Docker Interview Questions and Answers, Basic to Advanced

A Docker interview is rarely a quiz on memorized definitions. Interviewers want to see whether you understand how containers actually work under the hood, why you would reach for one approach over another, and whether you can debug a broken image without panicking. This guide collects real Docker interview questions, grouped from basic to advanced, covering images versus containers, Dockerfiles, volumes, networking, Compose, multi-stage builds, and security.

Each question includes a concise, technically correct answer and a note on what the interviewer is usually probing for. Read them as conversation starters, not flashcards. The strongest candidates anchor answers in a real project — "we cut our image from 1.2 GB to 90 MB with a multi-stage build" lands far better than reciting the docs. Where you lack hands-on experience, say so and reason from first principles.

Here is how the questions are organized:

• Basic — core concepts every Docker user should know: images, containers, the Dockerfile, and basic commands.
• Intermediate — volumes, networking, Docker Compose, and the container lifecycle.
• Advanced — multi-stage builds, image optimization, security, and orchestration trade-offs.

Basic Docker interview questions

These appear in nearly every screen. Get them crisp and correct — fumbling the fundamentals signals you have only used Docker by copy-pasting commands.

What is Docker, and what problem does it solve?

Docker is an open platform for building, shipping, and running applications in containers. A container packages an application together with all of its dependencies — libraries, runtime, system tools — into a single unit that runs identically on a laptop, a CI runner, and production. This kills the "works on my machine" class of bug and makes deployments reproducible. The official docs describe a container as "a loosely isolated environment" that includes everything the application needs to run.

What is the difference between a Docker image and a container?

This is the most common Docker interview question, so answer it precisely. An image is "a read-only template with instructions for creating a Docker container." A container is "a runnable instance of an image." The relationship mirrors classes and objects in programming: the image is the blueprint, the container is the running instance. You can start many containers from one image, and each gets its own writable layer on top of the shared read-only image layers.

How do containers differ from virtual machines?

A VM virtualizes the full hardware stack and runs its own guest operating system on top of a hypervisor. Docker does not. It uses Linux kernel features — namespaces for isolation and cgroups for resource limits — so containers share the host kernel instead of booting a separate OS. The docs note Docker uses "a technology called namespaces to provide the isolated workspace called the container." The practical result: containers start in milliseconds, use far less memory, and pack more densely onto a host. The trade-off is weaker isolation than a true VM, which matters for multi-tenant security.

What is a Dockerfile?

A Dockerfile is a text file with the build instructions needed to assemble an image. Each instruction (FROM, RUN, COPY, CMD, and so on) creates a layer. The interviewer often follows up by asking you to read or write one, so be comfortable with the common instructions:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

What is the difference between CMD and ENTRYPOINT?

Both define what runs when the container starts, but they behave differently when you pass arguments. ENTRYPOINT sets the fixed executable; CMD provides default arguments that are easy to override at docker run. A common pattern combines them: ENTRYPOINT ["python", "app.py"] with CMD ["--port", "8080"] lets a user override only the flags. If you specify just CMD, anything passed to docker run replaces it entirely.

What is the difference between COPY and ADD?

Both copy files into the image. COPY does exactly that and nothing more. ADD also auto-extracts local tar archives and can fetch remote URLs. Best practice is to prefer COPY for clarity and predictability, and reach for ADD only when you specifically need tar extraction.

Intermediate Docker interview questions

Once the basics are solid, interviewers probe how you handle state, connectivity, and multi-container setups — the things that bite you in real deployments.

How do you persist data in Docker?

Containers are ephemeral: delete one and its writable layer goes with it. To keep data, you mount storage from outside the container. Docker volumes are the recommended approach — they are "persistent data stores for containers, created and managed by Docker" and live "outside the lifecycle of a given container." Create and attach one like this:

docker volume create app-data
docker run -d -v app-data:/var/lib/data my-app

What is the difference between a volume and a bind mount?

Both put data outside the container's writable layer, but ownership differs. A volume is "completely managed by Docker and isolated from the core functionality of the host machine," which makes it portable and the recommended choice for databases and other persistent data. A bind mount maps a specific host directory straight into the container, so it depends on the host's filesystem layout — handy for mounting source code during local development, but less portable. Volumes are also faster than writing into the container's writable layer, which adds storage-driver overhead.

How does container networking work?

By default Docker connects containers to a bridge network, the standard driver. The main drivers an interviewer expects you to name:

A good follow-up answer: on a user-defined bridge network, containers resolve each other by name through Docker's built-in DNS, which is why Compose services can talk to each other using the service name as a hostname.

What is Docker Compose, and when would you use it?

Docker Compose defines and runs multi-container applications from a single declarative YAML file. Instead of running several long docker run commands by hand, you describe the services, networks, and volumes once and bring the whole stack up with one command:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data:

docker compose up -d

Use it for local development and small single-host deployments. For production clusters across multiple machines, you move to an orchestrator like Kubernetes.

What happens when you run docker run?

Walk the interviewer through the lifecycle: Docker checks for the image locally, pulls it from a registry like Docker Hub if it is missing, creates a container with its own writable layer, attaches it to a network, and starts the process defined by ENTRYPOINT/CMD as PID 1 inside the container. Mentioning PID 1 is a strong signal, because it leads naturally into signal handling and graceful shutdown.

What is the difference between docker stop and docker kill?

docker stop sends SIGTERM and waits a grace period (10 seconds by default) before sending SIGKILL, giving the process a chance to clean up. docker kill sends SIGKILL immediately, terminating the process with no cleanup. Use stop in normal operation; reserve kill for a hung container.

Advanced Docker interview questions

Senior and SRE loops push toward optimization, security, and the decisions that separate someone who *uses* Docker from someone who *operates* it at scale.

What is a multi-stage build, and why does it matter?

A multi-stage build uses multiple FROM statements in one Dockerfile, where each FROM begins a new stage. You build the application in a heavy stage with compilers and dev dependencies, then copy only the finished artifact into a small runtime stage — "leaving behind everything you don't want in the final image." The payoff is a dramatically smaller, more secure final image because build tools never ship to production.

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"]

How do you reduce Docker image size?

Hit several levers: start from a minimal base image (alpine, slim, or distroless), use multi-stage builds to drop build dependencies, combine RUN commands to minimize layers, add a .dockerignore so you do not copy node_modules or .git into the build context, and clean package-manager caches in the same layer they are created. Smaller images pull faster, cost less to store, and present a smaller attack surface.

How do Docker layers and the build cache work?

Each Dockerfile instruction creates a read-only layer, and Docker caches each one. On rebuild, Docker reuses cached layers up to the first instruction whose inputs changed, then rebuilds everything after it. This is why ordering matters: copy your dependency manifest and install dependencies *before* copying the rest of your source. Source code changes often, but dependencies rarely do — so the expensive install layer stays cached across most builds.

What are the main security concerns with Docker, and how do you address them?

Containers share the host kernel, so a container escape is a host compromise. Demonstrate layered thinking:

• Do not run as root — add a non-root USER in your Dockerfile so a compromised process has limited privileges.
• Use trusted, minimal base images and pin specific versions rather than latest.
• Scan images for vulnerabilities in CI before they ship.
• Never bake secrets into images — pass them at runtime via environment variables, a secrets manager, or Docker secrets, because image layers are inspectable.
• Drop unneeded Linux capabilities and avoid the --privileged flag unless absolutely required.

When would you choose Kubernetes over Docker Compose?

Compose is excellent for local development and a single host, but it does not handle scheduling across many machines, self-healing, autoscaling, or rolling updates with health checks. Kubernetes provides those, declaratively managing containerized workloads across a cluster. The honest answer names the cost: Kubernetes adds real operational complexity, so you adopt it when you genuinely need multi-host orchestration — not by default for a hobby project.

How do you debug a container that keeps crashing?

Show a methodical approach rather than random restarts. Check docker logs <container> for the application error first. Inspect exit codes and configuration with docker inspect. If the container exits too fast to investigate, override the entrypoint to get a shell — docker run -it --entrypoint sh <image> — and reproduce the failure manually. Verify the process is honoring SIGTERM so it shuts down cleanly, and confirm any required volumes, environment variables, and network connections are actually present.

How to prepare beyond the questions

Memorizing answers gets you only so far. Three things move the needle in a real Docker interview:

• Build something end to end. Containerize a small app with a multi-stage build, a volume for state, and a Compose file. The questions above will answer themselves once you have shipped it.
• Know the trade-offs, not just the definitions. Interviewers reward "here's when I would *not* use this" far more than textbook recall.
• Research who is interviewing you. Knowing whether your interviewer cares most about security, scale, or developer experience lets you steer your examples toward what they value.

That last point is where most candidates leave easy points on the table. If you can find the engineer or hiring manager running your loop and learn what their team actually works on, you walk in able to tailor every answer. Articuler is built for exactly that — semantic search across 980M+ professional profiles to find the right person behind a role, a Playbook that prepares you for *that specific* conversation, and AI-drafted outreach that gets roughly 8x the reply rate of a generic cold message. The Docker fundamentals get you to the door; knowing the room gets you through it.

For more role-specific prep, see our guides on DevOps interview questions, AWS interview questions, and broader technical interview questions. If your loop includes orchestration, the Kubernetes-heavy DevOps track pairs well with this one, and Articuler's AI meeting prep can build a Playbook on your actual interviewer.

FAQ

What are the most common Docker interview questions?

The most frequent are the difference between an image and a container, how containers differ from virtual machines, what a Dockerfile is, how to persist data with volumes, and what a multi-stage build does. Expect at least one of these in any Docker screen.

Do I need to memorize Docker commands for an interview?

Know the core commands — docker run, build, ps, logs, exec, volume, and compose up — well enough to use them fluently. Interviewers care more that you understand what each command does and can debug with them than that you can recite every flag from memory.

What is the difference between a volume and a bind mount in Docker?

A volume is fully managed by Docker and stored in Docker's own area, making it portable and the recommended choice for persistent data like databases. A bind mount maps a specific host directory into the container and depends on the host's filesystem, which is convenient for mounting source code during local development.

How do I answer advanced Docker questions if I am junior?

Be honest about your level and reason from first principles. If asked about multi-stage builds or security and you have not done them, explain the concept and what you would research before implementing it. Interviewers respect honest reasoning over confident bluffing.