Skip to content
DevOps AI ToolKit
Newsletter
All guides
Docker with AI By James Joyner IV · · 12 min read

Docker Interview Questions and Answers (2026): 15 to Practice

15 common Docker interview questions and answers for DevOps, cloud, and SRE roles — with model answers covering containers, Dockerfiles, networking, Compose, security, and troubleshooting.

  • #docker
  • #interview
  • #devops
  • #containers

Preparing for a Docker or DevOps interview? This guide walks through common Docker interview questions and answers — the kind that come up for DevOps, cloud, platform, and SRE roles — with model answers you can actually say out loud. It’s a free sample from the Docker Interview & Certification Prep Kit, which has 200 graded questions, 10 troubleshooting scenarios, a command cheat sheet, a whiteboard guide, and a two-week study plan.

Want the printable version? Download 40 free Docker interview questions and answers as a PDF — no cost, covers fundamentals through troubleshooting.

1. What is a Docker container, and how does it differ from a virtual machine?

Short answer. A container is an isolated process that shares the host OS kernel, while a VM runs a full guest OS on top of a hypervisor.

A Docker container is a lightweight, isolated runtime for a process (or group of processes) created from an image. Unlike a virtual machine, it shares the host’s Linux kernel rather than booting its own guest OS, so it starts in milliseconds and uses far less memory and disk. Isolation is provided by kernel features like namespaces (PID, net, mount, UTS) and cgroups (resource limits), not by a hypervisor. A VM virtualizes hardware and runs a complete OS, giving stronger isolation but heavier footprint. Containers are portable because the image bundles the app and its dependencies, but they are not full machines.

Topic: Container vs VM · Level: Beginner

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

Short answer. An image is a read-only template; a container is a running (or stopped) instance created from that image.

A Docker image is an immutable, read-only template made up of stacked filesystem layers plus metadata (entrypoint, env, exposed ports). A container is a runnable instance of an image: when you run one, Docker adds a thin writable layer on top of the image’s read-only layers and starts the specified process. You can create many containers from the same image, and each gets its own writable layer and isolated view of the system. Changes made inside a running container live in that writable layer and are lost when the container is removed unless you commit them or use a volume. The relationship is analogous to a class (image) and an object instance (container).

Topic: Image vs container · Level: Beginner

3. What is a Docker registry, and how does it relate to a repository and a tag?

Short answer. A registry is a service that stores and distributes images; a repository is a named collection of related images within it, and a tag identifies a specific version.

A Docker registry is a server that stores and serves images, such as Docker Hub, GitHub Container Registry, or a private Harbor instance. Within a registry, a repository is a named bucket that holds different versions of an image, for example nginx or myorg/api. A tag identifies a particular image version inside a repository, like nginx:1.27-alpine, and when omitted Docker defaults to latest. A full reference looks like registry-host/namespace/repository:tag, e.g. ghcr.io/myorg/api:1.2.0. You pull with docker pull and push with docker push after logging in via docker login.

Topic: Docker registry · Level: Beginner

4. Explain Docker’s client-server architecture.

Short answer. The Docker CLI is a client that talks to the Docker daemon (dockerd) over a REST API; the daemon does the actual work of building, running, and managing containers.

Docker uses a client-server model. The docker CLI is the client and communicates with the Docker daemon, dockerd, through a REST API over a Unix socket (/var/run/docker.sock) or a TCP endpoint. The daemon is the server that builds images, pulls from registries, and creates and runs containers by talking to a lower-level runtime (containerd and runc). Because the client and daemon are decoupled, the CLI can control a daemon on the same host or a remote one via DOCKER_HOST. This separation is why a single command like docker run triggers work in a long-running background process rather than in the CLI itself.

Topic: Docker architecture · Level: Beginner

5. What is the Docker daemon and what is it responsible for?

Short answer. The Docker daemon (dockerd) is the background service that builds, runs, and manages images, containers, networks, and volumes.

The Docker daemon, dockerd, is a long-running background process that listens for Docker API requests and manages Docker objects: images, containers, networks, and volumes. It handles building images, pulling and pushing to registries, and creating containers, delegating the actual container lifecycle to containerd and the OCI runtime runc. It typically listens on the Unix socket /var/run/docker.sock and runs as root, which is why socket access effectively grants root-level control of the host. On systemd hosts you manage it with commands like systemctl status docker and systemctl restart docker.

Topic: Docker daemon · Level: Beginner

6. Walk me through what happens when you run docker run -d --name web -p 8080:80 nginx:1.27-alpine.

Short answer. Docker pulls the image if missing, creates a container from it, publishes host port 8080 to container port 80, and starts it detached in the background named web.

First the daemon checks for the nginx:1.27-alpine image locally; if it is not present it pulls it from the registry. It then creates a container from that image with a writable layer and names it web. The -p 8080:80 flag publishes container port 80 to port 8080 on the host, so requests to the host’s 8080 are forwarded into the container. The -d flag runs it detached, so the container runs in the background and the CLI returns the container ID immediately. The container starts by executing the image’s default command (nginx in the foreground), and you can then reach it at http://localhost:8080.

Topic: Run a container · Level: Beginner

7. What does the -p flag do, and how does it differ from EXPOSE in a Dockerfile?

Short answer. -p actually publishes a container port to the host so it is reachable externally, while EXPOSE only documents which port the container listens on.

The -p (or —publish) flag on docker run maps a container port to a host port, for example -p 8080:80 forwards host port 8080 to container port 80 via the daemon’s port-forwarding rules. EXPOSE in a Dockerfile is purely documentation and metadata; it declares which ports the app listens on but does not open or map anything by itself. To actually publish EXPOSE-declared ports you still need -p, or -P (uppercase) which publishes all exposed ports to random high host ports. So EXPOSE informs image users and tools, while -p is what makes the service reachable from outside the container.

Topic: Port publishing · Level: Beginner

8. Describe the main states in a container’s lifecycle and the commands that move between them.

Short answer. A container goes created -> running -> paused/stopped -> removed, driven by docker create/run, start, pause/unpause, stop/kill, and rm.

docker create makes a container in the created state without starting it, and docker run creates and starts it in one step (running). docker stop sends SIGTERM then SIGKILL after a grace period to move a running container to exited, while docker kill sends SIGKILL immediately. docker pause and docker unpause freeze and resume processes using the freezer cgroup. A stopped container still exists and can be restarted with docker start, keeping its writable layer, until you delete it with docker rm. docker ps shows running containers and docker ps -a shows all states including exited.

Topic: Container lifecycle · Level: Beginner

9. How do you view the logs of a running container, and where do those logs come from?

Short answer. Use docker logs ; by default it captures whatever the main process writes to stdout and stderr.

You view logs with docker logs , adding -f to follow in real time and —tail 100 to show only the last lines. Docker captures the container’s stdout and stderr streams via its logging driver, json-file by default, and stores them on the host under the container’s directory. This is why the twelve-factor practice of logging to stdout/stderr matters: apps that write to a log file inside the container will show nothing in docker logs. You can also use —since and —timestamps for filtering, and swap logging drivers (for example json-file, local, or syslog) in the daemon or per container.

Topic: Container logs · Level: Beginner

10. Which commands do you use to list, pull, tag, and remove images, and what do they do?

Short answer. docker images (or docker image ls) lists, docker pull downloads, docker tag adds a reference, and docker rmi removes images.

docker images or docker image ls lists local images with repository, tag, image ID, and size. docker pull nginx:1.27-alpine downloads an image and its layers from a registry. docker tag nginx:1.27-alpine myrepo/nginx:1.27 creates an additional name pointing at the same image ID, which is how you prepare an image for pushing to another registry. docker rmi removes an image by name or ID, and it fails if a container still references it unless you force it. docker image prune cleans up dangling images to reclaim space.

Topic: Basic image operations · Level: Beginner

11. What is a Dockerfile, and what is the general structure of the instructions it contains?

Short answer. A Dockerfile is a plain-text file of ordered instructions that Docker reads to build an image automatically and reproducibly.

A Dockerfile is a text document containing the commands a user could call on the command line to assemble an image. It is processed top-to-bottom by docker build, and most instructions (FROM, RUN, COPY, ADD) create a new read-only layer. Instructions are written as INSTRUCTION arguments, with the instruction keyword conventionally uppercased. The first non-comment instruction must be FROM (optionally preceded by ARG), which sets the base image, and subsequent instructions like RUN, COPY, ENV, and CMD build on top of it. The build produces an immutable image that can be tagged, pushed, and run.

Topic: Dockerfile structure · Level: Beginner

12. What does the FROM instruction do, and why should you avoid using the latest tag for a base image?

Short answer. FROM sets the base image every subsequent instruction builds on; latest is a moving tag that makes builds non-reproducible.

FROM initializes a new build stage and sets the base image, e.g. FROM python:3.12-slim. It must be the first instruction (aside from a preceding ARG) and it can appear multiple times for multi-stage builds. Using FROM python:latest is risky because latest is just a floating tag that maintainers repoint over time, so the same Dockerfile can produce different images on different days. Pinning a specific version tag (or, more strictly, a digest like python@sha256:...) gives predictable, reproducible builds. FROM scratch is a special empty base used for minimal or statically compiled images.

Topic: FROM instruction · Level: Beginner

13. What does the RUN instruction do, and what is the difference between its shell form and exec form?

Short answer. RUN executes a command during the build to modify the image; shell form runs via /bin/sh -c, exec form runs the binary directly with no shell.

Topic: RUN instruction · Level: Beginner

14. What does the COPY instruction do, and how does the build context affect what it can copy?

Short answer. COPY copies files and directories from the build context into the image; it can only access paths inside that context.

Topic: COPY instruction · Level: Beginner

15. What is the purpose of the CMD instruction, and what happens if you specify it more than once?

Short answer. CMD sets the default command/arguments for a container; only the last CMD in the Dockerfile takes effect.

Topic: CMD instruction · Level: Beginner

How to prepare for a Docker technical interview

Reading answers is a start, but interviews are spoken and hands-on. A few tactics that work:

  • Answer out loud. Say each answer as if to an interviewer before you check the model answer.
  • Practice on a whiteboard. Be ready to draw containers vs VMs, namespaces and cgroups, and Docker’s layer cache.
  • Break and fix real containers. Diagnosing a broken container under pressure is the single most common practical test. Practice with the free Docker Academy labs: run your first container, repair a broken nginx container, and fix a restart loop.
  • Structure your study. A focused two-week plan beats cramming — the full kit includes one mapped to hands-on labs.

Get all 200 questions

The complete Docker Interview & Certification Prep Kit ($19, one-time) adds 185 more questions with full model answers, 10 “Here’s a Broken Container — Diagnose It” scenarios, a command cheat sheet, a whiteboard explanation guide, and a two-week study plan. Or start with the free 40-question PDF.

This is an independent educational resource. It is not an official Docker certification product and is not endorsed by Docker, Inc. “Docker” is a trademark of Docker, Inc.

Newsletter

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 2,778 DevOps AI prompts
  • One practical workflow email per week
Free download · 368-page PDF

Get 500 Battle-Tested DevOps AI Prompts — Free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.