Visitors to city hall need Internet-only Wi-Fi and must not use staff directory credentials. What authentication path should the designer choose?
Select an answer to reveal the explanation.
Short Explanation
Guests shouldn’t borrow the employee badge printer. Give them their own on-ramp—guest SSID, portal, or sponsor flow—and keep staff Enterprise auth out of it. Mixing realms or handing out staff secrets is how lobbies become back doors.
Full Explanation
Visitors to city hall who need Internet-only Wi-Fi must not use staff directory credentials; the designer should provide a separate guest access path—such as a guest SSID with portal or sponsored workflow—isolated from staff Enterprise authentication. Putting guests on the same WPA3-Enterprise SSID and AD realm as employees invites credential phishing and policy crossover. Publishing the staff RADIUS shared secret on a lobby whiteboard compromises AAA infrastructure. Reusing the corporate EAP-TLS profile and issuing visitor client certificates from the staff CA by default blurs guest and employee trust. Exam caveat: guest design is about isolation of authentication and network path, not merely a different SSID name on the same AAA realm and VLAN. Operational check: deploy a distinct guest SSID/VLAN with portal or sponsor flow, verify guests cannot authenticate with staff AD passwords, and confirm firewall policy allows Internet-only. Document the separation in the municipal guest access standard used for all public-facing buildings. In municipal WLAN operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the infrastructure versions and client fleets used by the civic environment.