An image is built from a Dockerfile containing `ENV LOG_LEVEL=info`. What value does the process see when the container is started with `docker run -e LOG_LEVEL=debug`, and what happens if the Dockerfile also declares `ARG LOG_LEVEL` and the build is run with `--build-arg LOG_LEVEL=trace`?

## Runtime precedence The image's `Config.Env` list — everything set by `ENV`, plus whatever the base image inherited — is the **default environment** for containers created from that image. It is not authoritative; the runtime layers on top of it. Strongest to weakest for a plain `docker run`: 1. `-e NAME=value` on the command line. 2. `--env-file file` entries. 3. The image's `ENV` values (including those inherited from the base image). With Compose the same shape applies, with Compose's own layering in front: `docker compose run -e` → the service's `environment:` → its `env_file:` → the image `ENV`. Note also `-e NAME` with no `=value`, which passes the variable through from the invoking shell — handy, and a way to accidentally leak host environment into a container. Crucially, an override changes **that container only**. The image is immutable; `docker inspect` on the image still shows `LOG_LEVEL=info`, and a second `docker run` without `-e` gets `info` again. That immutability is the point: one image artefact promoted through dev/stage/prod, configured per environment at start. ## Build-time precedence between ARG and ENV Inside the build, both mechanisms put values into the environment of `RUN` commands, so they can collide. Docker's documented rule is that an `ENV` with the same name **takes precedence over an `ARG`** for the rest of the build. Concretely: ```dockerfile ARG LOG_LEVEL=info ENV LOG_LEVEL=warn RUN echo $LOG_LEVEL # prints warn, even with --build-arg LOG_LEVEL=trace ``` People hit this when they try to "parameterise" an image whose base already sets the variable with `ENV` — for example overriding `NODE_ENV` or a base image's `JAVA_HOME` by passing a build arg, which quietly does nothing. The fix is always to make the dependency explicit by assigning the ARG into the ENV. ## The intentional bridge ```dockerfile ARG LOG_LEVEL=info ENV LOG_LEVEL=${LOG_LEVEL} ``` Read it as: the build accepts an input, and the image records the chosen default. This gives three layers of control — the Dockerfile default, the build-time override, and the run-time override — which is usually exactly what a platform team wants. Ordering matters: the `ARG` must appear above the `ENV` that references it, and both must be inside the stage that produces the final image (an `ENV` set in an earlier multi-stage stage does not survive into the final one). ## Where a value ends up mattering - **`ENTRYPOINT`/`CMD` in exec form do not run a shell**, so `CMD ["sh", "-c", "echo $LOG_LEVEL"]` expands the variable but `CMD ["echo", "$LOG_LEVEL"]` prints the literal text. Environment overrides are still delivered to the process; it is the *expansion in the instruction* that needs a shell. - **Some tools read only their own config**, so setting an env var that the application does not consult achieves nothing — check the application's precedence rules too (many frameworks put command-line flags above environment above config files). - **PATH-like variables**: `ENV PATH=/opt/tool/bin:$PATH` is a common append idiom; overriding `PATH` at run time with `-e` replaces it wholesale and can break the entrypoint. ## Practical guidance - Prefer **runtime** configuration (ENV overridden at start) over **build-time** configuration for anything that differs by environment. Baking `LOG_LEVEL=debug` at build time forces a rebuild per environment and defeats artefact promotion. - Use build args for things that genuinely change the *contents* of the image: dependency versions, base tags, target architecture, feature-flagged compilation. - Give every runtime variable a sensible `ENV` default in the Dockerfile so the image runs with no flags at all; treat the override as the exception. - Verify rather than assume: `docker inspect -f '{{json .Config.Env}}' image` shows the baked defaults, and `docker exec <container> env` shows what the running container actually has. ## What interviewers are listening for Two sentences: "run-time `-e` beats image `ENV`, and the image is unchanged", and "ENV beats a same-named ARG during the build, so you must assign the ARG into the ENV explicitly". Candidates who know only the first half typically write Dockerfiles that silently ignore their own `--build-arg` flags.