Your team stores DB passwords as plaintext environment variables in deployment config that's checked into the repo. Better approach?

A committed secret is one of the most common real-world incidents, and this question checks whether you know the difference between hiding a secret and protecting it. The only correct answer removes the secret from source control entirely and manages it properly.

Why a secrets manager is the answer

A secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) gives you the three things source control can't: access control (only the workload's role can read the secret), audit (every retrieval is logged), and rotation (the password can be changed automatically and on demand). The application fetches the secret at runtime — via its IAM role or a sidecar — so nothing sensitive is ever committed. Critically, because the password was already in the repo, you must treat it as compromised: remove it from history and rotate it.

Why the distractors fail

• Base64-encode it. Base64 is encoding, not encryption. It's reversible by anyone in one command. The secret is just as exposed, now with a false sense of safety.
• Move it to a private repo. A private repo still hands the secret to every developer with clone access, every CI/CD runner, every fork and local clone, and anyone who later gains read access. "Private" is not "secret," and the credential still lives in git history forever.
• Hardcode it into the binary. Strings in a compiled binary are trivially extractable with strings or a disassembler. You've added build friction without adding protection, and you still can't rotate without a redeploy.

The history problem

Deleting the file from HEAD is not enough: the secret remains in git history and in every clone. That's exactly why rotation is mandatory — assume it has leaked and invalidate it.

What interviewers look for

Naming a managed secrets store with runtime injection, insisting on rotation because the secret is already compromised, and calling out that base64 and private repos are not protection. Strong candidates add a pre-commit/secret-scanning guardrail so it can't happen again.