40 Free Docker Interview Questions and Answers

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.

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).

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.

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.

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.

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.

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.

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.

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

You view logs with docker logs <container>, 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.

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.

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.

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.

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.

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

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

Short answer. WORKDIR sets the working directory for subsequent instructions and the container's default runtime directory; `RUN cd` only affects that single RUN.

Short answer. EXPOSE documents which ports the container listens on; it does not publish them—you still need `-p` at runtime.

Short answer. A tag is a human-readable label on an image, formatted as `registry/repository:tag`; omitting parts defaults to Docker Hub and `latest`.

Short answer. Docker creates a default `bridge` network (docker0); containers without an explicit `--network` attach to it automatically.

Short answer. Use `-p hostPort:containerPort` to publish a port; `-p 8080:80` maps host port 8080 to container port 80.

Short answer. It removes network isolation and shares the host's network stack, so the container uses the host's interfaces and ports directly.

Short answer. User-defined bridges provide Docker's embedded DNS server for automatic name resolution; the default bridge does not.

Short answer. Use `docker network create` with `--subnet` and `--gateway`, then `--network` at run time or `docker network connect`.

Short answer. `--network none` gives the container only a loopback interface and no external connectivity, fully isolating it from networking.

Short answer. A named volume is Docker-managed persistent storage; create it with `docker volume create` and mount it with `-v name:/path`.

Short answer. The container's writable layer is deleted with the container; persist data by writing it to a volume or bind mount.

Short answer. Named volumes have a human-chosen name, anonymous volumes get a random ID, and bind mounts map an explicit host path.

Short answer. Run a throwaway container that mounts both the volume and a host directory, then tar the volume's contents in and out.

Short answer. The container process UID/GID doesn't match the files' ownership; fix by aligning UIDs, chowning, or using `--user`.

Short answer. Docker Compose is a tool for defining and running multi-container applications declaratively from a single YAML file. It replaces long chains of manual `docker run` commands with one versioned configuration.

Short answer. Compose looks for `compose.yaml`/`compose.yml` first, then the legacy `docker-compose.yaml`/`docker-compose.yml`. You override this with the `-f` flag.

Short answer. A service is a definition of how to run one component of your app (image, config, ports). At runtime Compose creates one or more containers (replicas) from that single service definition.

Short answer. `up` creates and starts the whole application (networks, volumes, containers); `down` stops and removes containers and networks. `stop`/`start` only pause and resume existing containers without removing them.

Short answer. Use the `ports:` key with `HOST:CONTAINER` syntax, for example `"8080:80"`, which maps host port 8080 to container port 80. The left side is always the host.

Short answer. Running as root inside a container means a container escape or writable bind mount gives root-level access on the host and to mounted resources. Use the `USER` instruction (with a numeric UID) so the process drops root.

Short answer. Restart policies tell the Docker daemon whether and when to automatically restart a container that exits. `unless-stopped` always restarts (except after a manual stop), while `on-failure` restarts only on non-zero exit codes.

Short answer. A HEALTHCHECK defines a command Docker runs periodically to report a container as healthy or unhealthy. It surfaces application-level liveness beyond just 'the process is running.'

Short answer. Smaller base images (alpine, slim, distroless) contain fewer packages, so there is less installed software to carry vulnerabilities or give an attacker tools. A minimal attack surface also means faster pulls and fewer CVEs to patch.

Short answer. Most often the main process finished or crashed on startup. First run `docker logs <id>` and check the exit code with `docker inspect`.

Short answer. Usually the app is using `localhost` or the wrong host, or the two containers aren't on the same user-defined network. Check the network and connect by service/container name.