Docker Interview Questions and Answers

Attack the layers, base image, and build context.

• Use a minimal base: alpine, distroless, or scratch for static binaries.
• Use multi-stage builds: compile in one stage and copy only artefacts.
• Combine RUN commands and clear package caches in the same layer:

RUN apt-get update && apt-get install -y --no-install-recommends curl \
  && rm -rf /var/lib/apt/lists/*

• Add a .dockerignore to exclude .git, node_modules, and build output from the context.
• Remove dev dependencies in the final stage, for example npm ci --omit=dev or pip install --no-cache-dir.
• Copy only the files the runtime needs.
• Inspect with docker image history or the dive tool to find the largest layers.

docker images app:1.0
docker history app:1.0

Smaller images pull faster, start faster, and expose fewer vulnerabilities.

A container stops when its main process exits, so first find out why the process ended.

1. Inspect the exit code and state.

docker ps -a
docker inspect --format '{{.State.ExitCode}} {{.State.Error}}' web

Common codes: 0 means the process finished normally, often a misconfigured entrypoint that does not stay in the foreground; 1 is a generic application error; 137 indicates SIGKILL, often OOM, so check docker inspect for OOMKilled true; 126 or 127 mean the command was not found or not executable.

1. Read logs from the crashed container with docker logs web.
2. Run interactively to debug: docker run -it --entrypoint sh web.
3. Check resource limits, missing environment variables, volume permissions, and whether the command runs in the foreground.

For daemons that background themselves, run them in the foreground, such as nginx -g 'daemon off;'.