Docker interview questions

The fundamentals

• Image versus container - a class and an instance is the usual analogy, and it holds.
• How does a container differ from a VM? Shared kernel, namespaces and cgroups for isolation, no guest OS.
• What are namespaces and cgroups actually doing?
• Where does container data go when the container is removed, and what are volumes for?
• What does `docker exec` let you do that `docker run` does not?

Layers and caching, the question behind the question

• Each instruction creates a layer; layers are cached and invalidated from the first change onward.
• The classic mistake: copying the whole source tree before installing dependencies, so every code change reinstalls everything. Copy the manifest, install, then copy the source.
• Why does deleting a file in a later layer not shrink the image? The earlier layer still contains it - which is why a secret written then deleted is still in the image.
• Multi-stage builds - compile in one stage, copy only the artefact into a minimal runtime stage.
• Why is `latest` a poor tag for production?

Dockerfile review

You may be handed a Dockerfile and asked what is wrong with it. The things to spot:

• Running as root when the process does not need to.
• A heavy base image where a slim or distroless one would do.
• Dependency installation placed after the source copy, defeating the cache.
• Secrets passed as build arguments and baked into history.
• No `.dockerignore`, so the build context ships the git history and local modules.
• Several `RUN` commands that should be chained, each adding a layer.

Networking and operations

Bridge versus host networking, how published ports work, and how containers resolve each other by name in a compose network. Then the operational questions: how you would shrink an image, how you handle logs from a container, and what a health check adds. This leads directly into orchestration - see Kubernetes interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and honesty about what you have not done reads better than bluffing.
• Mid-level: the same ground, plus images you have built and shipped. Expect follow-ups asking why you made a particular choice rather than whether you know the syntax.
• Senior: a build you made substantially faster or smaller, with the numbers. At this level the language questions get shorter and the judgement questions get longer.

Whatever the level, the reliable way to prepare is to say your answers out loud rather than reading them. Most of what candidates lose in a Docker interview is lost in the gap between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Docker interview questions?

The difference between an image and a container, how containers differ from virtual machines, how layer caching works and how Dockerfile ordering affects it, multi-stage builds, and reviewing a Dockerfile for mistakes.

Why does Dockerfile instruction order matter?

Each instruction creates a cached layer, and a change invalidates that layer and everything after it. Copying your whole source before installing dependencies means every code edit reinstalls all dependencies - copying the manifest, installing, then copying source keeps the expensive layer cached.

If you delete a file in a Dockerfile, is it gone from the image?

No. The earlier layer still contains it, so the data remains in the image history even though it is not visible in the final filesystem. This is why a secret that is written and later deleted is still recoverable, and it is a common interview trap.

What is a multi-stage build?

A Dockerfile with several `FROM` stages where you build or compile in one stage and copy only the resulting artefact into a minimal runtime stage. It keeps compilers and build dependencies out of the shipped image, cutting both size and attack surface.