Docker interview questions and answers for Docker Engine 29

This guide prepares you to answer the Docker questions that come up in developer, DevOps and backend interviews: what an image really is, why your build cache keeps breaking, how containers talk to each other, and why a container ignores Ctrl+C. By the end you should be able to explain each concept in two or three sentences and back it up with a small Dockerfile or Compose example.

The answers reflect Docker Engine 29, the current major version in October 2026 (29.9.0 was released on 8 October 2026), and they were checked against the Dockerfile reference and the Docker documentation. Engine 29 made the containerd image store the default for fresh installations, so expect at least one question about what changed.

Beginner questions: the core model

1. What is the difference between an image and a container?

An image is a read-only template: a stack of filesystem layers plus metadata such as the default command, environment variables and exposed ports. A container is a running (or stopped) instance of an image with its own thin writable layer on top. You can start many containers from one image, and deleting a container removes its writable layer but not the image.

2. How is a container different from a virtual machine?

A virtual machine runs a full guest operating system on virtualised hardware. A container is an isolated group of processes that shares the host's kernel; isolation comes from Linux namespaces and resource limits from cgroups. Containers therefore start in milliseconds and use far less memory, but they give weaker isolation than a VM, and a Linux container needs a Linux kernel (Docker Desktop on macOS and Windows runs a small Linux VM for this).

3. What is the difference between COPY and ADD?

Both copy files into the image. COPY copies from the build context, another build stage, a named context or an image. ADD can also fetch a remote URL or a Git repository, and it automatically extracts a local tar archive (a remote tar is not extracted by default). Use COPY unless you specifically need one of those extra behaviours, because it is predictable.

4. What is the difference between CMD and ENTRYPOINT?

ENTRYPOINT sets the executable the container always runs; CMD provides default arguments (or a default command if there is no entrypoint). Arguments passed to docker run replace CMD but are appended to an exec-form ENTRYPOINT. Only one CMD takes effect, and the shell form of ENTRYPOINT ignores CMD and command-line arguments entirely.

ENTRYPOINT ["node", "server.js"]
CMD ["--port", "3000"]
# docker run app            -> node server.js --port 3000
# docker run app --port 8080 -> node server.js --port 8080

5. How do you keep data when a container is removed?

Write it to a mount rather than the container's writable layer. There are three kinds:

• Volumes are managed by Docker, survive container removal and are the default choice for databases and uploads. They are not deleted automatically, except anonymous volumes of a container started with --rm.
• Bind mounts map a host path into the container. They are ideal for mounting source code in development but depend on the host's directory layout.
• tmpfs mounts live in memory and are never written to disk, which suits temporary or sensitive scratch data.

6. Does EXPOSE make a port reachable from the host?

No. EXPOSE only documents which port the application listens on. To reach it from the host you publish it at run time, for example docker run -p 8080:3000 app, which maps host port 8080 to container port 3000. A good follow-up point: publishing to 127.0.0.1:8080:3000 keeps the port off your public network interfaces.

Intermediate questions: builds, Compose and networking

7. How does the build cache work, and how should you order a Dockerfile?

Each instruction produces a layer, and Docker reuses a cached layer when the instruction and its inputs are unchanged. Once a layer changes, every layer after it must be rebuilt. So put the things that change least at the top: install dependencies from the lockfile first, then copy the rest of the source.

# syntax=docker/dockerfile:1
FROM node:24-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

Editing server.js now reuses the npm ci layer instead of reinstalling every package.

8. What is a multi-stage build and why use it?

A Dockerfile with several FROM instructions. You compile or bundle in a stage that has the full toolchain, then copy only the output into a small runtime stage, so compilers, dev dependencies and source files never reach production. Name stages with AS and copy with COPY --from; docker build --target build stops at a named stage, which is handy for running tests.

FROM node:24 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:24-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
USER node
CMD ["node", "dist/server.js"]

9. What is .dockerignore for?

It excludes files from the build context sent to the builder. Ignoring node_modules, .git, build output and local .env files makes builds faster, stops a broad COPY . . from invalidating the cache on irrelevant changes, and prevents secrets from being copied into an image by accident.

10. What is the difference between ARG and ENV, and where do secrets go?

ARG is a build-time variable: it is not embedded in the image and not available in the running container. ENV values persist in the image and are visible to the container, and an ENV overrides an ARG with the same name. Neither is a safe place for secrets, because values can end up in image metadata or history. Use a BuildKit secret mount for build-time secrets (RUN --mount=type=secret,id=npmrc ...) and inject runtime secrets from the orchestrator or a secrets manager.

11. What does Docker Compose do, and is the version key still needed?

Compose describes a multi-container application (services, networks, volumes) in one YAML file and runs it with docker compose up. The top-level version key is obsolete: Compose only treats it as informational and warns if you use it. A common follow-up is start-up order: depends_on with condition: service_healthy waits for the dependency's health check to pass, not merely for the container to start.

services:
  api:
    build: .
    ports: ["127.0.0.1:3000:3000"]
    depends_on:
      db:
        condition: service_healthy
  db:
    image: mysql:8.4
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root
    secrets: [db_root]
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 5s
      retries: 10
    volumes: ["dbdata:/var/lib/mysql"]
secrets:
  db_root:
    file: ./db_root.txt
volumes:
  dbdata: {}

12. How do containers find each other on a network?

On a user-defined bridge network, Docker provides automatic DNS, so the api container can connect to the database simply as db. On the default bridge network, containers can only reach each other by IP address. Compose creates a user-defined network for each project, which is why service names work as hostnames there. User-defined networks also isolate projects from each other.

Advanced questions: production behaviour

13. Why does my container take ten seconds to stop?

docker stop sends SIGTERM, waits for a grace period (10 seconds by default) and then sends SIGKILL. If you use the shell form (CMD node server.js), the main process is /bin/sh -c, which does not forward signals, so your app never sees SIGTERM and is killed. Fixes: use the exec form so your process is PID 1, handle SIGTERM in the app to close connections gracefully, and consider docker run --init (a tiny init process) to forward signals and reap zombie processes.

14. How do you make an image smaller and safer?

• Start from a slim or minimal base image and use multi-stage builds.
• Run as a non-root user with USER.
• Pin base images to a specific tag, or a digest for reproducibility, and rebuild regularly to pick up security patches.
• Combine package installation and cache cleanup in one RUN, or use RUN --mount=type=cache so package caches never become layers.
• Scan images for known vulnerabilities in CI and keep secrets out of the build context.

15. A container exits immediately. How do you debug it?

Check docker ps -a for the exit code, read docker logs <container>, and look at docker inspect for the command, environment and State.OOMKilled. Exit code 137 is 128 + 9, meaning the process was killed with SIGKILL, often by the out-of-memory killer. To explore interactively, override the entrypoint: docker run -it --entrypoint sh image. Remember that a container lives only as long as its main process, so a server that daemonises itself into the background makes the container exit.

16. What changed with the containerd image store in Docker Engine 29?

Docker Engine 29.0 made the containerd image store the default for fresh installations, replacing the older graph drivers for storing image layers (daemons using userns-remap were the exception). In practice it means images are stored and unpacked by containerd snapshotters, and the engine can natively hold multi-platform images and image attestations. Upgraded hosts keep using the legacy overlay2 driver until you enable the feature; after switching, old images stay on disk but are hidden, so you push or docker save them first. Engine 29 also deprecated cgroup v1 and removed Docker Content Trust from the CLI.

17. How do you build an image for both Intel and ARM servers?

Use Buildx with several platforms, for example docker buildx build --platform linux/amd64,linux/arm64 -t org/app:1.4 --push .. The result is a multi-platform image index, and each host pulls the variant that matches its architecture. Emulation (QEMU) makes cross-building possible but slow, so for heavy compiled builds teams use native builders for each architecture or cross-compile inside the build stage.

18. What do you still need beyond Docker in production?

Docker builds and runs containers on one host. Production also needs scheduling across machines, restarts, rolling deployments, service discovery, secrets and autoscaling, which is the job of an orchestrator such as Kubernetes or a managed container service on AWS, Google Cloud or Azure. Interviewers like candidates who mention health checks, resource limits and centralised logging here.

What interviewers look for

• A correct mental model: images are layers, containers are processes, data lives in volumes.
• Practical build habits: cache-friendly ordering, multi-stage builds, .dockerignore, non-root users.
• Security awareness: no secrets in ENV, ARG or layers; pinned, patched base images.
• Debugging steps said in order: exit code, logs, inspect, shell in.
• Honesty about limits: containers are not VMs, and Docker alone is not an orchestrator.

How to practise

1. Containerise a small app of your own with the multi-stage Dockerfile above and measure the image size before and after.
2. Change one source file and watch which build steps are cached.
3. Run the Compose file, stop the database and observe what depends_on does and does not protect you from.
4. Switch CMD between shell and exec form and time docker stop in each case.

If you can explain the results of those four experiments, you can answer almost every Docker question at junior and mid level with confidence.