Docker Interview Questions — Practice with Real Questions

Prefer COPY for copying local files into an image. COPY only copies files and directories from the build context, so its behaviour is transparent and predictable. ADD does extra implicit work — it can fetch remote URLs and auto-extracts local tar archives — which makes builds surprising. Both preserve permissions and handle single files, so reserve ADD for the narrow case where you actually want local-archive extraction.

An image is a read-only template: a stack of immutable layers holding the filesystem, dependencies, and default config built from a Dockerfile. A container is a running (or stopped) instance of an image — Docker adds a thin writable layer on top of the image's read-only layers and runs the entrypoint process. One image can spawn many independent containers, each with its own writable layer. The image is the class; the container is the object instance.

In a Dockerfile, each instruction (such as RUN, COPY, or ADD) creates a new cached layer that Docker reuses on subsequent builds only when the instruction itself and all of its input files are unchanged.

Docker Secrets (via docker secret / Swarm secrets). Secrets are stored in the Swarm Raft log, delivered to the container over a secure TLS mutual connection, and mounted as a file under /run/secrets/<secret_name> inside the container.

No. EXPOSE is only metadata — it records which port the application listens on but never publishes it. For host traffic to reach the container you must publish the port explicitly with -p 8080:8080, or auto-publish all exposed ports with -P. Publishing with -p even works without an EXPOSE line. Assuming EXPOSE opens the port is a common cause of an unreachable container.

The best practices are: exit code 0 for healthy and non-zero for unhealthy, use --start-period to give slow-starting apps a grace period, and keep the health check command fast so it finishes well under --timeout. You should NOT use HEALTHCHECK to replace orchestrator-level liveness/readiness probes, and a hanging command is never preferable to a quick non-zero exit.

Use a multi-stage build: compile/build your application in a full SDK base image in the first stage, then COPY only the resulting binary/artifacts into a minimal runtime base image (e.g. alpine, scratch, or a slim distroless image) declared in the final stage. This excludes build tools, intermediate files, and dev dependencies from the final image without changing your build process. Pair this with a minimal base image and a well-ordered Dockerfile (copy dependency manifests before source code) to maximize layer cache reuse.

In a Dockerfile, the RUN instruction that installs dependencies (npm install / pip install -r requirements.txt) should be placed in a layer before the layer that copies the application source code. This ordering ensures that the dependency-install layer is reused from cache when only the application source changes, because Docker builds each layer only when an instruction or its inputs have changed since the last build.

Docker Compose starts services in dependency order: db first, then cache, then api, then web. The depends_on directive ensures each declared dependency is started before the dependent service, so a linear chain produces a strict bottom-up startup sequence.

False. The default bridge network provides no automatic DNS resolution — containers on it can reach each other only by IP address. Name-based resolution (e.g. reaching a container called db by the name db) is a feature of user-defined bridge networks: create one with docker network create, attach both containers, and they resolve each other by name. This is why Docker Compose puts services on a user-defined network by default.

A multi-stage build uses several FROM instructions, each starting a new stage. An early 'build' stage uses a heavy base image with compilers, dev dependencies, and build tools to compile or bundle the app. The final stage starts from a slim runtime base and uses COPY --from=build /path/to/artifact . to pull only the built artifacts out of the earlier stage. Everything in the build stage — the toolchain, intermediate files, dev dependencies — is left behind and never ships in the final image, so it's far smaller and has a smaller attack surface. Naming the stage with AS build keeps the COPY --from reference stable even if stages are reordered.

A named volume is storage managed by Docker in its own area on the host; you reference it by name and Docker owns its lifecycle, so it's portable, easy to back up, and decoupled from any host path. A bind mount maps a specific host directory straight into the container, so its contents depend on the host's filesystem layout and the data is whatever is already at that path. Use a named volume for production state like a database's data directory — it survives container removal and isn't tied to a host path. Use a bind mount in development to mount your source code into the container so edits on the host show up live inside it. Both persist data beyond the container's life; the difference is who manages the storage and how coupled it is to the host.

Going from a Dockerfile to a running, reachable container follows a fixed sequence. The correct order is: first docker build reads the Dockerfile and produces an image of read-only layers, then the image is tagged so it can be referenced by name, then docker run creates a container by adding a writable layer on top of the image, then the container's entrypoint process starts and the app begins listening, and finally Docker forwards the published host port to the container port so external clients can reach the app.

To make a container restart automatically if it crashes AND come back up after a daemon/host reboot, but NOT restart if you manually stopped it, use docker run --restart **unless-stopped** ....

False. Docker Engine does not stop or restart a container when it becomes "unhealthy"; the container continues running with the unhealthy status. Automatic restart on health failure requires an orchestrator such as Docker Swarm, which treats unhealthy service tasks as failed and reschedules them.

Exec form launches your process directly so it becomes PID 1 and receives signals — including the SIGTERM that docker stop sends — letting it shut down gracefully. Shell form runs the command through /bin/sh -c, so the shell becomes PID 1 and often fails to forward SIGTERM to your process; docker stop then waits the grace period and SIGKILLs it. That is the usual cause of containers that take ten seconds to stop.

ARG and ENV values are baked into image metadata and recoverable with docker history --no-trunc, and ENV also persists into every container's environment. Writing a secret then rm-ing it later does not help either: layers are immutable and retained, so the file survives in the earlier layer. The only safe approach is a BuildKit secret mount (RUN --mount=type=secret), which exposes the value to one RUN step and never writes it to any layer.

hello world

Line 3 — COPY . . copies all source before npm install, so any source change invalidates that layer and forces the install to re-run; copy package*.json and install first, then copy the rest

True. During the --start-period grace window, health-check failures do not count toward the --retries threshold, so slow-starting containers are not prematurely marked unhealthy. Once the start period elapses, consecutive failures resume counting normally. This makes --start-period essential for containers with long bootstrap times.

The correct order is: FROM node:20-alpine, WORKDIR /app, COPY --from=deps /app/node_modules ./node_modules, COPY --from=builder /app/dist ./dist, CMD ["node", "dist/server.js"]. FROM must come first to define the base image; WORKDIR must precede COPY so relative destinations resolve correctly; production dependencies are copied before application code because they change less frequently, maximizing layer-cache hits; and CMD is placed last by convention as a metadata-only instruction.

Statements a, b, and c are true. docker exec bypasses the image ENTRYPOINT and runs the specified command directly; it requires the container to be in running status; and -e environment variables are scoped to the exec process only, not PID 1. Statement d is false because docker exec inherits the image's USER directive, so the process runs as appuser unless overridden with -u.

Structure. Two stages. Build stage FROM node:22 AS build: set WORKDIR, COPY package*.json ./, RUN npm ci, then COPY . . and RUN npm run build. Runtime stage FROM node:22-slim (or distroless/node): copy only what's needed.

Caching. Copy the manifest and lockfile and run npm ci before copying source, so the dependency layer is cached and only rebuilds when package.json/lock changes — not on every code edit. A .dockerignore (node_modules, .git, tests) keeps the context small and the cache stable.

Slim runtime. In the final stage, COPY --from=build --chown=node:node /app/dist ./dist and either copy a production-only node_modules (npm ci --omit=dev in the build stage, copied over) or reinstall prod deps. The compiler/dev deps stay in the build stage and never ship — image drops from ~1.1 GB to a couple hundred MB.

Non-root. The official node images ship a node user; USER node before CMD (with --chown=node:node on copies so it can read its files). If rolling my own: RUN useradd ... then USER.

Signals. CMD ["node", "dist/server.js"] (exec form) so Node is PID 1 and gets SIGTERM directly; the app handles SIGTERM to stop accepting connections and drain in-flight requests. CMD npm start runs npm (and a shell), which becomes PID 1 and doesn't forward SIGTERM — so docker stop waits the 10s grace period then SIGKILLs. Adding --init/tini is an alternative for zombie reaping.

Secrets. npm ci --omit=dev for reproducible, dev-free installs. A private registry token goes through a BuildKit secret: RUN --mount=type=secret,id=npmtoken ..., never ARG/ENV (those are recoverable via docker history).

Tradeoffs. Alpine is smallest but musl can break native modules; slim/distroless trade a little size for glibc compatibility and (distroless) harder debugging. Pin base tags rather than latest for reproducibility. A HEALTHCHECK lets the orchestrator detect a wedged process.

Below is a revised Dockerfile skeleton followed by the rationale for each decision.

# syntax=docker/dockerfile:1.7

# ---- Stage 1: Python deps ----
FROM python:3.12-slim AS py-deps
WORKDIR /app
COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install --no-cache-dir -r requirements.txt

# ---- Stage 2: JS deps + build ----
FROM node:20-slim AS js-build
WORKDIR /app
# Copy only manifest files for root + all workspace packages
COPY package.json yarn.lock ./
COPY backend/package.json backend/
COPY frontend/package.json frontend/
RUN --mount=type=cache,target=/usr/local/share/.cache/yarn \
    yarn install --frozen-lockfile
# Now copy source and build
COPY . .
RUN yarn workspace frontend build

# ---- Stage 3: Final runtime ----
FROM python:3.12-slim AS runtime
WORKDIR /app
# Copy installed Python packages from deps stage
COPY --from=py-deps /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
# Copy built JS assets
COPY --from=js-build /app/frontend/dist ./frontend/dist
# Copy application source last (changes most frequently)
COPY backend ./backend
EXPOSE 8000
CMD ["uvicorn", "backend.main:app", "--host", "0.0.0.0", "--port", "8000"]

COPY ordering rationale: Docker builds each layer as a cache-keyed hash of the parent layer ID plus the instruction and the checksums of all files referenced by COPY. If COPY . . precedes pip install, any change to any source file (even a comment in a React component) invalidates that layer and every layer below it, including the expensive pip install. By copying only requirements.txt first, the pip layer stays cached as long as the lock file is unchanged — which is the common case for source-only PRs. The same logic applies to the JS stage: package.json and yarn.lock are copied before yarn install.

Monorepo workspace manifests: Because Yarn workspaces resolve dependencies across multiple package.json files, we must copy every workspace package.json (at its correct relative path) before running yarn install --frozen-lockfile. We use a targeted set of COPY instructions rather than COPY . . so that source changes in frontend/src/ do not invalidate the dependency layer. The --frozen-lockfile flag ensures the lock file is authoritative and the install fails fast if manifests and lock are out of sync.

Multi-stage build: The final runtime image is based on python:3.12-slim (not the node image) and contains only the installed site-packages, the pre-built static JS assets, and the backend source. This drops the entire Node.js toolchain, dev dependencies, and intermediate build files from the final image, reducing it from potentially 1.2 GB to ~200 MB. Artifacts that cross stage boundaries are: site-packages (from py-deps), frontend/dist (from js-build), and backend source (copied directly in the final stage).

BuildKit cache mounts: --mount=type=cache,target=/root/.cache/pip persists the pip download cache across builds so that even when the requirements layer is invalidated, pip does not re-download packages from PyPI — it reuses cached wheels. Similarly, the yarn cache mount avoids re-downloading tarballs. Risks: (1) if the Python minor version in the base image changes (e.g., 3.12.1 → 3.12.2), cached wheels compiled against the old ABI may be reused and cause subtle import failures; (2) on ephemeral CI runners, the cache is lost unless a distributed cache backend (e.g., --cache-to=type=registry or a BuildKit remote cache) is configured; (3) stale cache entries can mask dependency resolution issues if the lock file is regenerated without a clean install. The cache mount should be paired with --frozen-lockfile / lock-file-based installs to mitigate drift.

.dockerignore: Critical entries include node_modules, .git, __pycache__, *.pyc, venv, .venv, frontend/dist, frontend/node_modules, .env, .env.*, *.log, .pytest_cache, .mypy_cache, and IDE directories (.vscode, .idea). These prevent local build artifacts and secrets from entering the build context, reduce the context tarball sent to the daemon (which alone can save minutes when node_modules is large), and ensure that local node_modules or virtualenvs do not shadow the container-installed dependencies when COPY . . runs later in the build stage.

USER only affects RUN (and CMD/ENTRYPOINT at runtime) — it does NOT change the ownership of files copied by COPY. COPY --from=builder /app /app preserves the ownership from the builder stage; if those files are owned by root there, they arrive owned by root in the final image regardless of USER 65532:65532, and the non-root process cannot write to any subdirectory it needs to modify. Fix: add --chown to the COPY itself, e.g. COPY --chown=65532:65532 --from=builder /app /app, which sets ownership at copy time without requiring an extra RUN chown layer. Alternatively, chown the files inside the builder stage before copying.