Docker Interview Questions and Answers

Docker interviews check whether you can build, run, and troubleshoot containers on real hosts—not recite the Moby project history.

A strong answer is:

"Docker interviews test whether I can ship a containerized app—build an image, run it with the right mounts and ports, debug why it crashed, and explain when Compose is enough versus when the team needs Kubernetes."

Interviewers want you to separate the Docker CLI workflow from the OCI runtime stack.

A strong answer is:

"Docker is a developer/container-engine workflow, while Kubernetes talks to CRI-compatible runtimes such as containerd or CRI-O. Docker Engine is no longer directly integrated through dockershim, although it can still be used through cri-dockerd. Podman is a good rootless alternative where policy forbids a long-lived daemon."

Docker prep is hands-on—build and break containers on a lab VM.

Work through tutorial how to manage Docker container with examples while you drill—each example maps to a common interview follow-up.

A strong answer is:

"I'd spend week one on build, run, volumes, and networking. Week two I'd add multi-stage builds, Compose, registry workflows, and practice debugging containers that exit immediately or repeatedly restart."

Beginner questions ask for a working one-liner. Advanced questions add constraints: least privilege, image size, network isolation, or zero-downtime deploy patterns.

A strong answer is:

"Junior answers get a container running. Senior answers mention image slimming, non-root users, volume backup, network segmentation, and knowing when Compose stops scaling and Kubernetes takes over."

What interviewers are testing: Whether you understand that an image is immutable build output while a container is a runtime instance with process state and a writable layer, and can explain why many containers can share the same image.

An image is a read-only template: filesystem layers plus metadata (default command, env, exposed ports). A container is a running (or stopped) instance of that image with its own writable layer and runtime state.

On a lab host you can list images and containers separately:

docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'

REPOSITORY   TAG       SIZE
nginx        alpine    52.5MB

Then list container instances:

docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'

NAMES     STATUS    IMAGE
web01     Up 2 hours nginx:alpine

A strong answer is:

"The image is the immutable recipe; the container is the process sandbox created from it. I can run many containers from one image, each with its own writable layer and lifecycle."

What interviewers are testing: Whether you understand that docker run combines container creation and startup, and can explain how image selection, command, ports, environment variables, mounts, and networking become runtime configuration.

docker run combines create and start. The daemon pulls the image if missing, creates a container with your flags (name, env, mounts, network), then starts the process defined by CMD or ENTRYPOINT.

Common flags interviewers expect you to explain:

Example shape:

docker run -d --name demo -p 8080:80 nginx:alpine

A strong answer is:

"docker run pulls if needed, creates the container with my flags, and starts the main process. I treat -p, -v, and -e as the three knobs interviewers always ask about—ports, persistence, and configuration."

What interviewers are testing: Whether you know which list and inspect commands reveal runtime state, published ports, mounts, and exit codes—and when a quick docker ps is enough versus a full JSON inspect.

Use docker ps for a quick status table and docker inspect for full JSON metadata—network IP, mounts, env, exit code after stop.

List running containers:

docker ps --format 'table {{.Names}}\t{{.Ports}}\t{{.Status}}'

NAMES   PORTS                  STATUS
demo    0.0.0.0:8080->80/tcp   Up 5 minutes

Pull IP and mount details from inspect:

docker inspect demo --format '{{.NetworkSettings.IPAddress}} {{range .Mounts}}{{.Destination}} {{end}}'

172.17.0.2

A strong answer is:

"docker ps tells me what is running and which ports are published. docker inspect is my deep dive—IP on the bridge, mount paths, restart policy, and the exit code when something stopped unexpectedly."

What interviewers are testing: Whether you understand the difference between starting a new diagnostic process inside a container and attaching your terminal to the existing PID 1 process.

Typical debug session:

docker exec -it demo sh

A strong answer is:

"I almost always use docker exec to open a shell or run a diagnostic command without disturbing the main process. attach reconnects to PID 1—if I detach wrong, I can accidentally send SIGINT and stop the container."

What interviewers are testing: Whether you understand that containers rely on Linux kernel isolation rather than hardware virtualization, and can name the major namespaces responsible for process, network, filesystem, hostname, and IPC isolation.

Docker relies on kernel namespaces to isolate what a container can see:

Containers share the host kernel—they are not full virtual machines. Interviewers often follow with "what is still shared?"—the kernel, and optionally the host network when you use --network host.

A strong answer is:

"Docker primarily uses namespaces such as PID, network, mount, UTS, and IPC to isolate container views. User namespaces add UID/GID remapping when rootless mode or user-namespace remapping is configured. Isolation is kernel-level separation, not hardware virtualization."

What interviewers are testing: Whether you can separate isolation from resource governance: namespaces control visibility, while cgroups account for and constrain CPU, memory, process, and I/O usage.

cgroups (control groups) limit and account for resource usage: CPU, memory, I/O, and pids. Docker applies cgroup limits when you pass flags such as --memory and --cpus.

Example limit:

docker run -d --name limited --memory=256m --cpus=0.5 nginx:alpine

Without limits, a container can consume all host memory—production interviews expect you to mention Kubernetes resource controls when the conversation moves to orchestration.

Docker CPU and memory limits map conceptually to Kubernetes resource controls. In Kubernetes, requests primarily influence scheduling and resource allocation, while limits constrain maximum resource use.

A strong answer is:

"Namespaces isolate what a process can see; cgroups control and account for resources it can consume. Docker CPU and memory limits use those kernel controls, while Kubernetes adds requests for scheduling plus limits for runtime constraints."

What interviewers are testing: Whether you can write a Dockerfile that is reproducible, cache-efficient, minimal, and safe to run—rather than merely remembering FROM, COPY, and CMD.

FROM node:24-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
USER node
CMD ["node", "server.js"]

Key points to say aloud:

• WORKDIR sets the default directory for later instructions
• COPY before RUN npm ci keeps dependency layer cached when source changes
• USER node avoids running as root inside the container

A strong answer is:

"I order Dockerfile instructions for cache efficiency—dependency install before app copy—and end with a non-root USER. EXPOSE documents the port; -p on docker run actually publishes it."

What interviewers are testing: Whether you choose the simplest Dockerfile instruction that expresses the intended build behavior and understand the extra semantics ADD introduces.

Prefer COPY for ordinary files and directories from the build context. Use ADD only when you intentionally need one of its extra behaviors, such as fetching a remote source, cloning a Git source, or unpacking an archive.

A strong answer is:

"I default to COPY because its intent is simple. I use ADD only when I deliberately need an ADD-specific feature such as archive extraction or a remote source."

What interviewers are testing: Whether you understand how an image defines its executable and default arguments, how docker run overrides them, and why exec form matters for PID 1 signal handling.

Exec form (preferred):

ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

docker run IMAGE -v passes -v as extra args to ENTRYPOINT when ENTRYPOINT is set. Shell form invokes a shell wrapper—harder to signal-handle correctly.

A strong answer is:

"ENTRYPOINT defines what the container is; CMD supplies default args you can override at run time. I use exec form so PID 1 receives signals cleanly—important for graceful shutdown questions."

What interviewers are testing: Whether you understand how immutable image layers affect caching, image size, secret exposure, and why deleting a file in a later layer does not erase it from earlier image content.

Each Dockerfile instruction that changes the filesystem creates a new layer. Layers are stacked read-only; a container adds a thin writable layer on top.

Layers matter for:

• Cache hits on rebuild when early instructions unchanged
• Image size when you leave build tools in final image
• Security when secrets or large artifacts land in the wrong layer

View layer history:

docker history nginx:alpine --format 'table {{.CreatedBy}}\t{{.Size}}'

A strong answer is:

"Every filesystem-changing instruction adds a layer. I order instructions so expensive steps cache well, and I avoid putting secrets in layers because they remain in image history even if you delete the file later."

What interviewers are testing: Your hands-on approach to debugging a slow or stale docker build—steps, pitfalls, and how you verify success.

A slow build often means an early Dockerfile step invalidated the cache, causing later steps to rebuild.

A stale build result can happen when a build step depends on external state Docker cannot see from its inputs—for example, a remote package repository changed but the cached RUN step was reused.

Speed tactics:

--no-cache does not fetch a newer base image—use --pull when you need a fresh base. For a fully refreshed build, combine both:

docker build --pull --no-cache -t myapp:test .

See docker build no cache for when a full rebuild is justified.

A strong answer is:

"For a slow build I find which step lost its cache and fix Dockerfile order or .dockerignore. For a deliberately fresh build I use --no-cache, and add --pull when I also need a fresh base image."

What interviewers are testing: Whether you can separate build-time dependencies from runtime artifacts to reduce image size and attack surface without maintaining separate Dockerfiles.

Multi-stage builds use more than one FROM in one Dockerfile. A compile stage holds compilers and dev dependencies; the final stage copies only the artifact into a slim runtime image.

Benefits interviewers want to hear:

• Smaller images (faster pull, smaller attack surface)
• No build toolchain in production image
• Clear separation between build-time and run-time files

A strong answer is:

"I compile or bundle in a fat builder stage, then COPY only the binary or static assets into alpine or distroless. The running image does not ship gcc, npm devDependencies, or source I do not need at runtime."

What interviewers are testing: Whether you can describe a multi-stage build pattern that compiles in a builder stage and copies only the runtime artifact into a slim final image.

Typical pattern:

ARG GO_VERSION=1.27
FROM golang:${GO_VERSION}-alpine AS builder
WORKDIR /src
COPY go.* ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=builder /out/app /app
ENTRYPOINT ["/app"]

The final image contains only the static binary—no Go toolchain. Pair with condition in Dockerfile when build args choose targets.

A strong answer is:

"Builder stage runs go build; final stage is distroless with just the binary. Image scans and deploy times improve because there is no shell or package manager in production."

What interviewers are testing: Whether you can choose between Docker-managed persistent storage, explicit host-path coupling, and ephemeral memory-backed storage based on persistence and operational requirements.

Create and use a named volume:

docker volume create appdata
docker run -d --name db -v appdata:/var/lib/mysql mysql:8

A strong answer is:

"Named volumes are my default for persistent application data. Bind mounts are useful when I intentionally need a host path. tmpfs is for ephemeral in-memory data; I use a proper secret mechanism for credentials."

What interviewers are testing: Whether you choose persistent storage based on lifecycle, portability, host coupling, permissions, backup/restore, and operational requirements rather than saying "volumes are always better."

For a normal single-host Docker deployment, I would usually prefer a named volume over an arbitrary bind-mounted host directory. In larger production systems, external or network-backed storage may be more appropriate.

Named volumes help because:

• Docker manages the volume's location and lifecycle, so the application is less coupled to a specific host directory layout
• Backup tools (docker run --rm -v appdata:/data …) attach without guessing host paths
• You avoid accidental deletion when someone cleans /tmp bind paths

Bind mounts expose a fixed host directory—fine for dev, brittle when paths differ per server or SELinux labels block access.

A strong answer is:

"Production database data goes in a named volume or external storage driver—not a random host path bind. Named volumes decouple data from a specific host directory, but ownership and permissions still depend on image UID/GID and how the volume is initialized."

What interviewers are testing: Whether you understand the isolation and connectivity trade-offs of Docker network modes—private bridge networking, sharing the host network namespace, or disabling networking entirely.

Default bridge run:

docker run -d --name web -p 8080:80 nginx:alpine

A strong answer is:

"Bridge is the default—I publish ports to reach the service from outside. Host mode skips NAT for performance or legacy reasons but removes network isolation. None is for workloads that should not talk on the network at all."

What interviewers are testing: Whether you understand Docker's user-defined network service discovery and know why localhost refers to the current container rather than another service.

Create a user-defined bridge network—Docker embeds a DNS server that resolves container names:

docker network create appnet
docker run -d --name api --network appnet myapi:1.0
docker run -d --name web --network appnet nginx:alpine

From web, curl http://api:8080 resolves via embedded DNS. On the default bridge, name resolution does not work the same way—another common interview trap.

A strong answer is:

"I normally put related standalone containers on a user-defined bridge because it provides automatic DNS by container name and better isolation than the default bridge. Compose creates a project network automatically for its services."

What interviewers are testing: Whether you recognize when imperative one-container commands become difficult to reproduce and when a declarative multi-service definition is the better operational model.

Compose fits multi-container apps on one host: web + database + cache with one YAML file and shared network.

A strong answer is:

"Single-container demos use docker run. When I have app + database + worker, Compose gives me one compose up and reproducible service names—still one host, not cluster orchestration."

What interviewers are testing: Whether you can distinguish network reachability, service naming, startup ordering, and application readiness rather than assuming depends_on makes the database ready.

Walk interviewers through an ordered checklist:

1. Shared network — verify the app and database share at least one Compose network. If neither service declares custom networks, Compose normally attaches both to the project default network
2. Service name — app should use db hostname, not localhost (DB is another container)
3. Depends_on — short syntax controls startup order but does not wait for application readiness. With long syntax and condition: service_healthy, Compose can wait for the database healthcheck before starting the dependent service
4. Published ports — app-to-db traffic uses internal network; ports on DB is for host access only
5. Env vars — DATABASE_URL host must match service name
6. Logs — docker compose logs db for bind or auth errors

See docker compose multiple commands for startup ordering patterns.

A strong answer is:

"I verify both services share the Compose network and the app points at the service name—not localhost. Short-form depends_on gives startup ordering, not readiness. When appropriate, I define a database healthcheck and use condition: service_healthy; the application should still tolerate reconnects after startup."

What interviewers are testing: Whether you understand image naming, authentication, mutable tags, immutable digests, and how an image artifact moves from CI into deployment.

Workflow:

1. Build locally: docker build -t myreg.example.com/team/app:1.4.0 .
2. Login: docker login myreg.example.com
3. Push: docker push myreg.example.com/team/app:1.4.0
4. Pull on another host: docker pull myreg.example.com/team/app:1.4.0

Tags are mutable pointers; image digest is the immutable content address interviewers ask about for supply-chain questions.

A strong answer is:

"I tag with the registry hostname so push knows the destination. In CI I push semver tags and pin deploys by digest when I need immutability—even if someone re-tags later."

What interviewers are testing: Whether you understand registry authentication on workstations and in CI, including credential helpers, short-lived tokens, and why secrets should not live in images or Dockerfiles.

Options:

Never embed passwords in Dockerfile or image layers.

A strong answer is:

"Developers use docker login or a credential helper. CI should normally use a scoped short-lived registry token supplied by the secret manager and pass it through docker login --password-stdin, rather than hard-coding a password. Kubernetes pulls use imagePullSecrets—the kubelet does not read my laptop's Docker config."

What interviewers are testing: Whether you can walk through a practical checklist for containers that fail to start or exit immediately—logs, exit codes, interactive runs, mounts, ports, and resource limits.

1. Logs — docker logs CONTAINER (or docker compose logs)
2. Exit code — docker inspect --format '{{.State.ExitCode}}' CONTAINER
3. Run interactively — docker run -it --name debug-myapp IMAGE without -d to see stderr; use --rm only when you do not need the stopped container for subsequent inspect or log analysis
4. Entrypoint — wrong CMD/ENTRYPOINT or missing binary
5. Mounts — bind path missing or SELinux :z / :Z needed on RHEL
6. Ports — host port already in use
7. Resources — OOM killed shows in docker inspect State

Tail logs from a stopped container:

docker logs demo 2>&1 | tail -5

A strong answer is:

"Logs first, then exit code and inspect. I rerun interactively with a named container so I can inspect it after failure—--rm only when I do not need that state. Mounts, port conflicts, and OOM are the usual root causes after misconfigured entrypoints."

What interviewers are testing: Whether you understand that a container's lifecycle follows its main process and can distinguish an application crash, bad ENTRYPOINT/CMD, missing configuration, architecture mismatch, and a process that daemonizes or exits normally.

The detached run hides stderr—recreate without -d:

docker run --name debug-myapp myapp:1.0

If it exits with code 1 and prints "config file not found", the fix is mount or env—not restart policy.

Then inspect the stopped container:

docker logs debug-myapp
docker inspect debug-myapp --format '{{.State.ExitCode}}'

Also check:

• Foreground process — the container's main process must remain in the foreground. Traditional daemons may need foreground mode; official container images such as nginx normally configure this already
• Wrong architecture — exec format error on mixed ARM/x86
• Missing dependency — database URL points at localhost inside container

See docker container keep running for PID 1 patterns.

A strong answer is:

"I run without -d and keep the container with --name so I can read logs and inspect exit code after it stops. If the app expects a config volume or daemon-off style command, that shows up immediately in the terminal output."

What interviewers are testing: Whether you understand that Docker-built OCI images still work with Kubernetes even though Kubernetes no longer depends on Docker Engine as its built-in node runtime, and can distinguish image building from container runtime and orchestration.

Kubernetes schedules Pods; the kubelet talks CRI to a runtime (containerd, CRI-O). Kubernetes no longer has the built-in dockershim integration. Nodes commonly use containerd or CRI-O directly through CRI; Docker Engine can still be used when paired with cri-dockerd. Images are still OCI images built with docker build or Buildah.

A strong answer is:

"I still build OCI images with Docker or BuildKit in CI. Kubernetes pulls those images and runs them via containerd or CRI-O. Docker the daemon is optional on workers—image format is what carries over."

What interviewers are testing: Whether you can identify the operational requirements that justify an orchestrator—multi-node scheduling, reconciliation, self-healing, rolling deployment, service discovery, and policy—rather than saying Kubernetes is simply "Docker at scale."

Compose stops scaling when you need:

• Multiple hosts and automatic rescheduling when a node dies
• Rolling updates with controlled surge and rollback
• Service discovery and load balancing across many replicas
• Declarative desired state reconciled by a control plane
• RBAC, NetworkPolicy, and cluster-level secrets

Compose is excellent for local dev and integration tests on one machine. Production multi-tenant platforms move to Kubernetes or another orchestrator.

A strong answer is:

"Compose is one host and one operator running compose up. When I need self-healing across nodes, rolling deploys, and cluster RBAC, I hand the same images to Kubernetes Deployments and Services."

What interviewers are testing: Whether you can explain how one immutable image artifact is promoted across environments with separate configuration, and why digest-based rollback matters when tags are mutable.

Narrative interviewers want:

1. CI builds and scans the image, pushes to registry, and records its immutable digest
2. Same image content promoted dev → staging → prod—no rebuild per environment
3. Config differs via env, ConfigMap, Secret—not different image builds per env unless necessary
4. Kubernetes changes replica count, rollout strategy, and Service/Ingress—image content stays identical
5. Rollback to a previously known image digest or immutable release reference

A strong answer is:

"CI produces one image artifact and records its digest. Dev, staging, and production run the same image content with environment-specific configuration injected at deployment time; I do not rebuild per environment."

What interviewers are testing: Whether you understand that EXPOSE is image metadata/documentation while -p creates runtime host-to-container port publishing, and can explain why an exposed port is not automatically reachable from the host.

EXPOSE in a Dockerfile documents which container ports the image expects to listen on. It does not publish a host port by itself.

-p / --publish maps a host port to a container port at docker run time:

docker run -d -p 8080:80 nginx:alpine

Traffic reaches the service on the host only when you publish or otherwise route to the container port.

A strong answer is:

"EXPOSE is metadata for image authors and tooling—it does not open a host port. I use -p when something outside the container network must reach the service."

What interviewers are testing: Whether you understand graceful versus forced termination, PID 1 signal handling, and when preserving application shutdown logic matters.

docker stop myapp
docker kill myapp
docker rm -f myapp

A strong answer is:

"docker stop gives the application a grace period to shut down using its configured stop signal. docker kill sends SIGKILL by default, though I can choose another signal. docker rm -f force-kills a running container and removes it."

What interviewers are testing: Whether you understand that process liveness and application health are different states, and can explain what Docker healthchecks do—and what they do not automatically do.

Up means the container's main process is still running. A configured healthcheck adds a separate starting, healthy, or unhealthy assessment based on repeated health commands.

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost/ || exit 1

In Compose, depends_on with condition: service_healthy waits for that health state—not merely for the container to start.

A Docker healthcheck changes the container's health status to starting, healthy, or unhealthy; it does not by itself restart a standalone container. Restart policies are primarily triggered by the container process exiting. Docker documents health status separately from the normal container state.

A strong answer is:

"Up only means the PID 1 process is alive—the app may still be booting or wedged. Docker healthchecks let Docker and Compose distinguish a live PID from an application that passes its configured health test. Kubernetes uses its own readiness, liveness, and startup probes."

What interviewers are testing: Whether you understand the boundary between build-time inputs and runtime environment configuration, including why neither mechanism should be used as a secret-management solution.

ARG NODE_VERSION=20
ENV APP_ENV=production

Neither belongs in committed secrets—use runtime secrets injection instead of baking credentials into ARG or ENV.

A strong answer is:

"ARG is for build-time inputs such as dependency versions. ENV sets defaults the running container sees. I keep secrets out of both and inject them at deploy time."