City guest Wi-Fi must onboard visitors, stop guest-to-guest snooping, and limit bandwidth abuse. Which control set fits?
Select an answer to reveal the explanation.
Short Explanation
Guest Wi-Fi needs a front desk, thin walls between visitors, and a speed limit. Portal plus isolation plus bandwidth policy is that trio. Handing guests the employee keys—or just breaking DHCP—misses the point.
Full Explanation
City guest Wi-Fi that must onboard visitors, stop guest-to-guest snooping, and limit bandwidth abuse needs a combined control set: captive portal plus client isolation and bandwidth policy enforcement. Portals handle acceptable-use acknowledgment and onboarding UX; isolation limits lateral movement between guest devices; rate policies protect civic uplinks during peak tourist or hearing days. No single control covers all three goals.
Granting guests full access to the finance VLAN after a logo splash page is a segmentation failure. Giving each guest the employee 802.1X profile for simplicity over-privileges visitors. Turning off DHCP so guests cannot obtain addresses and calling that isolation merely breaks onboarding and encourages risky static or tether workarounds.
Exam caveat: portal, isolation, and bandwidth must still sit on a dedicated guest VLAN with controlled upstream access—Layer-2 features do not replace routing policy. Operational check: associate two guest clients, confirm they cannot reach each other, verify portal completion is required, and measure that a bulk transfer hits the configured rate limit. In municipal WLAN programs, write the control into standards and verify it during change review so the next project inherits the same bar rather than rediscovering the failure mode under outage pressure.