For delivering a database password to a running container, compare an environment variable set with `docker run -e DB_PASSWORD=...` against a file mounted into the container. What leakage paths does each have, and which would you choose?

## Why this question is asked Both approaches "work", so the interviewer is testing whether you can enumerate real disclosure paths rather than repeat twelve-factor slogans. ## Leakage paths of environment variables - **Container config.** The value is stored in the container's JSON, so `docker inspect` prints it. On a shared host or CI runner, everyone with daemon access reads every service's credentials — including from *stopped* containers still on disk. - **Inheritance.** The environment is copied to every child process by default. A shell-out, a build tool, a debugging command — all carry the credential. - **/proc.** `/proc/<pid>/environ` is readable by the same uid (and by root), so any code running as the app user can read it, even code that had no business receiving it. - **Telemetry and crash paths.** Error trackers, core dumps, heap dumps and diagnostic endpoints commonly serialize the environment. This is the most common real-world disclosure: the credential ends up in a third-party SaaS. - **Upstream artifacts.** `--env-file` contents, shell history, CI job definitions and orchestrator objects all persist the plaintext value somewhere. - **Rotation.** Changing the value requires recreating the container, so rotation becomes a deployment. ## Leakage paths of mounted files - **Host storage.** The file exists on the host; backups, snapshots or other host users may capture it. Mitigate by placing it on **tmpfs** so it is memory-backed and never written to disk, and by setting restrictive mode and ownership. - **Container access.** Anyone able to run `docker cp` or exec into the container can read it — but that is true of the environment as well, and worse. - **Sloppy modes.** A world-readable bind mount defeats the point; the file should be readable only by the uid the process runs as. - **Application handling.** If the app reads the file and then logs it or re-exports it as an env var for a child process, you are back where you started. The decisive advantages of files: they are not in `inspect` output, they are not inherited, they carry filesystem permissions, and they can be replaced in place so a process that re-reads on demand picks up a rotated value without a restart. ## The practical convention Most official images support a `*_FILE` variant: instead of `POSTGRES_PASSWORD` you set `POSTGRES_PASSWORD_FILE=/run/secrets/db_password`. The environment carries only a **path** — harmless in `inspect` — while the value lives in a mode-0400 file on tmpfs. Docker Compose and Swarm `secrets:` entries deliver exactly that shape, mounting each secret at `/run/secrets/<name>`. If you own the application, implement the same convention: check `VAR_FILE` first, fall back to `VAR`, and read the file at startup or on a signal. ## When environment variables are acceptable When the platform gives you nothing better, when the value is low-sensitivity, or when the runtime injects it per-process from a secret manager so it never persists in a config object. Be pragmatic in the interview: state that env vars are the default because they are universal, then explain the specific disclosure paths that make a file better for real credentials, and note that neither approach protects against an attacker who already has code execution as the app user — they narrow exposure, they do not eliminate it. ## What to add if pressed Mention rotation strategy (file replace plus SIGHUP or periodic re-read), keeping material out of images entirely, restricting who can call `docker inspect` at all, and scrubbing the environment from crash reporters as a compensating control where env vars cannot be avoided.