Docker interview questions

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

What a strong answer shows

An image is a read-only template made of layers plus metadata such as the default command. A container is a running or stopped instance of an image with its own writable layer on top. Weak answers call the image a 'stopped container' or miss that changes in a container are lost when it is removed.

2.How are containers different from virtual machines?

What a strong answer shows

Containers share the host kernel and isolate processes with kernel features, so they start fast and use little overhead. A virtual machine runs its own kernel on a hypervisor, which gives stronger isolation at a higher cost. The trap is saying containers are simply lightweight VMs with the same security boundary.

3.How does the build cache work, and why does the order of instructions matter?

FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

What a strong answer shows

Each instruction creates a layer, and Docker reuses a cached layer until an instruction or its input files change. After that, every later step rebuilds. A strong answer copies dependency manifests and installs packages before copying the source, so code edits do not reinstall everything.

4.What is the difference between ENTRYPOINT and CMD?

FROM python:3.12-slim
ENTRYPOINT ["python", "-m", "http.server"]
CMD ["8000"]
# docker run img       -> python -m http.server 8000
# docker run img 9000  -> python -m http.server 9000

What a strong answer shows

ENTRYPOINT sets the executable, and CMD supplies default arguments that `docker run` arguments replace. A strong answer prefers the exec (JSON array) form so the process receives signals directly. Weak answers say the two are interchangeable or do not know how they combine.

5.When would you use a named volume instead of a bind mount?

What a strong answer shows

A named volume is managed by Docker and suits persistent data such as a database, independent of the host's folder layout. A bind mount maps a specific host path and suits local development, such as live-reloading source code. The trap is writing important data into the container's own filesystem, where it disappears with the container.

6.What does `-p 8080:3000` do, and what does EXPOSE do in a Dockerfile?

What a strong answer shows

`-p 8080:3000` maps port 8080 on the host to port 3000 inside the container. EXPOSE only documents which port the app listens on and publishes nothing by itself. A strong answer also notes the app must listen on 0.0.0.0, not 127.0.0.1, or the mapped port will not answer.

7.Your container exits as soon as it starts. How do you debug it?

docker ps -a --filter "name=api"
docker logs api
docker inspect api --format "{{.State.ExitCode}} {{.State.OOMKilled}}"
docker run --rm -it --entrypoint sh myimage

What a strong answer shows

Read the logs and the exit code first, then check whether the main process ran in the foreground. Common causes are a missing file or variable, a crash at start-up, or a command that finishes straight away. A strong answer overrides the entrypoint with a shell to inspect the image rather than guessing.

8.How do you pass configuration into a container?

What a strong answer shows

Use environment variables with `-e` or `--env-file`, or mount a config file, so the same image runs in every environment. A strong answer keeps environment-specific values out of the image. The trap is baking configuration or passwords into the Dockerfile and rebuilding the image for each environment.

9.What is a .dockerignore file for?

What a strong answer shows

It excludes files from the build context sent to the builder, such as `.git`, `node_modules`, local `.env` files and build output. That keeps builds faster, avoids needless cache invalidation and stops secrets leaking into images through `COPY . .`. Weak answers only mention image size.

10.What is the difference between COPY and ADD, and which should you use?

What a strong answer shows

COPY copies files from the build context and nothing more. ADD can also fetch remote URLs and auto-extract local tar archives, which makes its behaviour less obvious. A strong answer defaults to COPY and uses ADD only when that extra behaviour is wanted.

11.What is a multi-stage build, and why would you use one?

FROM golang:1.23 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

What a strong answer shows

A multi-stage build compiles in one stage with the full toolchain, then copies only the output into a minimal final stage. The final image leaves out compilers, source and build caches, so it is smaller and has less to attack. Weak answers try to clean up in the same stage, which leaves the files in earlier layers.

12.How do you choose a base image: full, slim, Alpine or distroless?

What a strong answer shows

Smaller images mean fewer packages to patch and faster pulls, so start from slim or distroless where you can. A strong answer notes that Alpine uses musl rather than glibc, which can break some native dependencies. Distroless images also have no shell for debugging. The trap is picking the smallest image without checking it runs the app correctly.

13.Why should a container not run as root, and how do you change that?

FROM node:22-slim
WORKDIR /app
COPY --chown=node:node package*.json ./
RUN npm ci --omit=dev
COPY --chown=node:node . .
USER node
CMD ["node", "server.js"]

What a strong answer shows

Root in a container is root on the host kernel, so a container escape or a bad mount does far more damage. Set a non-root user with USER and make sure that user can read the app files. A strong answer also mentions dropping capabilities and running with a read-only filesystem where possible.

14.How do you use a secret, such as a private registry token, during a build without leaking it?

# syntax=docker/dockerfile:1
# build with: docker build --secret id=npmrc,src=.npmrc .
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
COPY . .

What a strong answer shows

Use a BuildKit secret mount, which exposes the secret to one RUN step and never writes it into a layer. ARG and ENV values end up in image history or metadata. Deleting a copied file in a later step does not remove it from earlier layers. At runtime, inject secrets from the orchestrator or a secrets manager instead.

15.What is the difference between ARG and ENV?

What a strong answer shows

ARG exists only at build time and can be set with `--build-arg`. ENV is stored in the image and visible to the running container. A strong answer notes that an ARG declared before FROM must be declared again inside the stage to use it there. Neither is a safe place for secrets.

16.Write a compose file for an API and a Postgres database. How does the API wait for the database?

services:
  api:
    build: .
    ports: ["8080:8080"]
    environment:
      DATABASE_URL: postgres://app:app@db:5432/app
    depends_on:
      db: { condition: service_healthy }
  db:
    image: postgres:17
    environment: { POSTGRES_USER: app, POSTGRES_PASSWORD: app }
    healthcheck: { test: ["CMD", "pg_isready", "-U", "app"], interval: 5s }

What a strong answer shows

Services on the same compose network reach each other by service name, so the API connects to host `db`. Plain `depends_on` only orders start-up, so add a healthcheck and `condition: service_healthy` to wait for readiness. A strong answer still makes the app retry its connection, because databases can restart later.

17.What does a HEALTHCHECK do, and what does it not do?

What a strong answer shows

It runs a command on an interval and marks the container healthy or unhealthy, which compose and other tools can act on. Plain Docker does not restart an unhealthy container by itself. A strong answer keeps the check cheap and specific, and notes that Kubernetes ignores HEALTHCHECK and uses its own probes.

18.How do two containers on the same host talk to each other?

What a strong answer shows

Put them on a user-defined bridge network, where Docker's embedded DNS resolves container names. Inside a container, `localhost` means that container only, which is the usual cause of 'connection refused'. A strong answer knows the default bridge network has no name resolution, and that published ports are for traffic from outside.

19.Why might a container take ten seconds to stop, and how do you fix it?

What a strong answer shows

`docker stop` sends SIGTERM and kills the process after a grace period, which defaults to ten seconds. If the app runs under a shell-form command, the shell is PID 1 and may not forward the signal. Fix it with the exec form, an app that handles SIGTERM, or a small init such as `docker run --init`.

20.How does logging work for containers, and where should the app write its logs?

What a strong answer shows

The app should write to stdout and stderr, and Docker's logging driver captures them for `docker logs` or ships them elsewhere. A strong answer mentions configuring log rotation, because the default json-file driver keeps growing without limits. Writing log files inside the container is the trap: they fill the writable layer and vanish with the container.

21.How do you set resource limits on a container, and what happens when it exceeds them?

docker run -d --name api --memory=512m --cpus=1.5 --pids-limit=200 myimage
docker stats api --no-stream
docker inspect api --format "{{.State.OOMKilled}} {{.State.ExitCode}}"

What a strong answer shows

Set `--memory` and `--cpus`; going over the memory limit gets the process OOM-killed, usually seen as exit code 137. CPU limits throttle the process rather than killing it. A strong answer checks that the runtime respects the container limit, for example older JVMs or worker counts sized from the host's CPUs.

22.Why is relying on the `latest` tag a problem?

What a strong answer shows

`latest` is just a default tag name that moves, so two deploys can run different code and rollbacks become guesswork. Use immutable version tags or a commit SHA, and pin by digest when you need certainty. A strong answer applies the same rule to base images in FROM lines.

23.What actually makes a container a container at the Linux level?

What a strong answer shows

Namespaces give the process its own view of PIDs, network, mounts, hostnames and users. Cgroups limit and account for CPU, memory and I/O, and a union filesystem such as overlayfs stacks the image layers. A strong answer adds that the Docker engine delegates to containerd and runc, which do the low-level work.

24.Is a container a security boundary? What weakens its isolation?

What a strong answer shows

It is a weaker boundary than a VM because every container shares the host kernel. Isolation is weakened by `--privileged`, added capabilities, host namespaces and sensitive host mounts. Mounting the Docker socket is the worst case, because it grants root on the host. A strong answer lists hardening steps such as non-root users, rootless mode, seccomp profiles and read-only filesystems.

25.How do you keep production images free of known vulnerabilities?

What a strong answer shows

Scan images in CI and in the registry, fail builds on serious fixable issues, and rebuild regularly so base image patches flow in. A strong answer adds SBOMs, signed images and pinned base images, and triages findings by whether the vulnerable code is reachable. The weak answer scans once and ignores the long report.

26.How do Docker containers relate to Kubernetes?

What a strong answer shows

Docker builds OCI images, and Kubernetes runs those same images through a container runtime such as containerd. Kubernetes stopped using Docker Engine as a runtime, which did not affect images built with Docker. A strong answer explains that Kubernetes adds scheduling, self-healing, service discovery and rolling updates across many machines.

27.Docker builds are slow in CI. How would you speed them up?

docker buildx build \
  --cache-from type=registry,ref=registry.example.com/app:buildcache \
  --cache-to type=registry,ref=registry.example.com/app:buildcache,mode=max \
  -t registry.example.com/app:1.4.2 --push .

What a strong answer shows

CI runners usually start with an empty cache, so export and import the BuildKit cache through the registry or the CI cache. Order layers well, use cache mounts for package managers and keep the build context small. A strong answer measures which step is slow before changing anything.

28.An image built on an ARM laptop fails on an x86 server with 'exec format error'. What happened, and how do you fix it?

docker buildx create --use --name multi
docker buildx build --platform linux/amd64,linux/arm64 \
  -t registry.example.com/app:1.4.2 --push .
docker buildx imagetools inspect registry.example.com/app:1.4.2

What a strong answer shows

The image was built for arm64 and the server runs amd64, so the binaries cannot execute. Build a multi-platform image with buildx, which publishes a manifest list so each host pulls its own variant. A strong answer notes that emulated builds are slow and cross-compiling in the build stage is often faster.

29.Would you run a production database in a container?

What a strong answer shows

It can work, but the hard parts are storage, backups, failover and upgrades rather than the container itself. A strong answer compares running it yourself on reliable volumes or a Kubernetes operator against a managed database, and weighs the team's operational skill. The trap is a flat yes or no without discussing durable storage and recovery.

30.A container built from a distroless image misbehaves in production and has no shell. How do you debug it?

# Share the target's network and PID namespaces with a tools image
docker run --rm -it --network container:api --pid container:api busybox
# Inside: ps, netstat -tln, wget -qO- localhost:8080/health

# Kubernetes equivalent
kubectl debug -it pod/api --image=busybox --target=api

What a strong answer shows

Start a debugging container that shares the target's network and PID namespaces, so your tools can see its processes and ports. In Kubernetes, use an ephemeral container with `kubectl debug`. A strong answer avoids rebuilding the image with a shell just to debug, and checks logs, metrics and `docker inspect` first.