A library creates local usernames so helpdesk staff can run show commands while only network admins receive higher privilege for configuration. What concept does that local-user design illustrate?

A library creates local usernames so helpdesk staff can run show commands while only network admins receive higher privilege for configuration. That local-user design illustrates separating local user privilege levels so operational roles get least-privilege access on the device: helpdesk accounts stay at lower privilege suitable for operational show commands, while admin accounts receive higher privilege needed for configuration—reducing accidental or unauthorized changes.

Giving every local user privilege 15 to simplify audits fails by concept; it maximizes blast radius and contradicts least privilege even if it seems “simple.” Replacing privilege levels with Flexible NetFlow monitors per username confuses flow accounting with user authorization/privilege. Using RSPAN VLANs as a substitute for user authentication does not identify users or constrain privilege; it only mirrors traffic.

Exam caveat: local privilege levels are a foundational IOS access-control idea; combine them with AAA/TACACS+ authorization in larger designs, but the stem’s point is role separation via privilege on local users. Privilege 15 for everyone is a common wrong answer.

Operational check for the library: log in as helpdesk and confirm configuration commands fail while show commands work; log in as network admin and confirm necessary configuration privilege; document accounts and periodically review that no helpdesk user has been quietly raised to privilege 15.