Top 50 Docker Interview Questions in 2026 (With Real Answers)
Containers are the ground floor of modern infrastructure. Even teams running fully on Kubernetes or serverless still build images, write Dockerfiles, and debug local containers daily. Interviewers in 2026 expect you to know the runtime, not just the CLI.
These are the 50 questions that come up most often in DevOps, platform, and backend loops.
Fundamentals (1-10)
1. What is Docker and what problem does it solve?
A toolset for packaging applications into portable images that run in isolated processes (containers). It solves "works on my machine" by bundling code, runtime, and OS-level dependencies into a single artifact you can run anywhere there's a container runtime.
2. Container vs VM - what's the actual difference?
A VM virtualizes hardware and runs a full guest OS. A container shares the host kernel and isolates only the user-space (filesystem, processes, network namespace). Containers boot in milliseconds, weigh megabytes, and pack denser. VMs give you stronger isolation - which is why public clouds run containers inside VMs.
3. What is a Docker image?
A read-only filesystem template made of stacked layers. Each Dockerfile instruction creates a layer. Images are immutable - you don't modify them, you build new ones.
4. What is a Docker container?
A running instance of an image. It adds a thin writable layer on top of the immutable image. When the container is removed, that writable layer goes with it (unless you mount a volume).
5. What is Docker Hub vs ECR vs GHCR?
Public/private image registries. Docker Hub - the default public one, rate-limited for unauthenticated pulls since 2020. ECR - AWS's private registry, with public/private tiers. GHCR - GitHub's, integrated with Actions. Pick one and pin pulls to it; don't depend on Docker Hub for production.
6. Explain docker run -it ubuntu bash line by line.
docker run- create and start a container-i- keep stdin open-t- allocate a pseudo-TTYubuntu- image to run (latest tag implied)bash- command to execute as PID 1
Together: an interactive shell in an Ubuntu container.
7. What's the difference between docker run and docker start?
run creates a new container from an image and starts it. start restarts an existing stopped container. Most CI workflows always run (and remove with --rm); long-lived dev containers use start/stop.
8. Difference between docker exec and docker attach?
exec runs a new process in a running container (docker exec -it id bash for a debug shell). attach connects you to PID 1's stdin/stdout - if PID 1 isn't a shell, you can't really do anything. Use exec 99% of the time.
9. Where do container logs live?
By default, in the host's /var/lib/docker/containers/<id>/<id>-json.log (with the json-file driver). docker logs <container> reads them. In production, configure a log driver (fluentd, awslogs, gelf) so logs go directly to your aggregator.
10. What's a Dockerfile?
A text file with instructions to build an image: FROM, RUN, COPY, CMD, etc. Each instruction creates a layer. The order matters - put fast-changing instructions last to maximize cache hits.
Dockerfiles and Builds (11-20)
11. Explain CMD vs ENTRYPOINT.
ENTRYPOINT- the executable that always runsCMD- default arguments (overrideable atdocker runtime)
A common pattern:
ENTRYPOINT ["python"]
CMD ["app.py"]
docker run image runs python app.py. docker run image other.py runs python other.py.
12. RUN shell form vs exec form - which do you use?
Exec form: RUN ["command", "arg"] - no shell, more predictable.
Shell form: RUN command arg - runs through /bin/sh -c, supports pipes and redirects.
Use shell form when you need shell features, exec form otherwise. Same applies to CMD and ENTRYPOINT.
13. What is a multi-stage build?
A Dockerfile with multiple FROM directives. Earlier stages build artifacts; the final stage copies just what's needed:
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN go build -o /app
FROM gcr.io/distroless/base
COPY --from=build /app /app
ENTRYPOINT ["/app"]
Final image is tiny because it doesn't ship the toolchain.
14. How do you write a smaller Docker image?
(1) Multi-stage builds. (2) Use alpine, distroless, or scratch for the runtime stage. (3) .dockerignore to keep cruft out of the build context. (4) Combine RUN steps to avoid intermediate layer bloat. (5) Use --no-install-recommends for apt and clean caches.
15. What is .dockerignore and why does it matter?
Like .gitignore but for the build context. Without it, your node_modules, .git, and IDE files get sent to the daemon on every build, which is slow and can leak secrets. Always include at least: node_modules, .git, *.log, .env*.
16. How does Docker layer caching work?
Each instruction's output is cached by the image content of inputs. If you change a file referenced by COPY, that layer and everything downstream rebuild. Order Dockerfiles so the slowest/most-stable steps come first.
17. What's BuildKit and why should you use it?
The modern Docker build engine, default since 23.0. Adds parallel stage execution, secret/SSH mounts that don't bake into layers, cache mounts (RUN --mount=type=cache,...), and remote caching. Everything you'd want for fast, secure builds.
18. How do you mount build secrets without baking them into the image?
# syntax=docker/dockerfile:1.6
RUN --mount=type=secret,id=npm_token \
NPM_TOKEN=$(cat /run/secrets/npm_token) npm install
Then docker build --secret id=npm_token,src=token.txt. The secret is available at build time, never written to a layer.
19. What's a HEALTHCHECK?
HEALTHCHECK --interval=30s --timeout=3s \
CMD curl -f http://localhost/healthz || exit 1
Docker runs the command periodically. Status flips from starting to healthy/unhealthy. Orchestrators (Compose, Swarm, Kubernetes liveness probes) use this to make scheduling decisions.
20. ADD vs COPY - which do you use?
COPY. ADD does extra magic (auto-extract tarballs, fetch URLs) which is rarely what you want and surprises people. Use COPY unless you're explicitly using ADD's features.
Networking and Volumes (21-30)
21. What network drivers does Docker support?
bridge(default) - private network on host, NAT for outboundhost- container shares host's network stack, no isolationnone- no networkingoverlay- multi-host networking for Swarmmacvlan- container gets its own MAC on the physical network
Most use cases are bridge for dev, overlay or CNI plugins for production orchestrators.
22. How do containers on the same bridge network talk to each other?
By container name. Docker runs an embedded DNS server that resolves container names to IPs within user-defined networks. The default bridge network does NOT do this - you have to create your own network or use Compose.
23. What is docker-compose for?
Defining multi-container apps in YAML. One docker-compose.yml describes services, networks, and volumes; docker compose up starts everything. Replaces a pile of docker run commands and gives you a reproducible local dev environment.
24. Volume vs bind mount vs tmpfs - what's the difference?
- Volume - Docker-managed, lives in
/var/lib/docker/volumes/. Portable, survives container removal, the right default. - Bind mount - mounts a host directory into the container. Useful for dev (
./src:/app/src) but couples the container to the host filesystem. - tmpfs - in-memory, gone when container stops. For sensitive scratch space.
25. How do you persist a database in a container?
A named volume mounted at the data directory:
services:
db:
image: postgres:16
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
Without that, container removal nukes your database.
26. What does EXPOSE actually do?
Documents which ports the container listens on. It does NOT publish the port to the host. You need -p 8080:80 (or ports: in Compose) to actually map a host port.
27. How does port mapping work?
-p 8080:80 tells Docker to publish container port 80 to host port 8080. Docker manages the iptables rules. With -P (capital), Docker publishes all EXPOSEd ports to random high ports.
28. What is the Docker DNS resolver and where does it live?
127.0.0.11 inside the container. Docker injects this into /etc/resolv.conf for containers on user-defined networks. It resolves container names and falls back to the host's resolver for external lookups.
29. How do you debug a container that won't connect to another container?
Step by step. (1) Are they on the same Docker network? docker network inspect. (2) Does DNS resolve? docker exec a getent hosts b. (3) Is the port reachable? docker exec a nc -vz b 5432. (4) Is the service actually listening on 0.0.0.0, not 127.0.0.1?
30. What are container labels and when are you using them?
Key-value metadata: --label app=api. Used by orchestrators (Traefik, Kubernetes, Compose) for service discovery, monitoring tags, and log routing. Standard labels follow the org.opencontainers.image.* schema.
Production and Security (31-40)
31. Should you run as root inside containers?
No. Add a non-root user and USER to your Dockerfile. Many official images already do this (e.g., node image has a node user). Running as root means a container escape gives root on the host.
32. What is docker scan / docker scout?
Vulnerability scanners that check image layers against CVE databases. docker scout cves <image> is the modern command. Run it in CI; fail builds on high-severity unpatched CVEs.
33. How do you keep base images up to date?
Pin to a specific minor version (node:20-alpine, not node:latest), then rebuild on a schedule (Dependabot, Renovate, or scheduled CI) so you pick up patches. latest is unpinned and unreliable.
34. What's the difference between slim, alpine, and distroless?
slim- Debian with most non-essential packages removedalpine- musl-based, very small, can break C extensions that expect glibcdistroless- Google's minimal images, no shell, no package manager. The most secure option for production.
35. How do you reduce attack surface in production images?
(1) Distroless or scratch base. (2) Non-root user. (3) Read-only root filesystem (--read-only). (4) Drop Linux capabilities (--cap-drop=ALL --cap-add=NET_BIND_SERVICE). (5) Seccomp/AppArmor profiles. (6) No shell, no debugging tools in the runtime image.
36. What's a "shell-less" container debugging trick?
Distroless images have no shell, so docker exec -it container sh won't work. Use kubectl debug (K8s 1.23+) or attach an ephemeral debug container with a separate image, sharing the target's process namespace.
37. How does Docker isolate containers?
Linux namespaces (PID, NET, MNT, UTS, IPC, USER) and cgroups. Namespaces give the illusion of a private system; cgroups limit and account for resources (CPU, memory, IO).
38. What are cgroups in containers?
Kernel feature for resource limits. --memory=512m --cpus=0.5 translates to cgroup limits. Without limits, one runaway container can starve the whole host. Always set limits in production.
39. What's the difference between Docker Engine and containerd?
containerd is the lower-level container runtime. Docker Engine sits on top of it and adds the high-level CLI, image building, networking primitives. Kubernetes 1.24 dropped Docker shim and now talks to containerd directly. Most production K8s clusters never touch the Docker Engine.
40. How do you handle image signing?
Cosign (Sigstore project) is the 2026 standard. Sign images at build, verify at deploy time. Kubernetes admission controllers can require signed images via Cosign verification policies.
Real-World Scenarios (41-50)
41. Container exits immediately - how do you debug?
Run interactively to see the actual error: docker run --rm -it image sh. If the entrypoint runs and exits cleanly, the container will too. Check docker logs, check CMD/ENTRYPOINT, check that PID 1 is actually a long-running process.
42. The image builds locally but fails in CI - what's likely?
(1) Different platform (M1 Macs build arm64; CI builds amd64). Use docker buildx build --platform=linux/amd64. (2) Different cache state. (3) Build context differs - .dockerignore differences or files not committed.
43. How do you build multi-arch images?
docker buildx:
docker buildx build --platform linux/amd64,linux/arm64 \
-t myimage:tag --push .
Required if you have a mix of M-series Mac dev machines and amd64 production hosts (or arm64 Graviton in production).
44. PID 1 in containers - why does it matter?
PID 1 has special responsibilities (reaping zombies, forwarding signals). If your app spawns subprocesses and ignores SIGCHLD, you accumulate zombies. If it ignores SIGTERM, docker stop waits 10s then SIGKILLs - bad for graceful shutdown. Use tini (--init) or run a proper init.
45. How do you forward SIGTERM to your app correctly?
Use exec form (CMD ["python", "app.py"]) so the app is PID 1 directly. Shell form (CMD python app.py) makes /bin/sh PID 1, which doesn't forward signals by default. The --init flag adds tini as PID 1 to handle signals correctly regardless.
46. Build is slow - 8 minutes on every CI run. How do you speed it up?
(1) Layer ordering - copy package manifests before source so dep install caches. (2) BuildKit cache mounts for package managers (--mount=type=cache,target=/root/.npm). (3) Remote cache (--cache-from=type=registry,ref=myimage:cache). (4) Multi-stage parallel execution. (5) Smaller base images.
47. How do you debug "container can reach the internet but not internal services"?
Almost always DNS or network policy. (1) Is the container in the right network? (2) Is the destination service actually exposed? (3) Are there iptables rules blocking it? (4) On Kubernetes, NetworkPolicy. The classic debug toolkit: nslookup, curl -v, tcpdump.
48. What's the "12-factor app" and how does Docker enable it?
The 12-factor methodology - apps as stateless processes, config from env, logs to stdout. Docker is a natural fit: env vars are first-class, stdout is captured by the runtime, processes are ephemeral. If your app violates 12-factor, containerizing it is harder.
49. What's docker system prune and when do you run it?
Removes unused containers, networks, images, build cache. Run when disk fills up. docker system prune -a is more aggressive (removes any image not referenced by a running container). On dev machines, run it monthly. On CI runners, schedule it.
50. The Dockerfile that's 200 lines long - what's wrong?
Almost always it's bundling too much - your app and a dozen support tools, init scripts, multiple services. Split into separate images. A good Dockerfile is 10-30 lines. If it's longer, you're either fighting with apt, stacking workarounds, or shipping a distribution rather than an application.
Final thoughts
Docker interviews in 2026 are about depth. The shallow questions ("what's a container") are warmups. The real signal comes from production scenarios - how do you debug, how do you secure, how do you make it fast. Master those and you'll cut through 90% of the field.
If your image is over 500MB or your build takes more than two minutes, those are the first things to fix.