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. The built-in roles each give either too much or too little for that job description. How should the engineer provide the access?

DD OS role-based access control is designed so the job description drives the role: when none of the built-in roles - full administration, security, audit-style visibility - matches what a team should be able to do, a user-defined role carrying exactly the permitted command set is the sanctioned answer, bound to named accounts so the work stays attributable. Granting the administrator role and hoping a written list of forbidden commands holds 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 make impossible. Sharing the built-in administrative login, on a rotation or otherwise, destroys attribution - every command lands in a shared trail that no longer names a person, which is the same defect the environment is being cleaned of. Assigning the security-focused role confuses subject matter: that role owns authentication and security settings, not observation of replication or capacity, so it neither carries the needed status commands nor excludes the security ones. Exam caveat: always check the built-in set before authoring anything custom - user-defined roles are for the residue the built-ins do not cover, not a first resort. Operational check: an operator logs in, runs the required status output successfully, and one configuration command is refused and logged.