City hall atrium mixes guests and staff and needs centralized policy with optional local data-path flexibility. How should designers match the wireless deployment model?
Select an answer to reveal the explanation.
Short Explanation
Policy wants a central brain; some traffic wants to stay in the atrium. Pick a deployment that keeps the rulebook centralized but still lets you choose local data paths when the design calls for it.
Full Explanation
City hall atrium designs that mix guests and staff and need centralized policy with optional local data-path flexibility should choose a wireless deployment model that centralizes policy on controllers while allowing options that can keep some data switching local when required. Central policy enforces consistent guest versus staff segmentation, AAA, and profiles; selective local switching can keep atrium printer or local-server traffic on-site when hairpinning to a distant controller is undesirable.
Forcing every frame through an unmanaged consumer router in the lobby with no policy engine abandons enterprise control. Disabling AAA and sharing one PSK across guest and staff without segmentation collapses security boundaries. Using only bridging hubs so SSIDs cannot be tied to any controller policy profile removes the centralized policy the stem requires.
Exam caveat: Model selection is about matching policy centralization and data-path options—not unmanaged gear or shared PSKs as shortcuts.
Operational check: map guest and staff SSIDs to controller policies, decide which WLANs centrally switch versus locally switch in the atrium, and test that guest quarantine and staff access still meet city hall security standards.