A township wants ZTP only for initial image and configuration, then permanent local management afterward. How should that goal be framed relative to ZTP’s role?
Select an answer to reveal the explanation.
Short Explanation
ZTP is the moving truck that gets furniture into the building—not the facilities team that rearranges desks every week. The township can use it for day-0 image and config, then run steady-state management locally or with other tools. That is a normal split between first-boot automation and day-2 ops.
Full Explanation
ZTP is suited to day-0 image and config bring-up; ongoing township management can then be local or other ops tooling. That split keeps first-boot automation from being mistaken for forever orchestration. Keeping ZTP as the permanent day-2 controller for every change overstates the feature and blurs provisioning with continuous change platforms. Treating ZTP and continuous orchestration as identical so the township can never stop using ZTP collapses two lifecycles incorrectly. Limiting ZTP to spines while forcing console-only leaves invents a role restriction not used in leaf-spine DC ZTP definitions. Exam caveat: Day-0 ZTP is compatible with later static addressing, CLI/NETCONF, or external automation; those are complementary. Operational check: After ZTP, verify baseline config, document the day-2 change path, and ensure staff do not treat ZTP as the only allowed update method. In civic data-center practice, treat the correct concept as part of a controlled management design rather than an isolated checkbox, and document the expected show-command or log evidence so the next on-call engineer can prove the fabric behavior without re-deriving the theory under pressure. In civic data-center practice, treat the correct concept as part of a controlled management design rather than an isolated checkbox, and document the expected show-command or log evidence so the next on-call engineer can prove the fabric behavior without re-deriving the theory under pressure.