Public works wants to add thousands of Wi-Fi IoT clients to the existing municipal WLAN. What planning step should come first?
Select an answer to reveal the explanation.
Short Explanation
Thousands of chatty sensors can turn a healthy WLAN into a parking lot of retries. Check capacity, airtime, and security segmentation before the onboarding party. Infinite-SSID myths and 'just add them tonight' are how civic Wi-Fi melts.
Full Explanation
Before public works adds thousands of Wi-Fi IoT clients to the municipal WLAN, evaluate current capacity, airtime, security posture, and segmentation limits. Enabling every legacy 802.11b-only rate and disabling security to maximize joins destroys performance and security. Adding devices overnight without checking AP client counts, airtime, or segmentation risks outage. Assuming unused SSIDs provide infinite capacity is false. Exam caveat: IoT onboarding is a capacity and security project, not a checkbox join. Operational check: model airtime for the IoT flood, expand AP density or offload to LPWAN/WPAN as needed, and only then schedule the municipal onboarding waves. In municipal WLAN and IoT operations, record the chosen control and the rejected alternatives in the change ticket so on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same control still holds under the current platform code, device mix, and civic event calendar used by the wireless team. Keep RF, capacity, security, and QoS evidence attached to the municipal runbook entry for auditors and future CWNE-level reviews. Attach spectrum, capacity, security, and QoS evidence to the municipal runbook entry so auditors and future CWNE-level reviews can replay why this control was selected for city services.