How do you securely manage secrets in the cloud?
Short answer
Store secrets in a dedicated managed service (Secrets Manager, Parameter Store, Vault), encrypted with a KMS key, and grant access through IAM roles so workloads fetch them at runtime with short-lived credentials. Never bake secrets into code, container images, or committed .env files. Add automatic rotation, scoped key policies, and audit logging so every retrieval is traceable.
Secrets management is where good intentions meet reality: developers want the app to "just have" the database password, and the easy paths — a .env in the repo, a constant in code, an environment variable baked into an image — all leak. The interview wants the secure pattern and the reasoning.
The right pattern
- A dedicated secrets store. Use Secrets Manager, SSM Parameter Store (SecureString), or HashiCorp Vault. These keep secrets out of source control and give you versioning, rotation, and access logs.
- Encryption via KMS. The store encrypts secrets with a KMS key using envelope encryption — KMS holds the master key and never exposes it; a per-secret data key does the bulk encryption. Key policies control who can even decrypt.
- Access via IAM roles, not static keys. The workload assumes a role and fetches the secret at runtime. Combined with short-lived role credentials, there is no long-lived secret to steal at rest in the app.
- Rotation and audit. Enable automatic rotation so a leaked credential has a short useful life, and log every
GetSecretValuecall so retrievals are attributable.
Why the easy paths fail
A committed .env lives forever in git history. A secret baked into a Docker image layer stays in that layer even if a later RUN rm deletes the file — anyone who pulls the image can extract it. Plain environment variables show up in crash dumps, child processes, and logging.
What interviewers look for
Naming a managed store, explaining KMS envelope encryption and key policies, insisting on IAM-role access plus rotation, and knowing why image layers and git history make "delete it later" useless.
Likely follow-ups
- What is envelope encryption and how does KMS use a data key?
- How do you rotate a database credential without downtime?
- Why is a secret in a Docker image layer still exposed even after you delete it in a later layer?