How would you manage application secrets (DB passwords, API keys) across environments? Walk me through the options and their trade-offs.
What they are really testing: Whether you treat secrets as a managed lifecycle problem (storage, access, rotation, audit) or just "an env var somewhere". They want to hear you rank the options and explain why plaintext in the repo or a baked-in .env is the wrong answer.
A real interview question
How would you manage application secrets (DB passwords, API keys) across environments? Walk me through the options and their trade-offs.
What most people say
drag me
“I would put them in a .env file and add it to gitignore so it does not get committed.”
gitignore is a foot-gun, not a control: the secret is still plaintext on every machine, has no rotation, no audit, and no per-environment isolation. It also says nothing about how the running workload gets the value safely.
The follow-ups they ask next
Your secret store is now a single point of failure for every app at boot. How do you handle that?
Cache the fetched secret in memory with a TTL so the app survives a brief store outage; the store is highly available already, but a local cache means a blip does not crash every pod that restarts during it. Do not write the cached value to disk.
A developer accidentally logged a secret. What is your response and prevention?
Treat it as compromised: rotate the secret immediately (the whole point of having rotation). Prevent recurrence with log scrubbing/redaction, secret-scanning in CI (pre-commit + pipeline), and never passing secrets as command-line args.
What the interviewer is listening for
- Rules out repo and image plaintext immediately
- Names a managed store and what it adds (audit, versioning, rotation)
- Uses a workload identity instead of a static credential
- Treats rotation as a design requirement, not an afterthought
What sinks the answer
- Thinks gitignore is a security control
- No mention of rotation or audit
- Hardcodes a long-lived static credential to read the store
- Same secrets shared across all environments
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“The rule is [no secrets in the repo or the image]. I would use [a managed secret store like Secrets Manager or Key Vault] for [versioning, access control, and audit]. The app reads them via [its own IAM role / managed identity], and I would [rotate on a schedule and re-read on a TTL] so rotation needs no redeploy. Stores are [separated per environment].”
Keep going with iam & security
Junior
A service needs to read objects from exactly one storage bucket. How do you grant it access?
Mid
A service is suddenly returning 500s in production. Walk me through how you would troubleshoot it.
Mid
Design durable, highly available storage for user-uploaded images. Which service do you choose and why?
Mid
An Azure VM cannot connect to an Azure SQL Database. Walk me through how you debug the networking.
Mid
Your team provisions infrastructure with code. Why does idempotency matter, and what breaks without it?
Mid
Compare blue-green and canary deployments. When would you reach for each?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free