A water utility must push a template-driven SD-WAN change across many pump sites and wants to avoid one-off SSH snowflake configs. Which approach best fits?
Select an answer to reveal the explanation.
Short Explanation
vManage templates are the utility’s master blueprint; the configuration APIs stamp that blueprint on every pump site. Hand-SSH snowflakes look fast until Monday’s audit asks which device still matches intent.
Full Explanation
Water utilities pushing template-driven SD-WAN changes across many pump sites should apply changes through vManage configuration/template APIs so intent stays centralized and auditable. Avoiding one-off SSH snowflake configs is the point of SD-WAN templating and northbound automation. Fleet consistency and rollback narratives improve when vManage remains the source of truth.
SSH into each vEdge pasting unique CLI that never returns to templates recreates snowflakes. Storing production passwords in a shared spreadsheet and emailing screenshots is an anti-pattern. Disabling configuration management to rely on last-known running-config abandons controlled change.
Exam caveat: API-driven template changes still need staging, preview/diff, and change windows—automation is not a substitute for validation. Operational check: update a template via API in lab/staging, review device diffs, deploy to a pilot pump site, then promote. Ensure git or vManage version history captures who changed civic WAN intent. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that counters, logs, and failover behavior still match the documented design intent.