After go-live, the customer hands over an org chart - full-time administrators, a security auditor, and a monitoring group that only needs to see status - and asks that each group receive "just what it needs". How should system access be built?

DDOS ships system-defined roles that group commands into coherent job shapes: full administration for day-to-day operators, a security-focused role for authentication and security settings, and restricted read-only or audit-style roles for observation. Least privilege is therefore a mapping exercise - each org-chart function matched to the closest built-in role, bound to named accounts - not a permission-authoring exercise. The ask itself rules out universal administration: training is not a control boundary, and an operator's mistyped command under a monitoring badge is exactly the accident least privilege exists to make impossible. A single custom middle-ground role collapses three different needs into one shape: auditors do not need operator command authority, operators do not need to administer security policy, and one blended grant over-privileges everyone in it. The 'auditors need admin to see consequences' argument confuses observation with mutation - review requires visibility of state and logs, which read-only roles provide, and adding change authority to an auditor destroys the independence that makes the audit meaningful. Exam caveat: check each job's commands against the available role definitions before authoring a custom role; the built-in set usually covers the org chart. Operational check: every named user carries a role matching their function, and one representative per group attempts one permitted and one forbidden action, with both results recorded.