A rural broadband cooperative is onboarding a new field technician who needs to run diagnostic commands on POP routers but should never be able to change the configuration. Which approach best reflects Junos login-class design?
Select an answer to reveal the explanation.
Short Explanation
Login classes are how Junos does the 'give people only what they need' thing. Instead of handing over the keys to the whole building and hoping nobody wanders into a restricted room, you build a class that only opens the doors they actually need.
Full Explanation
Junos enforces access control through login classes, which bundle a set of permissions assigned to a user account under the system login hierarchy. The correct approach for a technician who needs to run diagnostics but never touch configuration is to define a custom class whose permission set includes operational visibility without configuration rights, then assign that class to the technician's account — this is exactly the least-privilege model Junos is designed around. Granting super-user access and trusting restraint defeats the purpose of the permission model entirely: super-user includes full configuration and maintenance rights, and relying on an individual's judgment is not an access control. Sharing the root account is worse still — root is a single shared identity with no way to distinguish which technician performed which action in the audit trail, and root's authority can't be selectively narrowed after the fact by class alone. There is also no default that silently grants read-only access to unclassified accounts; every local user must be explicitly assigned a login class, or account creation itself is incomplete. Operationally, the co-op should build one class per role — field technician, NOC monitor, senior engineer — so a configuration attempt from an unauthorized account fails predictably.