A parks department is replacing controller-based APs with cloud-managed APs in recreation centers. Why must the deployment checklist change rather than reuse the old controller discovery steps unchanged?
Select an answer to reveal the explanation.
Short Explanation
Controller discovery is not cloud claim-and-adopt. If the parks team runs yesterday's checklist on today's cloud APs, adoption fails and nobody knows why. Match the checklist to the architecture.
Full Explanation
Controller discovery and cloud adoption are different management-plane workflows. When a parks department replaces controller-based APs with cloud-managed APs in recreation centers, the deployment checklist must change to reflect the target architecture's join and adoption steps—cloud claim codes, outbound management connectivity, and tenant assignment—rather than reusing Layer-2 controller discovery unchanged. Copy-paste checklists are a common cutover failure mode that leaves APs orphaned.
Claiming cloud APs never need network connectivity during onboarding fails by concept: cloud adoption requires reachability to the cloud management service. Asserting controller discovery and cloud onboarding are identical Layer-2 processes fails by concept: the architectures differ in discovery, addressing, and adoption. Saying only antenna torque values change fails by concept: management-plane onboarding differences are central, not merely mechanical torque.
Exam caveat: CWNE deployment checklists are architecture-specific; swapping controller for cloud without updating onboarding steps causes failed adoptions.
Operational check: Rewrite the recreation-center install checklist for cloud claim and activation, verify DHCP/DNS/firewall paths to the cloud service, and pilot one AP adoption before mass swap.