A monitoring server will run read-only health-check commands against the appliance's CLI every night. The draft automation stores a human administrator's password inside the script. What should replace that arrangement?
Select an answer to reveal the explanation.
Short Explanation
Your monitoring server isn't a person, so stop signing it in like one. Give the machine its own read-only account with SSH keys and the scripts run with exactly the reach the job needs. You'll also stop getting paged when a colleague changes her password.
Full Explanation
Machine-to-device automation should authenticate as the machine, not as a borrowed human: DD OS supports SSH public-key authentication, so a dedicated account for the monitoring server, restricted to a read-only role and keyed with a private key held only by that server, gives the automation an identity whose reach matches its job. A key-based machine identity can be scoped and revoked independently of staff changes, and the audit lines name the monitor instead of a person who is asleep at 02:00. A credential vault is better hygiene than a plaintext file but leaves the core defect: the automation still acts as a named human, so the human's password rotation breaks the job, the human's departure pages someone, and machine traffic is misattributed to a person in the audit trail. An environment variable relocates the secret without changing its nature - still a human password, still held on a box that is not the human's. A second human administrator account doubles both errors: it adds a full-privilege identity owned by nobody while keeping the password-in-automation failure underneath. Exam caveat: pair the key-based machine account with a role no broader than read-only - least privilege applies to robots too. Operational check: run one health check as the machine identity, confirm the output, then attempt a configuration command and watch it refuse and log.