A city IT ops lead wants new QFX leafs to boot, fetch configuration, and join the municipal fabric without console staging on every rack. What does Juniper zero-touch provisioning (ZTP) primarily provide in this data-center deployment?
Select an answer to reveal the explanation.
Short Explanation
Picture dropping a new leaf in a city rack like plugging in a smart streetlight that downloads its own map. ZTP is that day-0 autopilot: the switch boots, finds provisioning services, and pulls image plus config without someone sitting on the console in every aisle. That is exactly what the municipal ops lead is after.
Full Explanation
Juniper ZTP primarily provides automated first-boot image and configuration retrieval so municipal QFX leaves join the fabric without per-rack console staging. Factory-default devices use DHCP for addressing and boot information, then pull Junos software and role configuration from a reachable file service on the planned management path. Manual USB imaging with no network services is a separate, labor-heavy staging method; it is not the primary value ZTP brings when city ops wants to avoid aisle-by-aisle console work. Permanent day-2 orchestration that replaces monitoring and telemetry overstates ZTP: after bring-up, observability and change platforms remain distinct operational layers. Requiring a full-mesh underlay redesign before any leaf can boot invents a topology prerequisite; Clos leaf-spine underlays do not need mesh conversion for ZTP to function. Exam caveat: ZTP does not invent reachability; DHCP and file-server paths on the intended management network must already be designed and reachable. Operational check: On a factory-default lab leaf, confirm DHCP options point to the municipal file server, verify artifact download completes, and validate hostname/role after first commit.