Environment Variables Docker
Fast recall
Quick revision
Core answer
Whether you understand Environment Variables Docker beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
The four mechanisms, from build-time to runtime:
# Dockerfile: ENV — baked into the image (every container from it)
ENV APP_MODE=production
# Dockerfile: ARG — build-time only (not in the final image)
ARG VERSION=dev
RUN go build -ldflags="-X main.version=${VERSION}" .The Go side (the receiver):
port := os.Getenv("PORT") // "8080"
dbURL, ok := os.LookupEnv("DATABASE_URL") // the present/absent distinctionThe pattern (12-factor): the container is the same everywhere (the image); the ENVIRONMENT is the config — the same binary, different env vars per environment. This is the docker env's entire value: the image is immutable; the env is the deployment.
The secrets distinction: env vars are readable via docker inspect — for secrets (DB passwords), use Docker secrets (Swarm/K8s) or a vault — env vars are fine for config, wrong for credentials.
The .env file: docker run --env-file .env reads the KEY=VALUE list — the development convenience. Production env vars come from the orchestrator (Kubernetes configMap/secret).
Environment Variables Docker
Direct Answer
docker run -e KEY=value passes env vars. In Dockerfile: ENV KEY=value (baked in) or ARG KEY (build-time, passed via --build-arg). docker-compose: environment: section. The app reads with os.Getenv/LookupEnv.
Deep Dive & Architecture
The ENV vs ARG distinction, mechanically: ENV values live in the image's config (every container, every start — same value). ARG values exist only DURING the build (the build's parameter) — not in the final image. The crossover: ARG VERSION + ENV APP_VERSION=${VERSION} — the build-time parameter baked into the runtime env.
The layer interaction: ENV creates a layer — changing the env in a rebuild invalidates every layer after it. Multi-stage builds mitigate (the final stage is minimal). The composition: ENV for defaults (the image's sane baseline), -e for the deployment's overrides — the precedence: run-time -e BEATS the image's ENV (the layering is deliberate).
The Go integration pattern: main reads the config env vars ONCE at startup, validates (fail fast on a missing required var), and passes the config struct everywhere. The app never re-reads os.Getenv mid-request (a config change mid-run is a different deployment — the container philosophy).
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Environment Variables Docker in a real project?
- How would you compare Environment Variables Docker with an alternative?
- What is a common mistake when using Environment Variables Docker?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.