Docker Interview Questions for DevOps Engineers (2026)

Docker interviews test whether you understand containers at the system level — not just how to run docker run. Here are the questions that separate junior from senior answers.

The Question That Every Senior Panel Asks

"Your container works fine locally but fails in production. How do you debug it?"

Most candidates say: "Check the logs."

What a strong answer looks like:

1. Verify image consistency: Is the same image tag being deployed? Never use latest in production — pin to a digest or specific version tag

2. Compare environment variables: Production env vars differ from local. Check for missing secrets, wrong endpoints, or misconfigured feature flags

3. Check resource limits: Local Docker has no limits. Production Kubernetes has CPU/memory limits. OOMKilled containers look like crashes

4. Inspect network mode: Local uses bridge by default. Production may use host, overlay, or a custom CNI. DNS resolution differs between environments

5. Verify volume mounts: File paths and permissions that work locally may fail in production due to read-only filesystems or different user IDs

6. Run the production image locally with production env vars: docker run --env-file prod.env

Core Concepts

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

An image is a read-only template — a snapshot of a filesystem and metadata (entrypoint, exposed ports, environment variables). It's immutable.

A container is a running instance of an image. It adds a writable layer on top of the image's read-only layers. Multiple containers can run from the same image simultaneously.

Analogy: Image is the class definition. Container is the instantiated object.

2. Explain Docker layers and how they affect image size

Every instruction in a Dockerfile creates a new layer. Layers are cached and shared between images.

FROM node:18-alpine           # layer 1: base image
WORKDIR /app                  # layer 2: working directory
COPY package*.json ./         # layer 3: package files
RUN npm ci                    # layer 4: dependencies (expensive)
COPY . .                      # layer 5: application code
CMD ["node", "server.js"]     # layer 6: entrypoint

Why this order matters: Docker caches layers. If you COPY application code before npm ci, any code change invalidates the npm cache and reinstalls all dependencies. The order above only reinstalls dependencies when package.json changes.

Reducing image size:

Use Alpine or distroless base images
Multi-stage builds — compile in a full image, copy only the binary to a minimal image
Combine RUN commands to reduce layers: RUN apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*

3. What is a multi-stage build and when do you use it?

# Stage 1: Build
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o server .

# Stage 2: Runtime
FROM alpine:3.18
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

Result: The final image contains only the compiled binary and Alpine (~8MB), not the Go toolchain (~800MB).

Use when: Compiled languages (Go, Rust, Java, C++), or when your build process requires tools not needed at runtime.

4. How does Docker networking work?

Default networks:

bridge: Default for standalone containers. Each container gets a private IP. Use container names for DNS within the same network.
host: Container shares the host's network namespace. No port mapping needed. Better performance but no isolation.
none: No network access.

Custom bridge networks (recommended):

docker network create my-app
docker run --network my-app --name db postgres
docker run --network my-app --name api my-api-image
# api can now reach db at http://db:5432

Custom networks enable automatic DNS resolution by container name. Default bridge network does not.

5. What is the difference between CMD and ENTRYPOINT?

ENTRYPOINT: The command that always runs. Cannot be overridden with arguments to docker run (but can be overridden with --entrypoint).

CMD: Default arguments to ENTRYPOINT, or the default command if no ENTRYPOINT. Overridden by anything passed to docker run.

ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]

docker run myimage → runs python app.py --port 8080

docker run myimage --port 9090 → runs python app.py --port 9090

Shell vs exec form:

Shell form: CMD python app.py — runs as /bin/sh -c "python app.py". PID 1 is sh, not your process. Signals (SIGTERM) may not reach your app.
Exec form: CMD ["python", "app.py"] — runs directly. Your app is PID 1. Signals handled correctly. Always prefer exec form.

6. How do you secure Docker containers?

Image security:

Scan images with Trivy or Snyk before deployment
Use minimal base images (distroless, Alpine)
Never run as root — use USER instruction
Pin base image versions by digest, not tag

Runtime security:

--read-only flag — container filesystem is read-only
--no-new-privileges — prevents privilege escalation
Drop unnecessary capabilities: --cap-drop ALL --cap-add NET_BIND_SERVICE
Use seccomp profiles to restrict syscalls

Secrets:

Never pass secrets as environment variables in Dockerfile
Use Docker secrets (Swarm) or Kubernetes secrets
Use AWS Secrets Manager / Vault at runtime

7. What is the difference between docker stop and docker kill?

docker stop:

Sends SIGTERM to the container's PID 1
Waits 10 seconds (default) for graceful shutdown
Then sends SIGKILL if not stopped

docker kill:

Sends SIGKILL immediately (or a specified signal)
No grace period

Why it matters: Applications need SIGTERM to clean up connections, finish in-flight requests, and flush buffers. Always use docker stop for production containers. Make sure your application handles SIGTERM correctly — this is a common interview follow-up.

8. How do you reduce Docker build time in CI/CD?

Layer caching: Order Dockerfile instructions from least to most frequently changed
BuildKit: Enable with DOCKER_BUILDKIT=1 — parallel layer builds, better caching
Registry caching: Pull the previous build as cache: --cache-from registry/image:latest
docker build --mount=type=cache: Cache package manager directories between builds
Multi-stage builds: Only transfer the final stage artifacts
.dockerignore: Exclude node_modules, .git, test files from build context

Typical result: 10-minute builds reduced to 2-3 minutes with proper caching.

Practice These Questions Live

InterviewDrill.io has a Docker & Containers track — Joshua asks real production scenarios, scores your answer, and shows you the ideal response. First session free → interviewdrill.io