The customer wants one account that a compliance reviewer can use to read logs and system state but change nothing. What is the right way to serve that request on the appliance?
Select an answer to reveal the explanation.
Short Explanation
Least privilege isn't a favor you negotiate — it's built into the box. The platform ships a read-only audit tier whose whole job is 'can look, can't touch,' so your compliance reviewer gets an account, not a compromise. Don't hand over the master keys with a memo asking for politeness.
Full Explanation
The platform ships a role model so that least-privilege requests become configuration rather than invention: full administration for operators, intermediate capabilities for operators with narrower duties, and a read-only audit tier whose permission set allows viewing logs, status, and configuration while refusing configuration commands. Serving the compliance reviewer is therefore a user-creation task — create the account, bind it to the built-in read-only tier, and the requirement is met inside the product's own access model. A full admin account governed by a written agreement fails on control type: policy that relies on the operator's good behavior is not a control, and a compliance account holding write authority is exactly the finding an audit raises. Routing the reviewer to an external log mirror fails by ignoring the built-in capability — mirroring serves retention and analytics needs, but on-system review within the platform's access model does not require it. Calling the operator tier view-only fails on role semantics: operator-level roles are documented as permitting a set of operations, so binding the reviewer there grants writes the request explicitly excludes. Exam caveat: 'can view but not change' maps to the audit or read-only tier, never to a reduced admin. Operational check: create the user with the read-only role, run one status command and one configuration command as that user, and confirm the first succeeds while the second is refused.