City hall wireless must keep staff devices from sharing a broadcast domain with public guest Wi-Fi. What virtual-network design should automation implement?
Select an answer to reveal the explanation.
Short Explanation
You can keep staff and guest traffic safely apart by using separate subnets, typically on separate VLANs, rather than relying on access-point names. A shared subnet or bridging guests into the finance or elections network would expose sensitive traffic to the wrong devices.
Full Explanation
City hall wireless should place staff devices and public guest Wi-Fi on separate subnets, typically backed by separate VLANs, so they do not share a broadcast domain or equivalent Layer-2 adjacency. This lets automation apply distinct DHCP scopes, access controls, captive-portal behavior, and firewall policies: guests can receive tightly restricted visitor or internet access, while staff can reach approved municipal resources under stronger identity controls. Putting staff, guests, and servers on one shared wireless subnet and relying on access-point names fails because names do not provide network-layer separation; all clients still share a broadcast domain, increasing lateral discovery and attack risk. Bridging guest Wi-Fi directly into the finance VLAN fails because it gives untrusted public devices adjacency to a sensitive financial segment. Extending guest SSIDs onto the elections air-gap network also breaks essential zoning and may violate elections security requirements for isolation from public wireless. Exam caveat: separate SSIDs alone are insufficient if they map to the same subnet or VLAN; verify that network segmentation and policies actually differ. Practical check: confirm staff and guest clients receive addresses from different prefixes, inspect VLAN mappings, and test that a guest client cannot reach staff resources; also verify guest SSIDs are not mapped to the finance or elections networks.