A bank must onboard 60 identical branches with routed ports, VPNs and security policies, allow one site-specific IP per branch, and minimize future change windows. Engineers have tested feature templates in the lab. Which device-template workflow builds reusable configuration and attaches it correctly to devices?

The correct workflow is right because 60 identical branches demand a single reusable hierarchy where tested feature templates for routed interfaces, VPNs, and security policy are assembled once into a device template, devices are attached with variables to preserve that reuse while permitting one site-specific IP, and the configuration is then pushed with deployment verification to confirm attachment and minimize future change windows through centralized updates. The CLI-based variant fails by concept because replacing lab-validated feature templates with CLI add-on templates discards structured, reusable modeling and version control, which increases parsing risk and future maintenance even though variables and push verification are retained. The manual follow-up variant fails by concept because completing VPN changes by hand per branch after the template push breaks single-source management, so every future policy update requires 60 separate change windows instead of one template change. The identical-IP variant fails by concept because retaining the same variable values across all branches violates the explicit per-site addressing requirement and will cause duplicate-IP conflicts and routing failures despite correct template reuse and verification. Exam caveat: distinguish feature templates from CLI templates and variable attachment from static entry, as questions often test reuse plus per-site customization together. Practical check: in SD-WAN Manager confirm the device template shows 60 attached devices with populated variable values, unique system and interface IPs per site, and a successful push status before closing the task.