During a failover drill, a city controller cluster fails. Some client data forwarding continues while new 802.1X authentications stall. What does this most likely demonstrate?
Select an answer to reveal the explanation.
Short Explanation
Controllers are like city hall and the mail trucks. Mail already on the road may keep moving, but new IDs at the clerk window freeze when city hall is dark. Know which plane breaks.
Full Explanation
During a city controller-cluster failover drill, some client data forwarding may continue while new 802.1X authentications stall because forwarding and authentication planes can fail differently; existing data paths may continue while new auth depends on the controller or RADIUS path. It is false that all wireless data always stops the instant any controller process exits. Controller loss does not only affect guest captive portals while never touching employee SSIDs—auth-dependent employee joins stall too. Dual Ethernet links on APs do not make failover tests unnecessary. Exam caveat: test both data continuity and new authentication during controller failure. Operational check: during the drill, verify existing sessions, attempt new 802.1X joins, and document municipal failover behavior for voice and staff SSIDs. In municipal WLAN and IoT operations, record the chosen control and the rejected alternatives in the change ticket so on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same control still holds under the current platform code, device mix, and civic event calendar used by the wireless team. Keep RF, capacity, security, and QoS evidence attached to the municipal runbook entry for auditors and future CWNE-level reviews.