After a nurse successfully authenticates on the hospital's staff SSID, the access point needs to decide which role to place her session in so the right VLAN and firewall policy apply. Where does that role decision typically come from?
Select an answer to reveal the explanation.
Short Explanation
Once the badge office confirms who someone is, it also tells the door which key to hand over. In the same way, RADIUS doesn't just say yes or no to a login — it can return an attribute telling the AP or switch which role to apply.
Full Explanation
Role-based access ties a client's post-authentication treatment (VLAN, firewall policy, bandwidth limits) to a role, and that role is most commonly derived from an attribute the authentication server returns alongside its accept message, such as a group membership mapped to a named role. This lets the network apply differentiated policy automatically, so a nurse lands in the staff role with access to clinical systems while a visiting vendor authenticating on the same SSID with different credentials lands in a restricted role, all without the end user doing anything beyond logging in. A nurse manually picking her own role from a menu would defeat the entire point of centralized policy, since nothing prevents her from picking a more privileged role than she's entitled to; end users are never trusted to self-select their access level this way. Channel width is a Wi-Fi RF setting affecting throughput and has no bearing on identity-based policy. A switch's firmware version affects supported features and bug fixes, not which role an individual authenticated session receives. A good operational check is inspecting the authentication log for that session to confirm the expected role attribute was actually returned and applied, not just that the login succeeded.