Docker interview questions: commands, scenarios, experienced

Docker interview questions test five things: how images are built (Dockerfiles, layers and the build cache), how containers run and fail (docker run, exec, logs, inspect, exit codes), networking and storage, Docker Compose, and container security. Freshers are asked to explain the concepts; experienced engineers get a failure ("the container keeps restarting", "the image is 2 GB") and are judged on the command they reach for and the fix they give. Questions on how Docker maps to Kubernetes now come up in almost every DevOps round.

This guide goes topic by topic, with the exact commands and error messages from Docker's own documentation, then maps each Docker concept to its Kubernetes equivalent, and ends with the answers that are out of date in 2026. For the rest of a DevOps interview, see DevOps interview questions; for the Kubernetes side in depth, see Kubernetes interview questions.

What Docker interview questions check

A fresher round checks that you can explain the moving parts in plain words: what an image is, what a container is, and why Docker isn't a virtual machine. An experienced round assumes that and asks you to debug and optimise: why a build is slow, why a container won't stop cleanly, why two containers can't reach each other. In both, the interviewer is listening for precise language. "A container is a running instance of an image, sharing the host kernel" is a strong answer; "a container is a lightweight VM" is the answer they're hoping you won't give.

Fundamentals: images, containers and VMs

What is the difference between an image and a container?

An image is a read-only template for creating a container, built from a series of filesystem layers. A container is a running (or stopped) instance of an image, with a thin writable layer on top. Many containers can run from one image, and deleting a container doesn't touch the image.

How is a container different from a virtual machine?

Containers share the host's kernel and are isolated with Linux namespaces and control groups (cgroups). A virtual machine runs a whole guest operating system on a hypervisor. So containers start faster and use less memory, but the isolation boundary is the kernel, which matters for security: a container is not as strongly separated from its host as a VM is.

Dockerfile and build questions

CMD vs ENTRYPOINT

ENTRYPOINT sets the executable the container runs; CMD supplies default arguments, which anything you add after the image name in docker run replaces. Use the exec form, a JSON array such as ENTRYPOINT ["executable", "param1"]. The shell form wraps your command in /bin/sh -c, so the shell becomes process 1, SIGTERM never reaches your app, and arguments passed to docker run are ignored. A practice question on ENTRYPOINT, CMD and arguments tests the override rules, and one on PID 1 signal handling tests the shutdown problem. If you can't change the entrypoint, docker run --init adds a small init process that forwards signals.

COPY vs ADD

COPY copies local files. ADD can also unpack a local tar archive and download from a URL, which makes its behaviour less predictable. Docker's best practices say to prefer COPY and use ADD only when you want the archive extracted. A practice question on COPY vs ADD with archives covers the difference.

Why is my build slow every time?

The classic cause is COPY . . before RUN npm install (or pip install): any source edit changes that layer and invalidates the cache for every layer after it, so dependencies reinstall on every build. The fix is to copy the lockfile, install dependencies, then copy the source. A practice question on build cache layer order is exactly this. The other cause is a huge build context: without a .dockerignore file, the CLI sends everything in the directory, and you see something like Sending build context to Docker daemon 2.5GB. A practice question on .dockerignore and the build context covers it. For experienced candidates, mention BuildKit cache mounts, RUN --mount=type=cache,target=/root/.cache, which keep package caches between builds without putting them in the image.

How do you make an image smaller?

Use a multi-stage build: compile in a full SDK image, then COPY --from=<stage> only the built artefact into a minimal runtime image such as alpine or scratch. Single-stage builds ship the toolchain, tests and git history, which is how images reach gigabytes. Also chain package installs with cache clean-up in the same RUN, and check what each layer adds with docker image history <image>. A practice question on multi-stage builds shows the pattern.

A build fails. What do the errors mean?

ERROR: failed to solve: process "/bin/sh -c <cmd>" did not complete successfully: exit code: 1 means a RUN step failed; read the output above it. failed to compute cache key: failed to calculate checksum of ref...: not found means a COPY source doesn't exist in the build context, often because .dockerignore excludes it. And a container that fails at start with exec /entrypoint.sh: no such file or directory when the file plainly exists usually has Windows line endings in the script.

Docker commands for running and debugging containers

A container keeps restarting. What do you do?

docker ps shows Restarting (1) 2 seconds ago. Read the output of the failing run with docker logs -f --tail 100 <container>, and check its exit code and state with docker inspect <container>. The usual cause is a permanent error (bad config, a missing file) combined with a restart policy of always or on-failure, so Docker relaunches it forever. Fix the cause; if you need the loop to stop first, docker update --restart=no <container>.

Exit code 137

docker inspect shows "OOMKilled": true and the exit code is 137, meaning the kernel killed the process with signal 9 because it went over its memory limit (--memory). Check real usage with docker stats, then raise the limit or fix the leak. Docker enforces --cpus and --memory with cgroups.

"Port is already allocated" and name conflicts

Bind for 0.0.0.0:<port> failed: port is already allocated means something else, often another container, already holds that host port: publish to another one (-p 8081:80) or free it. The container name "/<name>" is already in use means a stopped container still has the name: remove it with docker rm <name>.

Restart policies

The four are no, on-failure, always and unless-stopped. The common follow-up is the difference between the last two: a container set to unless-stopped stays stopped after a daemon restart if you stopped it by hand, while always brings it back.

Networking and storage

Why can't two containers reach each other by name?

On the default bridge network there's no automatic DNS between containers, so lookups fail with errors such as Could not resolve host: <container_name>. Create a user-defined bridge with docker network create <net> and run both containers on it with --network <net>; Docker's embedded DNS then resolves container names. A practice question on container DNS and user-defined networks covers it. Know the other drivers too: host removes network isolation, and overlay connects containers across several Docker hosts.

Volumes vs bind mounts

Named volumes live in storage Docker manages, survive the container, and are the right choice for persistent data. Bind mounts map a host path straight in, which suits development but depends on the host's directory layout and permissions. With --mount type=bind, a host path that doesn't exist fails with bind source path does not exist; the older -v syntax silently creates the directory instead, which is a classic source of empty mounts. A practice question on volumes, bind mounts and tmpfs asks you to choose between all three.

Docker Compose questions

Compose defines and runs a multi-container application from one compose.yaml; docker compose up -d starts it and docker compose down removes the containers and networks. The favourite scenario: the app container crashes at start with connection refused because the database isn't ready. Plain depends_on only waits for the database container to start, not for the database to accept connections. The fix is a healthcheck on the database and depends_on: { db: { condition: service_healthy } }, which a practice question on depends_on and health checks tests.

Security questions

Experienced rounds usually include three security questions. First, run as a non-root user with USER in the Dockerfile. Second, never put secrets in ENV or ARG, where they stay in the image layers; use a BuildKit secret mount, RUN --mount=type=secret,id=mysecret, which exists only during that build step (forgetting the matching --secret flag gives secret mysecret not found). Third, scan images: docker scout quickview <image> and docker scout cves <image> replaced the old docker scan. Pinning images by digest is a good fourth point to raise; a practice question on pinning image digests explains why.

Docker vs Kubernetes: how the concepts map

"Docker vs Kubernetes" is a common question, and the honest answer is that they aren't competitors. Docker builds images and runs containers on one host; Kubernetes runs containers across a cluster. Since Kubernetes removed dockershim in v1.24, nodes talk to a CRI runtime such as containerd or CRI-O, but they still run the images Docker builds. Experienced candidates should be able to map the concepts:

Container command: Docker ENTRYPOINT / Kubernetes command; Docker CMD / Kubernetes args.
Running and debugging: docker run / a Deployment applied with kubectl apply; docker exec / kubectl exec; docker logs / kubectl logs; docker inspect / kubectl describe.
Networking: bridge networks and published ports / flat Pod networking and Services (ClusterIP, NodePort, LoadBalancer) with CoreDNS.
Storage: named volumes / PersistentVolumes and PersistentVolumeClaims; bind mounts / hostPath, which Kubernetes restricts.
Restart policy: Docker's four policies / a Pod's restartPolicy of Always, OnFailure or Never, with Deployments requiring Always.
Limits: --cpus and --memory / resources.requests and resources.limits; going over the memory limit gives OOMKilled and exit code 137 in both.
Non-root: USER / securityContext.runAsNonRoot.

The CKA cert page and CKA practice questions cover the Kubernetes side, such as a practice question on debugging a control-plane static pod.

Answers that are out of date

Interviewers notice answers learned from old tutorials. As of November 2026:

docker-compose (Compose v1, the Python tool) reached end of life in June 2023. The command is docker compose, a Docker CLI plugin.
The top-level version: key in a Compose file is obsolete and ignored.
BuildKit has been the default builder since Docker Engine 23.0; the legacy builder is deprecated.
docker scan was replaced by Docker Scout.
overlay2 is the standard Linux storage driver; aufs and devicemapper are deprecated or removed.
Kubernetes no longer uses Docker Engine directly (dockershim was removed in v1.24).

How to prepare

Build and break things rather than memorise lists. Write a Dockerfile for a small app, make it slow on purpose (COPY . . first, no .dockerignore), then fix it with layer ordering and a multi-stage build, and compare sizes with docker image history. Set a low --memory and watch the exit code. Put two containers on the default bridge, see the name lookup fail, then fix it. Write a Compose file with a database and a health check.

Then test yourself: the Docker cert page explains the bank, and the Docker practice questions cover each topic above in ten questions.

Frequently asked questions

What are the most common Docker interview questions?

Image vs container, container vs virtual machine, CMD vs ENTRYPOINT, COPY vs ADD, volumes vs bind mounts, how container networking works, what Docker Compose does, how to debug a crashing container, and how to make an image smaller.

What Docker questions are asked of experienced candidates?

Scenarios: a slow build, a 2 GB image, a container stuck restarting, exit code 137, containers that can't reach each other, an app that starts before its database. You're expected to name the command that confirms the cause (docker logs, docker inspect, docker stats) and the exact fix, plus security practice and how each concept maps to Kubernetes.

What is the difference between Docker and Kubernetes?

Docker builds images and runs containers on a single host. Kubernetes schedules and manages containers across a cluster, keeping them in the state you declared. You typically build with Docker and run in production on Kubernetes.

How do you troubleshoot a Docker container that keeps crashing?

Read the logs with docker logs, check the exit code and state with docker inspect (137 with "OOMKilled": true means a memory limit), and check the restart policy, because always or on-failure will relaunch a container with a permanent error forever.

How do you reduce the size of a Docker image?

Use a multi-stage build so only the built artefact reaches a small runtime image, add a .dockerignore, clean package caches in the same RUN step that installs them, and inspect each layer with docker image history.