Security and Best Practices in Automation
Automation concentrates privilege, so security and guardrails are exam-critical. Know credential and secret management: never hardcode credentials; use environment variables, encrypted vaults (e.g., Ansible Vault, HashiCorp Vault), or a secrets manager; rotate keys; use least-privilege accounts and role-based access control (RBAC) on devices and controllers. Understand transport security: SSH, HTTPS/TLS, certificate validation (do not disable host-key or TLS verification in production), and secure storage of keys.
Understand change safety: dry runs (commit check, check mode), confirmed commit with automatic rollback, peer review, approval gates, and audit logging of who changed what and when. Know that automation accounts should be distinct from human accounts for traceability, and that the source of truth must be protected and versioned.
Traps: disabling certificate/host-key checks "to make it work"; storing secrets in playbooks or Git; granting automation broad admin rights when least privilege suffices; and assuming a successful script run means a correct network state (always verify). Also expect questions on idempotency as a safety property, rate limiting to prevent runaway loops, input validation to prevent injection into templates/commands, and keeping tooling and dependencies patched.
Rule of thumb: least privilege + secrets out of code + encrypted transport + dry-run + rollback + audit = defensible automation. If any of these is missing, the design is unsafe.
Worked example: A playbook reads the device password from an environment variable injected by the CI secret store, connects over NETCONF/SSH with host-key verification, runs commit check, then a confirmed commit with a rollback timer - and logs the run to an audit system.