A transit agency wants one enterprise SSID but different network rights per job function. Which RBAC pattern best achieves that?
Select an answer to reveal the explanation.
Short Explanation
One SSID can still mean many fates when RADIUS attributes hand out roles. Badge-number SSIDs and break-room PSKs are the opposite of tidy RBAC. Rebooting APs is not authorization.
Full Explanation
A transit agency that wants one enterprise SSID but different network rights per job function should use the same SSID with different authorization delivered via RADIUS attributes. Drivers, supervisors, and contractors can all see one network name while AAA returns role-specific VLANs, ACL names, or filter attributes. That RBAC pattern scales cleaner across depots and buses than exploding SSID counts or posting shared secrets in break rooms. Creating a unique cleartext SSID per employee badge number is operationally unmanageable and still fails if those SSIDs lack strong AKM and centralized authorization. One shared PSK posted in every bus depot break room collapses identity into a community secret anyone can photograph. Daily reboot of all APs instead of authorization changes does not implement RBAC and only creates availability risk. Exam caveat: keep the attribute-to-role map documented—opaque filter-id values that only one engineer understands become an outage and audit risk during staff turnover. Operational check: place two job-function test accounts on the single enterprise SSID, confirm distinct RADIUS authorization results and resulting network rights, and attempt cross-role access that policy should deny while recording the outcome for the design package.