On shared AP hardware for a city network, how should employee, guest, and IoT SSIDs be designed?
Select an answer to reveal the explanation.
Short Explanation
Staff, guests, and IoT shouldn’t share one big open living room—and you also shouldn’t invent an SSID per laptop. Segment sensibly, lock down security per role, and keep the SSID count lean so Beacons don’t eat the air. Open employee SSIDs are not an onboarding strategy.
Full Explanation
Shared AP hardware still needs logical segmentation matched to community risk and without SSID sprawl. On city network APs carrying employee, guest, and IoT traffic, design should segment SSIDs and security to each community's requirements while avoiding excessive SSID count that wastes Beacon airtime. Employee 802.1X, guest isolation, and IoT posture differ; one open blob or one SSID per device are both wrong extremes.
Putting all three communities on one open SSID to minimize Beacon overhead fails by concept: overhead savings cannot justify collapsing security domains. Creating a unique SSID per user device fails by concept: SSID explosion burns airtime and operational complexity without proportional security gain. Disabling encryption on the employee SSID so IoT onboarding is simpler fails by concept: employee traffic must remain protected; IoT onboarding problems are solved with proper IoT SSID design, not by opening staff WLAN.
Exam caveat: CWNE SSID architecture balances segmentation against Beacon overhead on shared municipal radios.
Operational check: Define employee/guest/IoT security profiles, limit SSID count per radio to what policy requires, measure Beacon airtime, and verify VLAN/firewall separation between communities.