Day one after handover: the backup operations team wants a login of its own so it can check filesystem usage, replication status and daily health output without being able to reconfigure anything. How should the engineer provide the access?

DD OS role-based access control uses a fixed set of built-in roles - admin, limited-admin, user, backup-operator, security, none, and the tenant roles - rather than user-defined roles. The user role is the one that matches this job: it can monitor the system, view status, and change its own password, but it cannot change the system configuration, so assigning it to individually named operator accounts gives the team visibility while keeping every action attributable. Granting the administrator role and relying on a written list of forbidden commands fails by concept: a control that depends on restraint is not a control, and one mistyped command under full rights is exactly the accident least privilege exists to prevent. Sharing the built-in sysadmin login, on a rotation or otherwise, destroys attribution - every command lands in a shared trail that no longer names a person. Assigning the security role confuses subject matter: that role belongs to security officers who authorize sensitive procedures and manage other security officers, not to an operations desk watching replication or capacity. Exam caveat: if the team must also create MTree snapshots or move virtual tapes, the backup-operator role adds exactly those tasks on top of the user role. Operational check: an operator logs in, views filesystem usage and replication status, and one configuration command is refused.