Outside contractors on the city’s guest SSID must reach a few internal project apps without placing those apps on the open guest VLAN. Which control best fits the encryption/security design?
Select an answer to reveal the explanation.
Short Explanation
Guest Wi-Fi is the lobby—internal apps live behind the badge door. A VPN concentrator lets contractors carry an encrypted tunnel from that lobby to the apps without pouring the app VLAN onto the guest SSID. Bridging guest straight inside is the opposite of segmentation.
Full Explanation
Outside contractors on a city guest SSID who must reach a few internal project apps should do so through a Layer 3 VPN to a concentrator rather than by placing those apps on the open guest VLAN. The VPN preserves segmentation: guest RF remains a lower-trust path while authorized application sessions traverse an encrypted tunnel under enterprise identity and routing control. That pattern fits civic zero-trust instincts without pretending guest Wi-Fi is an internal LAN extension. Bridging the guest SSID directly onto the internal app VLAN collapses trust boundaries and exposes applications to every guest associate and their malware. Publishing internal app links on the captive portal over clear HTTP invites interception and still fails network segmentation. Disabling guest Wi-Fi entirely and forcing unsupervised cellular removes a managed path without guaranteeing stronger enterprise oversight or logging for contractor access. Exam caveat: VPN authorization for contractors should remain identity-scoped and time-limited—guest-path VPN is not a blanket pass to all city systems merely because the user associated to guest Wi-Fi. Operational check: from a client on the guest SSID without VPN, confirm project apps are unreachable; with VPN connected, confirm only published app routes succeed and that Layer 2 scanning on the guest VLAN still cannot see internal app subnets.