Securely supplying secrets to an app

WHAT THIS TESTS This is a security-hygiene question. The interviewer wants to know you keep credentials out of code and the build artifact and that you can name a concrete safe pattern.

A GOOD ANSWER COVERS The anti-pattern is putting the database URI directly in source code or a checked-in config file. Once committed it lives in git history forever even if later removed, it is visible to everyone with repo access, and it gets baked into any image built from that code. The baseline best practice is to externalize the secret and inject it at runtime as an environment variable, set as a platform config var or container env, so the same image runs in any environment with different credentials and nothing sensitive is in the repo. The stronger practice is a dedicated secrets manager such as AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault: the app authenticates with its own identity and fetches the secret at startup, which adds centralized rotation, fine-grained access control, and an audit trail. Pair this with least-privilege IAM and regular rotation.

COMMON WRONG ANSWERS Committing credentials and assuming a private repo is safe. Baking secrets into the Docker image, which anyone who pulls the image can extract. Treating environment variables as fully secret without restricting who can read the config. Never rotating.

LIKELY FOLLOW-UPS How do you rotate a database password with zero downtime? What are the limits of environment variables for secrets, such as exposure via logs or child processes? How does an app authenticate to a secrets manager without a bootstrap secret, for example using instance IAM roles?

ONE CONCRETE EXAMPLE Instead of DATABASE_URL = "postgres://user:pass@host/db" in settings.py, the code reads os.environ["DATABASE_URL"]. In production an IAM-scoped task fetches the URI from AWS Secrets Manager at boot using the instance role, so the credential is never in git or the image, can be rotated centrally, and every access is logged.