An election office wants one device template to onboard many firehouse Edges. Which elements are typically supplied as device-specific variables?
Select an answer to reveal the explanation.
Short Explanation
One cookie cutter, many cookies—but each cookie still needs its own name tag. System IP and site-id are the classic per-device variables; the shared template holds everything that should look alike. That’s how one design covers a dozen firehouses.
Full Explanation
SD-WAN device templates scale election-office and firehouse onboarding by separating shared configuration from device-specific variables. System IP, site-id, hostnames, and similar identifiers uniquely place each Edge in the fabric while one common template structure is reused across many sites. That pattern keeps centralized intent consistent and reduces one-off CLI drift between firehouses.
Reinventing the entire centralized AAR policy as a per-device variable defeats shared intent and multiplies policy versions. Modeling the vSmart certificate chain as a unique per-Edge-interface variable confuses controller trust material with device template variables. Claiming OMP graceful restart timers cannot be expressed outside CLI snippets misstates what device and feature templates can carry in a well-structured design.
Exam caveat: variables exist for per-device uniqueness; fabric-wide policy generally stays centralized and shared unless a deliberate localized exception is required.
Operational check: attach the common device template, populate system IP and site-id variables per firehouse, push configuration, verify each Edge appears with the correct site identity and shared policy, and audit that no site-specific forks were created unnecessarily.