A city public-works team wants repeatable WAN Edge builds across many yards instead of unique CLI pastes. Which SD-WAN configuration approach best supports that scale?
Select an answer to reveal the explanation.
Short Explanation
Feature templates are Lego bricks—VPN, interface, AAA pieces you snap into a device template for every yard router. CLI snowflake pastes do not scale when public works adds another dozen sites. Laptop text files named after techs are how configurations go missing on Friday afternoon.
Full Explanation
City public-works wanting repeatable WAN Edge builds across many yards should use feature templates composed into device templates for consistent, reusable Edge configuration. Template-driven SD-WAN configuration is the scalable civic alternative to unique CLI pastes per truck yard.
One irreversible CLI-only paste per device with no reusable objects does not scale and drifts immediately.
Manual TACACS command authorization as the only configuration source of truth controls who can type—not what standardized config is deployed.
Storing full running-configs solely in personal laptop text files named after technicians fails change control and bus-factor resilience.
Exam caveat: variables and device-specific values still belong in templates—avoid hard-coding every yard IP into a single shared feature without variables.
Operational check: build feature templates, assemble a device template for the yard platform, attach a pilot Edge, and diff intent vs running. Publish the template catalog for public-works WAN Edge onboarding. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.