Docker is a core DevOps and backend skill. These Docker interview questions cover images, containers and Dockerfiles for freshers, then layers and caching, multi-stage builds, volumes, networking, Docker Compose, security and production best practices for experienced engineers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Docker packages an application with its dependencies into a container that runs the same way everywhere.
A virtual machine includes a full guest operating system on a hypervisor, so it is heavy and slow to start.
Containers share the host's kernel and isolate processes using namespaces and cgroups, so they are lightweight, start in seconds and use far fewer resources.
An image is a read-only template with the application, libraries and configuration, built from a Dockerfile and stored in a registry such as Docker Hub.
A container is a running instance of an image with a thin writable layer on top.
You can start many containers from one image.
FROM sets the base image, WORKDIR sets the working directory, COPY copies files into the image, RUN executes commands at build time, ENV sets environment variables, EXPOSE documents the port, USER sets the user to run as, and CMD or ENTRYPOINT define the command run when the container starts.
docker build -t name . builds an image, docker run starts a container, docker ps lists running containers (-a for all), docker logs shows output, docker exec -it name sh opens a shell inside, docker stop and docker rm stop and remove containers, docker images and docker rmi manage images, docker pull and docker push transfer images, and docker system prune cleans up.
-d runs in the background, -p 8080:80 publishes container port 80 on host port 8080, -e sets environment variables (or --env-file), -v mounts volumes, --name names the container, --rm removes it when it stops, -it gives an interactive terminal, --network attaches it to a network, and --restart sets the restart policy.
A registry stores and distributes images.
Docker Hub is the default public registry; others include GitHub Container Registry, Amazon ECR, Google Artifact Registry and Azure Container Registry, often private.
Images are named registry/repository:tag, pushed after building in CI and pulled by servers and Kubernetes clusters.
COPY copies files and folders from the build context into the image.
ADD does the same but can also extract local tar archives and download files from URLs.
Because ADD's extra behaviour can be surprising, COPY is recommended for normal file copying, and RUN with curl or wget is clearer for downloads.
ARG defines a variable available only while the image is being built, passed with docker build --build-arg, such as a version number.
ENV sets an environment variable that is stored in the image and available to running containers.
Neither should hold secrets, because both can be seen in the image history; use build secrets or runtime secrets instead.
It lists files the Docker client should not send to the build context, such as node_modules, .git, logs, local .env files and build output. This makes builds faster, avoids invalidating the layer cache unnecessarily, keeps images smaller and prevents secrets from accidentally being copied into images.
Check output with docker logs -f, open a shell with docker exec -it container sh (or bash), check settings and state with docker inspect, watch resource use with docker stats and see processes with docker top. For minimal images without a shell, docker debug or a temporary debugging container sharing the same namespaces helps.
Alpine images are very small and use musl libc, which can cause compatibility issues with some compiled libraries.
Slim images are trimmed Debian images using glibc, a safe default.
Distroless images contain only the application runtime, with no shell or package manager, which gives a smaller attack surface but makes debugging harder.
Choose based on size, compatibility and security needs.
Applied problems, trade-offs and questions about your own projects.
ENTRYPOINT defines the main executable that always runs, and CMD provides default arguments that can be overridden at docker run.
If only CMD is used, the whole command can be replaced.
A common pattern is ENTRYPOINT ["python", "app.py"] with CMD ["--port", "8000"].
The exec (JSON array) form is preferred so signals reach the process.
Each instruction creates a layer, and Docker reuses cached layers until one changes; every layer after a change is rebuilt.
So I copy dependency files first and install dependencies, such as COPY package*.json then RUN npm ci, before copying the rest of the source code.
I also use a .dockerignore file and combine related RUN commands.
Container file systems are temporary, so data is lost when a container is removed.
Volumes are managed by Docker and are the preferred way to persist data such as databases.
Bind mounts map a specific host directory into the container, which is useful in development for live code reloading. tmpfs mounts keep data in memory only.
Docker Compose defines and runs multi-container applications from a YAML file (compose.yaml), with services, networks, volumes, environment variables and dependencies. docker compose up starts the whole stack, such as an API, a database and Redis, with one command. It is mostly used for local development and testing.
Restart policies decide what happens when a container exits: no (default), on-failure, always, or unless-stopped.
A HEALTHCHECK instruction or Compose setting runs a command periodically, such as calling a /health endpoint, so Docker marks the container healthy or unhealthy, and Compose can wait for a database to be healthy before starting the app.
Kubernetes uses its own probes instead.
Use --memory to cap memory, which kills the container with an out-of-memory error if exceeded, and --cpus to limit CPU, for example --cpus=1.5.
Without limits, one container can starve others on the same host.
Runtimes such as the JVM and Node.js should be configured to respect container limits, which modern versions detect automatically.
Avoid relying on latest, because it changes and makes deployments unpredictable.
Tag images with the version and the Git commit SHA, such as myapp:1.4.2 and myapp:sha-3f2a1c9, so every deployment is traceable and easy to roll back.
For maximum safety, deploy by image digest (sha256:...), which never changes, and pin base images too.
The main process in a container runs as PID 1, which receives stop signals such as SIGTERM.
If CMD uses the shell form, a shell becomes PID 1 and may not forward signals, so the app is killed abruptly after a timeout.
Use the exec (JSON array) form, make the app handle SIGTERM gracefully, and use --init or tini to reap zombie processes when needed.
BuildKit is Docker's modern build engine, with parallel stages and better caching.
Cache mounts (RUN --mount=type=cache,target=/root/.npm npm ci) keep package manager caches between builds without storing them in the image.
Secret mounts (RUN --mount=type=secret,id=npmrc) provide credentials during a build without leaving them in any layer.
Non-sensitive settings go in environment variables or an env_file, and variables can be substituted from a .env file.
Secrets such as passwords should use Compose secrets, mounted as files in /run/secrets, or come from a secrets manager in production.
Never bake secrets into images or commit .env files with real credentials.
Check docker ps -a for the exit code and docker logs for errors.
Common causes are the main command finishing immediately (containers stop when their main process ends, so services must run in the foreground), a missing file or wrong path, a missing environment variable, or an exit code 137 meaning it was killed for using too much memory.
Overriding the entrypoint with a shell lets you look inside.
System design, deep internals, leadership and tough follow-ups.
A multi-stage build uses several FROM stages in one Dockerfile.
Early stages contain compilers and build tools to build the application; the final stage copies only the built output into a small runtime image such as alpine, distroless or a slim base.
This makes images much smaller and more secure because build tools and source code are not shipped.
Use small official or distroless base images and keep them updated, scan images for vulnerabilities with tools such as Trivy or Docker Scout, run as a non-root user, never put secrets in images or build arguments, use a read-only root filesystem where possible, drop Linux capabilities, set resource limits, and sign and pin images by digest.
The default bridge network connects containers on one host; user-defined bridge networks add DNS so containers reach each other by name, which is what Compose sets up.
The host network shares the host's network stack, none disables networking, and overlay networks connect containers across hosts in Swarm.
Ports are published to the host with -p 8080:80.
The Docker CLI talks to the Docker daemon, which uses containerd to manage containers and runc to create them according to the OCI runtime specification. Isolation comes from Linux namespaces (PID, network, mount, user and others), resource limits from cgroups, and images use a layered union file system such as overlayfs, with a thin writable layer per container.
Swarm is built into Docker and is simple to set up, using familiar Compose files for services, scaling and rolling updates, which suits small clusters.
Kubernetes is far more powerful and extensible, with autoscaling, a huge ecosystem, custom resources and support from every cloud provider, but it is more complex.
Most organisations today choose Kubernetes or a managed container service.
Use multi-stage builds so only the built output reaches the final image, start from slim or distroless bases, install only production dependencies, clean package manager caches in the same RUN step, use .dockerignore, combine related commands to reduce layers, and for compiled languages such as Go, copy a static binary into a scratch or distroless image. docker history and dive show what takes space.
Use docker buildx with --platform linux/amd64,linux/arm64 to build a multi-platform image, which is published as a manifest list so each machine pulls the right variant, such as ARM-based Apple Silicon laptops and AWS Graviton servers. Builds use QEMU emulation or, faster, native builders for each architecture, or cross-compilation in the Dockerfile.
Mounting the Docker socket into a container gives it root-level control of the host, and Docker-in-Docker needs privileged mode, so both are risky in shared CI. Safer options are rootless Docker, daemonless builders such as BuildKit in rootless mode, Kaniko or Buildah, and running containers as non-root users with dropped capabilities, read-only file systems, seccomp profiles and scanned images.
See all DevOps Engineer interview questions, covering Linux, Git, Docker, Kubernetes, CI/CD (GitHub Actions, Jenkins) and more.