Docker Interview Questions and Answers

Docker appears in almost every interview for .NET, Python, DevOps and cloud roles. Interviewers usually start with the basics (what Docker is, images vs containers), then check practical understanding: Dockerfile instructions, port mapping, the container lifecycle and networking. This page answers the 15 questions asked most often, each with a short answer you can say in the interview, followed by an explanation and, where useful, a real example.

For hands-on practice, follow the Docker tutorial series: every concept below is shown there with real command output.

Quick reference

1. What is Docker?

Answer: Docker is an open-source platform for building, shipping and running applications in containers. A container packages the application with everything it needs (runtime, libraries, configuration), so it runs the same way on a developer laptop, a test server and in the cloud.

Explanation: Docker solves the classic "it works on my machine" problem. Instead of installing the .NET runtime, Python packages or a database on every server, you build an image once and run it anywhere Docker is installed. Docker includes the tools to build images (docker build), store and share them (registries such as Docker Hub) and run them (docker run).

2. What is containerization?

Answer: Containerization is packaging an application and its dependencies into a lightweight, isolated unit, a container, that runs as an isolated process on a shared operating-system kernel.

Explanation: Unlike virtualization, which emulates hardware and runs a full guest OS, containerization isolates only the application. On Linux this isolation comes from kernel features:

• Namespaces give each container its own view of processes, network, file system, hostname and users.
• Control groups (cgroups) limit how much CPU and memory a container can use.
• Layered file systems (overlayfs) let many containers share the same read-only image layers.

Benefits: consistency across environments, fast start-up (seconds or less), high density (many containers per server), and easy scaling.

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

Answer: An image is a read-only template containing the application and its environment. A container is a runnable instance of an image, with its own writable layer and processes. It's like a class and an object.

4. Explain Docker architecture.

Answer: Docker uses a client-server architecture with four main parts: the Docker client (CLI) sends commands through a REST API to the Docker daemon, which builds, runs and manages Docker objects (images, containers, networks, volumes) and pulls or pushes images from a registry such as Docker Hub.

  Docker Client          Docker Host                          Registry
  (docker CLI)  --API-->  Docker Daemon (dockerd)  <--pull/push-->  Docker Hub,
                            |-- images                               ECR, ACR ...
                            |-- containers (via containerd + runc)
                            |-- networks
                            |-- volumes

Explanation: When you run docker run nginx: the client sends the request to the daemon; the daemon checks for the image locally and pulls it from the registry if needed; then it asks containerd to create the container, and runc sets up the namespaces and cgroups and starts the process. The full architecture, with diagrams, is explained in Docker architecture, and the hello-world lab shows these exact steps in real output.

5. What is the Docker daemon?

Answer: The Docker daemon (dockerd) is the background service on the Docker host that listens for Docker API requests and does the actual work: building images, running and stopping containers, and managing networks and volumes.

Explanation: The docker command is only a client; without a running daemon it can't do anything. That's why docker --version works when Docker Desktop is closed but docker ps fails. On Windows and macOS the daemon runs inside a small Linux VM managed by Docker Desktop. The daemon delegates low-level container execution to containerd and runc. Check it with docker info or docker version, which show a "Server" section only when the daemon is reachable (see Install Docker Desktop on Windows 11).

6. What is Docker Hub?

Answer: Docker Hub is Docker's public, cloud-based registry where images are stored and shared. It is the default registry: docker pull nginx downloads docker.io/library/nginx:latest from Docker Hub.

Explanation:

• Official images (nginx, python, redis, postgres) live under library/ and are maintained and scanned.
• Anyone can push public or private repositories under their own account (docker push username/app:1.0).
• Microsoft's .NET images are on its own registry, mcr.microsoft.com; companies often use private registries such as AWS ECR, Azure ACR or GitHub Container Registry.
• Anonymous and free accounts have pull rate limits.

7. What is a Dockerfile?

Answer: A Dockerfile is a plain-text file with step-by-step instructions that Docker follows to build an image: which base image to start from, which files to copy, which commands to run, and how to start the application.

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY main.py .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Explanation: Each instruction creates a layer, and unchanged layers are reused from the build cache. That's why dependencies are installed before the code is copied. Common instructions: FROM, WORKDIR, COPY, RUN, ENV, EXPOSE, USER, CMD and ENTRYPOINT. Complete examples: ASP.NET Core multi-stage Dockerfile and Python FastAPI Dockerfile.

8. What is the difference between RUN and CMD?

Answer: RUN executes a command while the image is being built and saves the result as a new layer. CMD sets the default command that runs when a container starts; nothing is executed at build time.

9. What is the difference between CMD and ENTRYPOINT?

Answer: Both define what runs when the container starts. CMD is a default that is replaced by any command you pass after the image name in docker run. ENTRYPOINT defines the fixed executable; arguments you pass are appended to it, and it's replaced only with --entrypoint.

# Dockerfile with CMD only
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

docker run python-fastapi:1.0                                   # runs the CMD
docker run python-fastapi:1.0 uvicorn main:app --host 127.0.0.1 # CMD is replaced completely

# Dockerfile with ENTRYPOINT (the ASP.NET Core image)
ENTRYPOINT ["dotnet", "DotnetDay1.dll"]

docker run dotnet-day1:1.0 --urls http://+:5000   # runs: dotnet DotnetDay1.dll --urls http://+:5000

Used together, ENTRYPOINT is the program and CMD supplies its default arguments:

ENTRYPOINT ["ping"]
CMD ["localhost"]
# docker run img           -> ping localhost
# docker run img google.com -> ping google.com

Prefer the exec form (JSON array) for both. The shell form (CMD uvicorn main:app) runs the app under /bin/sh -c, so the app doesn't receive the SIGTERM sent by docker stop and gets killed after the timeout.

10. What is port mapping in Docker?

Answer: Port mapping (publishing) forwards a port on the host to a port inside the container, so the application can be reached from outside. It's set with -p HOST_PORT:CONTAINER_PORT.

docker run -d -p 8080:80 nginx                     # host 8080 -> Nginx on 80
docker run -d -p 8081:8080 dotnet-day1:1.0         # host 8081 -> Kestrel on 8080
docker run -d -p 8002:8000 python-fastapi:1.0      # host 8002 -> Uvicorn on 8000

Explanation: Containers have their own network namespace, so without -p they can't be reached from the host's browser. EXPOSE in a Dockerfile only documents the port; -p actually opens it. A host port can be used by only one container at a time; otherwise you get Bind for 0.0.0.0:8080 failed: port is already allocated (see the Nginx lab). -P publishes all exposed ports to random host ports.

11. What is the difference between docker stop and docker rm?

Answer: docker stop gracefully stops a running container (SIGTERM, then SIGKILL after 10 seconds) but keeps it: its name, settings and writable layer remain, and docker start brings it back. docker rm deletes a stopped container permanently, including its writable layer.

Real error when removing a running container: cannot remove container "web-demo": container is running: stop the container before removing or force remove. More in the container lifecycle lab.

12. Can multiple containers be created from one image?

Answer: Yes. An image is a read-only template, and every docker run creates a new, independent container from it. All the containers share the image's read-only layers on disk; each one gets only its own thin writable layer, its own processes, network namespace and name.

docker run -d --name web1 -p 8080:80 nginx
docker run -d --name web2 -p 8081:80 nginx
docker run -d --name web3 -p 8082:80 nginx

Three independent web servers from one image. The only rules: unique container names and unique host ports. This is exactly how applications are scaled horizontally, by running more containers of the same image behind a load balancer.

13. What is the difference between a Docker container and a virtual machine?

Answer: A virtual machine virtualises hardware and runs a complete guest operating system with its own kernel on a hypervisor. A container virtualises at the operating-system level: it shares the host's kernel and isolates only the application's processes.

They're often combined: in the cloud, containers usually run inside VMs (for example on EC2 instances).

14. Why do we use -d in docker run?

Answer: -d (detached) runs the container in the background and returns the terminal immediately, printing only the container ID. Without it, the terminal is attached to the container's output, and pressing Ctrl+C usually stops the container.

Explanation: Long-running services such as web servers and APIs are almost always started with -d. You then read their output with docker logs (or follow it with docker logs -f) and reattach with docker attach if needed. Short tasks, such as a one-off script or hello-world, are usually run without -d so you see the output directly. Don't confuse it with -it, which is for interactive sessions.

15. Why should an application listen on 0.0.0.0 inside a container?

Answer: Because port publishing forwards traffic to the container's network interface (eth0), not to its loopback. An application bound to 127.0.0.1 only accepts connections from inside the same container, so it can't be reached from the host. Binding to 0.0.0.0 listens on all interfaces, including the one Docker forwards to.

Real example: starting Uvicorn with --host 127.0.0.1 in a container published as -p 8002:8000:

INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
curl http://localhost:8002/  ->  curl: (52) Empty reply from server

The container is Up and the log looks fine, yet the browser gets no response. From inside the container the same URL works. Changing to --host 0.0.0.0 fixes it. Each container has its own 127.0.0.1, meaning "this container", not "my computer". ASP.NET Core images already listen on all interfaces (http://[::]:8080). Full walkthrough: Dockerize a Python FastAPI app.

Tips for answering Docker questions

• Use the class/object analogy for image vs container, and the shipping container analogy for Docker itself.
• Mention namespaces and cgroups when asked how isolation works; it shows you understand containers aren't VMs.
• Give practical examples with real ports and commands; interviewers value hands-on experience.
• Know the follow-ups: volumes for persistent data, user-defined networks for container-to-container calls, multi-stage builds for smaller images, and Docker Compose for multi-container apps.

Related tutorials

• Docker Introduction and Fundamentals
• Docker Container Lifecycle
• Docker Logs and Exec
• Dockerize an ASP.NET Core App
• All interview questions