DevOps Engineer interview question
How do you manage infrastructure secrets?
Keep secrets in a dedicated encrypted manager, issue identities instead of static keys where possible, grant least privilege, inject at runtime, avoid logs and images, rotate automatically, audit access, and test revocation.
Direct answer
What a strong answer covers
How it works
Secrets live in a dedicated manager such as Vault, AWS Secrets Manager, or a cloud KMS-backed store, never in code, images, or CI variables copied by hand. Wherever possible workloads authenticate with an identity, a Kubernetes service account bound to a cloud role or a SPIFFE identity, so there is no long-lived key to leak at all. Access is least privilege per secret, secrets are injected at runtime through mounted files or short-lived tokens rather than baked at build time, rotation is automated with dual-validity windows, every read is audited, and revocation is tested so a leaked credential can be killed in minutes.
Example
A service reads its database password from a Vault dynamic secret with a one-hour lease tied to its Kubernetes service account; there is no static password to rotate. The third-party API key that cannot be dynamic lives in Secrets Manager, is mounted as a file by the CSI driver, and is rotated monthly by a Lambda that updates both the vendor and the store. A leaked key drill last quarter revoked and replaced a key in six minutes.
Common mistakes
- Passing secrets as environment variables that end up in crash dumps and logs.
- Baking a credential into a Docker image layer.
- Rotating secrets on paper only, with no rehearsed revocation.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.