Docker Interview Questions

A curated set of Docker interview questions, ordered roughly from fundamentals to more practical, day-to-day scenarios — the kind you'll actually be asked in real screens and on-sites.

Fundamentals#

Q: What's the fundamental difference between a container and a virtual machine? A virtual machine virtualizes hardware — each VM boots and runs its own complete guest operating system and kernel on top of a hypervisor. A container virtualizes at the operating system level, with all containers on a host sharing the same underlying kernel and relying on kernel features (namespaces, cgroups) for isolation — which is why containers start in milliseconds and are typically megabytes rather than gigabytes.

Q: What's the difference between a Docker image and a Docker container? An image is a read-only template — layered filesystem contents plus metadata like the default command and exposed ports. A container is a running (or stopped) instance created from an image, with its own thin writable layer on top; many independent containers can be created from the same image, the same way many objects can be instantiated from one class.

Building images#

Q: How does Docker's layer caching work, and why does the order of instructions in a Dockerfile matter? Each instruction in a Dockerfile produces a cached layer, and a rebuild reuses a layer as-is if its inputs haven't changed since the last build — but the moment one layer's cache is invalidated, every instruction after it must rerun too. Ordering instructions from least-frequently-changing (copying dependency manifests, installing dependencies) to most-frequently-changing (copying application source) means routine source changes don't force a full dependency reinstall on every build.

Q: What's the purpose of a multi-stage Dockerfile build? It lets you use one build stage with the full toolchain (compilers, dev dependencies, source files) to produce a compiled artifact, then copy just that artifact into a second, much smaller runtime stage via COPY --from=<stage>. The result is a final image that ships only what's needed to run the app — smaller, faster to pull/deploy, and with a meaningfully smaller attack surface than shipping the build tools too.

Storage and networking#

Q: What's the difference between a named volume and a bind mount? A named volume is storage Docker fully manages and locates on the host itself — you reference it only by name, making it portable and the right fit for persistent data like a database. A bind mount maps a specific host path you choose directly into the container, which is convenient for local development (editing source on the host and seeing it live inside the container) but ties the setup to that host's exact filesystem layout.

Q: How do containers on the same Docker network communicate with each other? On a user-defined bridge network, Docker's built-in DNS server resolves each container's service/container name to its current internal IP address automatically — so one container can reach another simply by name (e.g., connecting to a database at host db) without hardcoding an IP that could change on restart. The default bridge network created automatically by Docker does not provide this name-based resolution, which is one of the main reasons to create a user-defined network explicitly.

Practical#

Q: If a container's data disappears every time you remove and recreate it, what's the likely cause and fix? The data is being written to the container's own writable layer instead of a persistent volume, so it's lost along with the container. The fix is mounting a named volume (or, for local development, a bind mount) at the path where the application writes its data, so that path's contents live independently of any single container's lifecycle.

Security and production readiness#

Q: Why run a container's process as a non-root user, given that it's already isolated from the host? Because container isolation is weaker than a VM's — all containers on a host share the same kernel — running as root inside the container still hands an attacker who exploits the running application root privileges within that container's namespace, which widens what a subsequent container-escape or kernel-level vulnerability could do next. Adding a dedicated unprivileged user with USER appuser before the final CMD (many official images, like Node's, already ship one) costs nothing at runtime and meaningfully limits the blast radius of a compromise.

Q: What's the practical difference between an alpine-based image and a distroless image? Both are far smaller than a full OS-based image like plain node:20 or ubuntu, but alpine is still a genuine, minimal Linux distribution with a shell and a package manager, useful for occasionally shelling in to debug. Distroless images strip out the shell and package manager entirely, leaving only the language runtime and the application — smaller and with far less for an attacker to work with post-compromise, at the cost of not being able to docker exec into a shell for interactive debugging.

Q: What's the difference between a Docker health check and a restart policy, and why do you need both? A health check (HEALTHCHECK in a Dockerfile, or healthcheck: in Compose) periodically runs a command to determine whether the application inside a running container is actually working, not just whether its process is still alive — a wedged app can stay "running" forever without a health check ever catching it. A restart policy (on-failure, always, unless-stopped) tells the Docker daemon what to do when the container's main process actually exits. They answer different questions — "is it healthy right now" versus "what happens when it dies" — and a production service typically needs both: a health check to detect it's stuck, and a restart policy to recover once it (or something monitoring it) actually stops the container.