How should secrets like API keys and database passwords be managed in an application?

Secrets — API keys, DB passwords, signing keys, tokens — are high-value targets because a single leaked one can unlock entire systems. Managing them well is mostly about keeping them out of the places they tend to leak and limiting the damage if one does.

The cardinal rule: not in code

Secrets must never live in source code, config files committed to version control, container images, or client-side bundles. Git history is forever — a secret committed once is compromised even after you delete it, so it must be rotated, not just removed. Embedding secrets in a compiled binary doesn't help either; they're trivially extractable.

Centralize and inject

Store secrets in a purpose-built secrets manager or vault (HashiCorp Vault, AWS Secrets Manager, cloud KMS-backed stores). The application fetches them at runtime via an authenticated identity, or they're injected as environment variables/mounted files by the platform. This centralizes control, encryption, and auditing.

Limit blast radius

• Least privilege: each service can read only the specific secrets it needs.
• Rotation: rotate secrets on a schedule and immediately on suspected exposure.
• Short-lived dynamic credentials: the best pattern — the vault generates a credential on demand that expires in minutes, so a leaked secret is useless almost immediately and there's nothing long-lived to steal.
• Audit logging: record every secret access to detect misuse.

The bootstrapping problem

There's always a "secret zero" — the initial credential an app uses to authenticate to the vault. Solve it with platform-provided workload identity (instance roles, OIDC federation, mTLS) rather than yet another static secret.

What interviewers look for

The baseline is "never hardcode, use a vault." The mid-level signal is rotation, least-privilege scoping, and especially favoring short-lived dynamic credentials, plus awareness of the secret-zero bootstrapping challenge.