Docker Interview Questions for 2026: 40+ Q's Across Images vs Containers, the Layer Cache, Dockerfiles, Volumes, Networking, Compose, and the Orchestration Intro New Grads Get Wrong

What docker interview questions should I prepare for in 2026

Prepare across four buckets: fundamentals (images vs containers, layers, the build cache), Dockerfile authoring (instruction order, multi-stage builds, base-image choice), runtime (volumes, networking, docker-compose), and a conceptual close (containers vs VMs plus an intro to orchestration). The fundamentals are the floor that screens out tutorial-only candidates. The Dockerfile and runtime buckets are where most new-grad rounds are actually decided. The orchestration close is the senior signal that shows you know where Docker stops.

The reason these buckets matter is that Docker sits in the middle of almost every modern backend, DevOps, and platform role. A CS new grad in the 2025-2026 hiring cycle who can write a clean Dockerfile and reason about the layer cache reads as someone who has shipped real software, not just solved algorithm puzzles. That single competency moves you out of the "only did coursework" pile.

What docker interviews test in 2026

Docker interviews test three things, roughly in this order: whether you understand the image-and-container model deeply enough to explain it without a slide, whether you can write and optimize a real Dockerfile (the text file that defines how an image is built), and whether you can reason about the runtime concerns that bite in production (data persistence, container-to-container networking, multi-service orchestration). A fourth, lighter layer probes the conceptual boundary between containers and virtual machines and the handoff to an orchestrator.

The 2026 hiring environment rewards hands-on fluency. Containerization is no longer a niche DevOps skill; it shows up in backend, full-stack, data-engineering, and platform interviews alike. Docker itself, born in 2013, standardized the format and the workflow, and the surrounding ecosystem (the Open Container Initiative image spec, container registries, and orchestrators like Kubernetes and the managed container services on every major cloud) now assumes a working knowledge of images, layers, and Dockerfiles as table stakes. Interviewers have adapted by asking build-and-debug questions that are hard to fake. "Your image is two gigabytes and the build takes eight minutes, what do you change" cannot be answered from memorized definitions. It requires having actually optimized a Dockerfile.

A second reason these rounds have gotten sharper: containers are now how teams guarantee that the code on a candidate's laptop, the CI runner, and production all behave identically. That "works on my machine" guarantee is the business value, so interviewers probe whether you understand the mechanism behind it (immutable images plus an explicit build) rather than treating Docker as a black box you copy commands into.

Distribution of question types most new-grad candidates report seeing in their docker rounds:

• 30-40% fundamentals (images vs containers, layers, the build cache, the writable layer)
• 25-35% Dockerfile authoring and optimization (instruction order, multi-stage, base image, image size)
• 20-30% runtime (volumes vs bind mounts, networking and port publishing, docker-compose)
• 10-15% conceptual (containers vs VMs, intro to orchestration, where Docker hands off)

The Dockerfile-authoring slice is the one most candidates under-rehearse, and it disproportionately determines the outcome. Someone who recites "an image is a template" but cannot explain why their dependency-install step keeps rebuilding usually loses the round to someone who fumbles a definition but writes a clean, cache-friendly build.

Key terms

A definition list for the terms that anchor a docker interview. Learn the one-sentence version of each; the questions later expand on them.

Image

A read-only template made of stacked filesystem layers plus metadata, used as the blueprint to start one or more containers.

Container

A running or stopped instance of an image with a thin writable layer on top and its own isolated process, network, and filesystem view.

Layer

A single filesystem diff produced by one Dockerfile instruction, cached and shared across images so identical layers are stored and pulled only once.

Dockerfile

The text file of instructions (FROM, RUN, COPY, CMD, and others) that Docker reads top to bottom to build an image.

Volume

Docker-managed persistent storage that lives outside a container's writable layer, the right default for keeping database and stateful data across container restarts.

Registry

A server that stores and distributes images (a public hub or a private registry); docker push uploads and docker pull downloads tagged images.

Three more definitions worth holding in your head before the interview. The build context is the set of files Docker sends to the daemon at build time, which is why a stray .git directory or node_modules can bloat builds unless a .dockerignore excludes them. Orchestration is the automated scheduling, healing, and scaling of containers across many machines, the job Docker itself does not do. A user-defined bridge network is a private network Docker creates so containers on it resolve each other by name through built-in DNS, which is exactly how docker-compose services find each other.

How to prepare for docker interview questions

A focused three-week plan, calibrated for a CS new grad whose Docker is at the "ran a tutorial once, never wrote a real Dockerfile" starting point. The steps map one-to-one to the prep plan in this guide's structured data.

1. Week 1 (days 1-7): install Docker and write a Dockerfile by hand. Pick a small web app you already have. Write a Dockerfile from scratch with a base image, a working directory, a dependency-install step, a source copy, and a start command. Build it, run it, reach it on a published port. End the week fluent in docker build, docker run, docker ps, docker logs, docker exec, and docker stop without looking up flags.

2. Week 1 in parallel: break the build cache and watch what rebuilds. Edit one line of source, rebuild, and notice which layers print CACHED. Reorder the Dockerfile so the dependency install sits above the source copy, edit one line again, and watch the dependency layer stay cached. Seeing the rebuild boundary move teaches the cache question cold.

3. Week 2 (days 8-12): convert to a multi-stage build and add a volume. Split into a build stage and a slim runtime stage, copying only the artifact with COPY --from. Measure the size before and after with docker images so you can quote a real reduction. Add a named volume for a small database, remove and recreate the container, and confirm the data survived.

4. Week 2 in parallel: wire a multi-service app with docker-compose. Write a compose file with a web service, a database with a named volume, and optionally a cache. Bring it up with docker compose up. Confirm the web service reaches the database by its service name, proving you understand user-defined-network DNS.

5. Week 3 (days 13-17): drill the definition questions out loud. One distinction per sitting: image vs container, volume vs bind mount, CMD vs ENTRYPOINT, container vs VM, bridge vs host networking. State the criterion and the use case, not just the textbook line. Record yourself once and listen for the hand-waving.

6. Week 3 in parallel: read where Docker hands off to orchestration. Be able to define orchestration, name Kubernetes, explain self-healing and rolling updates in a sentence each, and say honestly that you have run containers locally but not operated a production cluster.

7. Day 18-21: run two timed mock interviews. First mock: fundamentals and Dockerfile authoring. Second mock: a build-and-debug scenario plus the containers-vs-VMs and orchestration close. Narrate out loud as if screen-sharing. If you want on-demand reps, run a mock docker round in the live interview assistant and rehearse saying each answer out loud before the real round.

The non-negotiable weeks are one and two. There is no substitute for having broken your own build cache and watched it rebuild, or having lost container data and fixed it with a volume. Interviewers can tell within a minute whether you have done that work or only read about it.

Docker fundamentals questions (8 Q)

The questions below cover the surface area every docker interview assumes you know cold. Memorize the answer outlines; adapt the language to your own voice. The structure is the load-bearing part.

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

An image is a read-only template, a stack of filesystem layers plus metadata describing how to start a process. A container is a running or stopped instance of that image with a thin writable layer on top. One image, many containers, each isolated. The writes a container makes land in its own writable layer and never modify the image. State the class-and-object analogy and the immutability point, and you have answered the underlying follow-ups before they're asked.

Q2. What is a Docker layer?

A layer is the filesystem diff produced by a single Dockerfile instruction. Images are stacks of these read-only layers. Layers are content-addressed and shared: if two images use the same base layer, it is stored once on disk and pulled once over the network. The interview-relevant consequence is that small, well-ordered layers make builds faster and pulls cheaper, because Docker reuses unchanged layers from cache.

Q3. What is the writable layer and why does it matter?

When a container starts, Docker adds a thin writable layer on top of the image's read-only layers. Every file the container creates or modifies goes there using copy-on-write. The catch: that writable layer is tied to the container's lifecycle and is destroyed when the container is removed. This is exactly why containers "lose data" on a fresh docker run, and why anything that must persist belongs on a volume.

Q4. What happens when you run docker run?

Docker checks for the image locally and pulls it from a registry if missing, creates a container with a fresh writable layer, sets up the container's namespaces and network, and starts the process defined by the image's entrypoint and command. Useful flags to mention: -d for detached, -p to publish a port, -v to mount a volume, -e to set an environment variable, --name to name the container. Knowing the lifecycle, not just the flags, is the signal.

Q5. What is the difference between docker stop and docker kill?

docker stop sends SIGTERM first and gives the process a grace period (10 seconds by default) to shut down cleanly before following with SIGKILL. docker kill sends SIGKILL immediately with no grace period. The practical point: a well-built image uses the exec form of CMD or ENTRYPOINT so the signal actually reaches your process rather than a shell wrapper, letting docker stop trigger a graceful shutdown.

Q6. What is a Docker registry?

A registry is a server that stores and distributes images. You docker push a tagged image to it and docker pull to download. There are public registries and private ones teams host themselves. The interview-relevant detail is image tagging: a tag like myapp:1.4.2 identifies a specific version, and relying on latest in production is an anti-pattern because it makes deployments non-reproducible.

Q7. How do you inspect what is happening inside a running container?

docker logs shows the container's stdout and stderr. docker exec -it <container> sh opens a shell inside it to poke around the filesystem and processes. docker inspect dumps the full configuration as JSON (mounts, network, environment). docker stats shows live CPU and memory use. The interview value is showing a debugging workflow: logs first, then exec in to confirm, then inspect for the configuration details.

Q8. What is a .dockerignore file and why does it matter?

A .dockerignore excludes files from the build context that Docker would otherwise send to the daemon. Excluding the .git directory, node_modules, local environment files, and build artifacts speeds up builds, shrinks images, and avoids accidentally baking secrets into a layer. New grads who skip it ship needlessly large images and occasionally leak a local .env file into the build. Worth pairing with the tagging point: relying on the latest tag in production is an anti-pattern because latest can change underneath you, so pin an explicit version tag for reproducible deploys.

Images vs containers and the layer cache (the most-tested pair)

These two topics carry the heaviest weight in a 2026 docker round because they reveal whether you understand Docker under the hood. The image-vs-container follow-up to expect: "if I change a file in a running container and commit it, what do I get?" The answer is a new image with an extra layer capturing your change, which is why docker commit exists but is discouraged (it produces opaque, undocumented images); the repeatable path is editing the Dockerfile and rebuilding. The cache point that earns the round: each instruction produces a layer keyed by the instruction plus the state above it, so the first changed layer invalidates every layer below it. Instruction order is a real performance lever, not a style preference.

Here is the canonical cache-busting comparison interviewers probe. The recommendation column is the part they're grading:

The takeaway candidates miss: a cleanup command in a layer below the thing it's cleaning cannot reclaim the space, because the earlier layer is already frozen. You must clean up in the same RUN that created the mess.

Dockerfile authoring questions (8 Q)

Writing a real Dockerfile is the competency that most separates candidates. These eight questions cover the authoring decisions a mid-level interviewer will push on.

Q11. Walk me through a basic Dockerfile. Name the common instructions in order: FROM picks the base image, WORKDIR sets the working directory, COPY brings files in, RUN executes build commands, EXPOSE documents the port, ENV sets environment variables, and CMD or ENTRYPOINT defines the start process. The signal is explaining why each line exists, not reciting the keyword list.

Q12. What is the difference between CMD and ENTRYPOINT? ENTRYPOINT is the fixed executable that always runs; CMD provides default arguments a user can override at run time. The clean pattern is ENTRYPOINT for the binary and CMD for its default flags. Use the exec form (a JSON array) so signals reach your process for graceful shutdown. Confusing the two is a classic miss.

Q13. What is the difference between COPY and ADD? COPY copies files and directories from the build context into the image, and that's all it does. ADD does the same but also auto-extracts local tar archives and can fetch remote URLs. The 2026 best practice is COPY by default for predictability, reaching for ADD only when you specifically want tar auto-extraction. Defaulting to ADD "because it does more" is the wrong instinct.

Q14. Why does instruction order matter? Because the build cache invalidates the first changed layer and everything below it. Put the least-frequently-changed instructions (base image, dependency manifests, dependency install) at the top and the most-frequently-changed (application source) near the bottom. A one-line code change should never force a full dependency reinstall.

Q15. What is a multi-stage build? A Dockerfile with more than one FROM. An early stage compiles or bundles the app; a later slim stage copies only the finished artifact with COPY --from. Build tools, source, and dev dependencies never reach the final image. It's the highest-impact way to shrink and harden a production image.

Q16. How do you handle secrets in a Dockerfile? Never bake secrets into image layers with ENV or COPY, because every layer is inspectable and a leaked secret lives forever in the image history. Pass secrets at run time via environment variables, mounted files, or build-time secret mounts that don't persist to a layer. New grads frequently leak a database password by copying a .env file into the image.

Q17. What does EXPOSE actually do? EXPOSE documents which port the container listens on; it does not publish the port. You still need -p host:container at docker run (or a ports entry in compose) to make the container reachable from outside. Thinking EXPOSE opens the port to the host is a common misconception worth correcting out loud.

Q18. How do you reduce build time and image size together? Order instructions for cache reuse, use a slim base image, use a multi-stage build, combine and clean up RUN commands in a single layer, and add a .dockerignore. Quote a real number if you have one ("multi-stage took my Node image from about 1.1 GB to roughly 180 MB"). Concrete reductions read as real experience.

Volumes and data persistence questions (5 Q)

Data persistence is a frequent new-grad trap because tutorials rarely remove a container, so the data loss never surfaces until a redeploy.

Q19. Why does my container lose data when I remove and recreate it? Because writes land in the container's thin writable layer, which is destroyed on docker rm. A fresh docker run starts from the immutable image again. Mount a volume at the write path to persist data across the container lifecycle.

Q20. What is the difference between a named volume and a bind mount? A named volume is Docker-managed storage in its own area, portable and the right default for production state like a database. A bind mount maps a specific host directory into the container, ideal for dev-time source mounting but coupled to the host's filesystem layout. Name the use case: volumes for prod state, bind mounts for local development.

Q21. What is an anonymous volume and why is it a footgun? An anonymous volume is created without a name (often implicitly by a VOLUME instruction or a -v /path with no source). It persists data but is hard to find and easy to orphan, so disks fill with dangling volumes nobody can identify. Prefer named volumes you can reference and clean up deliberately.

Q22. How do you back up a Docker volume? Run a throwaway container that mounts both the volume and a host directory, then tar the volume's contents to the host (or restore the other direction). The point is that volumes are just directories Docker manages, so backup is a copy operation, not a magic command. Knowing the pattern signals real operational thinking.

Q23. Where should a database's data live in a containerized app? In a named volume, never in the container's writable layer. The container is disposable and the data is not. In compose, you declare the volume and mount it into the database service's data directory so the database survives docker compose down and up. This is the single most common stateful-service question.

Docker networking questions (5 Q)

Networking questions separate candidates who ran a single container from those who wired several together.

Q24. What are the default Docker network drivers? bridge (the default single-host private network using NAT, with port publishing to reach containers from outside), host (the container shares the host's network stack, no isolation, no port mapping), none (no networking), and overlay (multi-host networking for orchestrated clusters). Name the four and their one-line use cases.

Q25. How do two containers talk to each other? On a user-defined bridge network, containers resolve each other by name through Docker's built-in DNS, so a web container reaches a database as db:5432 rather than chasing an IP. On the default bridge, that automatic name resolution isn't available, which is one reason compose creates a user-defined network for you. Naming the DNS behavior is the signal.

Q26. What does publishing a port with -p actually do? -p host:container maps a port on the host to a port inside the container so external traffic reaches the container's process. EXPOSE only documents the port; -p is what actually opens the path. Mixing these up is the most common networking misconception.

Q27. What is the difference between the bridge and host network drivers? bridge isolates the container on a private network and uses NAT plus port publishing, the safe default. host removes that isolation and binds the container directly to the host's interfaces, which avoids the NAT hop for performance-sensitive workloads but sacrifices isolation and port remapping. The trade-off is isolation versus raw network performance.

Q28. How does DNS work between docker-compose services? Compose puts every service on a shared user-defined network and registers each service name in Docker's internal DNS. A service reaches another by its service name, and Docker load-balances across replicas if there are several. This is why a compose web service connects to postgres://db:5432 with no hard-coded IPs anywhere.

docker-compose questions (4 Q)

Compose is where new grads prove they can run a real multi-container application, not just a single container.

Q29. What is docker-compose and what problem does it solve? It defines a multi-container app in one YAML file (services, images or build contexts, ports, volumes, environment, dependencies) and starts the whole stack with one docker compose up. It solves the pain of starting several docker run commands by hand in the right order with the right flags. It's the standard local-development tool for any app with more than one moving part.

Q30. What does depends_on actually guarantee? It controls start order, not readiness. depends_on ensures the database container starts before the web container, but it does not wait for the database to be ready to accept connections. The new-grad trap is assuming the web service can connect the instant it starts; the fix is a health check the dependent service waits on, or application-level connection retries.

Q31. How do environment variables and .env files work in compose? Compose reads a .env file in the project directory and substitutes variables into the compose file, and you can also set per-service environment under each service. This keeps secrets and config out of the committed YAML. The caution is the same as everywhere: don't commit real secrets, and don't bake them into images.

Q32. When do you outgrow docker-compose? When you need to run across multiple machines, restart failed containers automatically, roll out updates without downtime, and scale replicas horizontally. Compose is single-host and manual about most of that. The honest line is that compose is excellent for local dev and modest single-server deploys, and that scale and availability push you to an orchestrator.

Containers vs VMs and an intro to orchestration (5 Q)

The conceptual close. These questions check whether you understand the boundaries of what Docker is and where it hands off.

Q33. What is the difference between a container and a virtual machine? A VM runs a full guest OS on a hypervisor with its own kernel and boots in tens of seconds to minutes. A container shares the host kernel, isolates processes with namespaces and cgroups, and starts in under a second, so a host packs far more containers than VMs. Containers are lighter but share the kernel, so isolation is weaker. VMs for strong isolation or a different OS; containers for density and speed.

Q34. If containers are lighter, why do VMs still exist? Because kernel sharing is a security and compatibility boundary. You use a VM when you need strong tenant isolation, a different operating system or kernel version, or hardware-level features a container can't reach. Many production stacks run containers inside VMs to get both density and isolation. Saying "containers replaced VMs" is the naive answer; they're complementary.

Q35. What is container orchestration? The automated management of containers across many machines: scheduling which container runs where, restarting failures, rolling out new versions without downtime, scaling replicas, and giving services stable addresses. Docker runs containers on one host; an orchestrator runs them across a fleet. Knowing that boundary is the conceptual line interviewers check.

Q36. What is Kubernetes and how does it relate to Docker? Kubernetes is the dominant orchestrator as of 2026. Docker builds and runs the container images; Kubernetes schedules those containers across a cluster, heals them when they crash, and scales them under load. They're complementary layers, not competitors. The new-grad version is just naming Kubernetes and the build-versus-orchestrate split; the deeper version probes scheduling and self-healing.

Q37. What does "self-healing" mean in an orchestrator? The orchestrator continuously compares the desired state (run three replicas of this service) against the actual state and corrects drift automatically: if a container crashes or a node dies, it reschedules a replacement without a human paging in. Pair this with rolling updates (replace old containers with new ones gradually, with rollback on failure) and you've described the two features that justify moving from compose to an orchestrator.

Common docker interview mistakes for new grads

The five most-reported mistakes from new-grad docker rounds in the 2025-2026 hiring cycle, with the fix for each.

Confusing images and containers. Candidates blur the template and the instance, then stumble on every follow-up about persistence and immutability. The fix is the class-and-object framing plus the writable-layer point: the image never changes, the container's writes are disposable.

Misordering Dockerfile instructions. Putting COPY . . above the dependency install busts the cache on every code edit and signals you've never optimized a real build. The fix is to copy the dependency manifest and install before copying the source, so a one-line change leaves the install layer cached.

Assuming EXPOSE publishes a port. New grads think EXPOSE opens the container to the host, then can't reach their app. The fix is knowing EXPOSE only documents the port and -p host:container (or a compose ports entry) is what actually publishes it.

Storing state in the container instead of a volume. Data vanishes on the next docker rm and the candidate can't explain why. The fix is mounting a named volume for any stateful service and being able to say which path the data lives at and why it survives the container.

Treating depends_on as a readiness guarantee. Candidates assume the web service can connect the moment the database container starts. The fix is knowing depends_on controls start order only, and that readiness needs a health check or application-level retries.

One founder's note from watching new grads run these rounds: don't try to memorize all five the night before. Pick the two that match your gaps (almost always the image-vs-container model and Dockerfile cache ordering) and close those with hands-on practice. The rest follow once the foundation is solid. If you want to rehearse the build-and-debug scenarios out loud and react to a model answer in your own words, a live interview assistant you can start for a $3 trial gives you on-demand docker scenarios so the rep cost is a coffee, not a friend's afternoon.

Related guides

• Kubernetes interview questions: the orchestration layer Docker hands off to, and the natural next round after a docker screen.
• AWS interview questions: the cloud platform that runs your containers in production via its managed container services.
• System design basics for new grads: where containerized services slot into a larger architecture, which scenario rounds build on.
• Mock interview practice: how to drill these build-and-debug questions under realistic timing pressure.

About the author: Sam K. is the founder of InterviewChamp.AI, building AI interview prep for the new-grad CS market and writing about the modern interview gauntlet from the inside.