Docker Interview Questions and Answers

RUN executes a command at build time and bakes the result into an image layer. CMD sets the default command when a container starts, and can be overridden on the docker run line. ENTRYPOINT sets the fixed program of the container. Anything you pass after the image name is added to it as arguments.

• Use RUN for installing packages and building code.
• Use CMD for default arguments or a default command.
• Use ENTRYPOINT with CMD when the image behaves like a command: ENTRYPOINT is the program, CMD holds default arguments.
• Prefer the exec (JSON array) form so signals reach your process.

RUN pip install -r requirements.txt
ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8000"]

docker run img --port 9000 replaces only CMD, so the container runs python app.py --port 9000.

What they are checking: Whether you understand build time versus run time and how overriding works.

A multi-stage build uses several FROM lines in one Dockerfile. Early stages build the app with compilers and dev tools. The final stage copies only the finished files into a small runtime image.

Benefits:

• Much smaller images, because build tools never ship.
• A smaller attack surface, with fewer packages to patch.
• One Dockerfile for build and run, so no separate build scripts.
• Faster pulls and deploys.

FROM node:22 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

Copying the dependency file (package.json) before the source means the install layer stays cached until dependencies change.

What they are checking: Whether you know how to keep images small and use the build cache well.

docker pull nginx:1.27                       # download the image
docker run -d --name web -p 8080:80 nginx:1.27   # run detached, map host 8080 to container 80
docker ps                                    # running containers (-a for all)
docker exec -it web sh                       # shell inside the running container
docker logs -f web                           # follow logs
docker stop web && docker start web          # stop and restart (start runs detached by default)
docker rm -f web                             # remove

• -d runs in the background, -it gives an interactive terminal.
• docker start brings back a stopped container in the background. Add -a to attach.
• Use bash instead of sh if the image includes it.

What they are checking: Whether you have hands-on daily Docker command fluency.

Docker Compose describes all the services, networks and volumes of an app in one compose.yaml. It starts them together.

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

docker compose up -d --build
docker compose logs -f web
docker compose down

Compose puts services on a shared network, so web reaches the database simply as db. It is ideal for local development and small single-host setups; use Kubernetes for production scale.

What they are checking: Whether you can model a multi-service stack and understand service discovery by name.

-p HOST_PORT:CONTAINER_PORT publishes a container port on the host. Traffic to the host port is forwarded to the container.

docker run -d -p 8080:80 nginx          # host 8080 -> container 80
docker run -d -p 127.0.0.1:5432:5432 postgres   # only reachable locally
docker run -d -P nginx                  # publish all EXPOSEd ports on random host ports

For several services on one host, give each a different host port (-p 8081:3000, -p 8082:3000). The container ports can be the same because each container has its own network namespace. In Compose use ports: ["8081:3000"].

For many sites on the standard ports 80 and 443, put a reverse proxy (nginx, Traefik) in front. Route by hostname instead of opening many ports.

What they are checking: Whether you understand host versus container ports and a sane way to host several services.

A Dockerfile is read top to bottom, and each instruction adds a layer or metadata.

• FROM picks the base image.
• WORKDIR sets the working directory for the later instructions.
• COPY copies files from the build context into the image.
• RUN executes a command at build time (install packages, build code).
• EXPOSE documents the port the app listens on. It does not publish it.
• CMD is the default command at container start.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]

What they are checking: Whether you can read and write a basic Dockerfile and know each step's purpose.

ENTRYPOINT defines the program that always runs. CMD supplies default arguments to it. When both exist in exec form, the container runs ENTRYPOINT + CMD.

• Arguments after the image name in docker run replace CMD but are appended to ENTRYPOINT.
• To replace ENTRYPOINT itself, use docker run --entrypoint.

A network driver decides how containers connect to each other and the outside world.

Docker is a platform that packs an application and its dependencies into a container image. The image runs the same way on any host with a container runtime. Containers share the host kernel. So they start in seconds and use much less memory than virtual machines.

Write a Dockerfile that installs dependencies and sets the start command.

An image is a read-only template made of layers. A container is a running (or stopped) copy of that image, with a thin writable layer on top.

Use COPY for plain file copying; ADD does the same plus two extras that are usually unwanted.

Each instruction creates a layer. Docker reuses a cached layer when the instruction and its inputs have not changed. Once one layer changes, every layer after it is rebuilt.

So put things that change rarely first and things that change often last. The classic case is dependencies before source code:

All three give a container storage outside its writable layer. They differ in who manages it and where it lives.

Log in, tag the image with the registry path, then push.

ARG is a build-time variable; ENV is set in the image and is available at runtime too.

On a user-defined bridge network, containers find each other by container name or service name. Docker's built-in DNS does this.

• Virtual environment (venv): isolates only Python packages inside one machine. It does not isolate the OS, system libraries, processes or network.
• Container: isolates a whole process tree, filesystem and network using kernel namespaces and cgroups, but shares the host kernel. Light and fast, and it packages system libraries too.
• Virtual machine: a full guest operating system with its own kernel on a hypervisor. Strongest isolation, but heavier and slower to start.

Container filesystems are temporary, so data must live in a volume outside the container layer.

A .dockerignore file lists paths that Docker must leave out of the build context. It works like .gitignore does for git.

Use docker logs for output and docker stats for live resource usage.

stop shuts a container down gracefully, kill stops it immediately, and rm deletes a stopped container.

Attack both: smaller layers and better cache use.

Image size

• Use a slim, alpine or distroless base. Use multi-stage builds so compilers stay out of the final image.
• Combine related RUN steps and clean caches in the same layer (apt-get install --no-install-recommends then remove /var/lib/apt/lists/*).
• Use a .dockerignore to keep .git, node_modules and logs out of the context.

Build time

• Order instructions from least to most frequently changing: copy package.json or requirements.txt, install, then copy the source.
• Use BuildKit cache mounts (RUN --mount=type=cache,target=/root/.cache/pip pip install ...).
• In CI, reuse cache with --cache-from/--cache-to (registry or GitHub Actions cache), and build independent stages in parallel.
• Pin base images so the cache is not invalidated by surprise.

Measure with docker history and docker build --progress=plain to see which step is slow.

What they are checking: Whether you understand layer caching and can name concrete, practical optimisations.

Use a full Node image to install and build. Then use a slim or distroless image to run only the production output.

FROM node:22 AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM deps AS build
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER nonroot
EXPOSE 3000
CMD ["dist/server.js"]

• Build stage: node:22 (or -slim) has npm and build tooling.
• Runtime stage: node:22-alpine or distroless for a small, low-attack-surface image.
• The package files are copied first so npm ci stays cached.
• For Next.js, enable output: "standalone" and copy .next/standalone and .next/static.
• Add a .dockerignore for node_modules and .git.

What they are checking: Whether you can write a production-grade Dockerfile with caching, small runtime and non-root user.

• Minimal base images (slim, distroless) with fixed versions or digests. Use multi-stage builds so build tools are not shipped.
• Run as non-root: add USER app in the Dockerfile; in Kubernetes set runAsNonRoot: true.
• Scan images in CI (Trivy, Grype, ECR scanning) and fail on critical CVEs. Rebuild regularly for patches.
• No secrets in images or build args. Use runtime secrets or BuildKit secret mounts.
• Least privilege at runtime: read-only root filesystem, drop Linux capabilities, no --privileged, never mount /var/run/docker.sock.
• Trusted sources: pull from verified registries and sign images (cosign).
• Use a .dockerignore so .env and .git never enter the build context.

RUN addgroup -S app && adduser -S app -G app
USER app

What they are checking: Whether you apply defence in depth to the image and runtime, not just one fix.

Two options:

Registry (best): push to Docker Hub, AWS ECR, GitHub Container Registry or a private registry. Then the other person pulls it.

docker tag myapp:1.0 registry.example.com/team/myapp:1.0
docker login registry.example.com
docker push registry.example.com/team/myapp:1.0

Use a multi-stage build: the SDK image compiles, and a small ASP.NET runtime image runs the published output.

Containerise each service separately and route to them through one entry point.

Docker is a client that talks to a daemon. The daemon hands work to lower-level parts that use Linux kernel features to isolate processes.

Never use ARG, ENV or COPY for secrets, because they stay in image layers and docker history. Use BuildKit secret mounts. They show the secret only during one RUN step and never write it to a layer.

latest is just a movable label, not the newest version by magic. It makes deployments non-reproducible: two hosts can pull different images under the same name, and rollback is unclear.

Scan images in CI, use small trusted bases, and rebuild regularly.

Use Docker Buildx (BuildKit) to build a multi-platform image and push it as one manifest list. Each machine then pulls the version for its own architecture.

Keep one base Compose file and layer environment-specific differences on top.

The Docker socket is the API of the daemon, which runs as root. A container that can talk to it can start a privileged container that mounts the host filesystem. So access to the socket is the same as root on the host.

Match the tool to the scale and operational needs.

First find out what is using space, then prune what is unused.

docker system df            # usage by images, containers, volumes, cache
docker container prune      # stopped containers
docker image prune -a       # images not used by any container
docker builder prune        # build cache
docker volume prune         # unused volumes (check first, this deletes data)
docker system prune -a      # most of the above in one go

• Be careful with volumes: unused volumes can still hold database data.
• Large container logs are a common culprit. Set log rotation in /etc/docker/daemon.json ("log-driver": "json-file", "log-opts": {"max-size": "10m", "max-file": "3"}).
• Prevent a repeat with a scheduled prune, smaller images, and disk alerts.

What they are checking: Whether you can diagnose disk usage and clean up safely without deleting live data.

Work from outside in.

A container exits when its main process (PID 1) ends, so find out why that process stopped.

Inside a container, localhost means the container itself, not the host or another container. So the app connects to nothing.

Running as non-root is the secure default, but it often breaks things written assuming root.

A 10-second stop usually means your app never got SIGTERM. Docker waited for the grace period and then sent SIGKILL.

Exit code 137 is 128 + 9, meaning the process was killed by SIGKILL. The most common reason is the kernel OOM killer, after the container hit its memory limit. But docker kill or a failed clean stop also give 137.

It means something already listens on that host port, either another container or a host process.

Find the owner:

docker ps --format 'table {{.Names}}\t{{.Ports}}'
sudo ss -ltnp | grep ':8080'

CI runners are usually clean machines with no local cache, so every build starts from zero. Fix that first, then optimise the Dockerfile.

Containers remove many differences, but not all. Compare what is still different.