Skip to content
SeeItFlow
Interactive guide · 4 chapters · ~18 min read

Docker Interview & Revision

A fast-access reference for the day before an interview, or the five minutes before a design discussion: the questions that get asked, the notes worth re-reading, a quiz to check retention, and a one-page cheat sheet.

Mangesh MandlikLast updated:
01 · What gets asked

Interview Questions

The recurring Docker questions, grouped from foundational to production-grade.

What is the difference between an image and a container?

An image is an immutable, versioned template. A container is a running (or stopped) instance created from an image, with its own writable layer and process.

How is a container different from a virtual machine?

A VM virtualizes hardware and boots a full guest OS; a container virtualizes the OS via kernel namespaces/cgroups and shares the host kernel — no guest OS, no hypervisor, near-instant startup.

What are Docker image layers, and why do they matter?

Each Dockerfile instruction produces a cacheable, shareable, read-only layer. They matter because they enable fast incremental rebuilds and disk-efficient sharing between images.

How do you persist data in Docker?

Named volumes (managed by Docker, portable) or bind mounts (map a host path directly) — both decouple data lifetime from any single container's lifecycle.

How do containers communicate with each other?

Via a user-defined Docker network with built-in DNS, resolving other containers by name — no published host port required for container-to-container traffic.

What happens when a container crashes?

The process exits; depending on the configured restart policy (no / on-failure / always / unless-stopped), Docker may automatically start a new instance.

How would you reduce the size of a Docker image?

Use a minimal base image, multi-stage builds to exclude build tooling, combine and clean up RUN instructions, and use a .dockerignore file.

What's the difference between CMD and ENTRYPOINT?

ENTRYPOINT defines the fixed executable a container always runs; CMD supplies default arguments to it (or the default command if no ENTRYPOINT is set) — CMD is easily overridden at docker run, ENTRYPOINT usually isn't.

How does Docker relate to Kubernetes?

Docker builds and runs a single container; Kubernetes orchestrates many containers across many machines — scheduling, scaling, self-healing, and networking at cluster scale.

What's a health check and why does it matter in production?

A periodic command that verifies the application is actually working, not just that the process is running — used to gate traffic routing and trigger restarts.

02 · The five-minute refresher

Revision Notes

The essential facts, compressed.

Key takeaways
  1. 01Docker packages an app + dependencies into an immutable image; a container is a running instance of that image.
  2. 02Containers share the host kernel via namespaces (isolation) and cgroups (resource limits) — no guest OS, unlike VMs.
  3. 03Images are built from stacked, cacheable, read-only layers; only the container's top layer is writable.
  4. 04A container's data disappears on removal unless it's written to a volume; volumes decouple data from container lifetime.
  5. 05Docker networks let containers reach each other by name; only explicitly published ports are reachable from the host/outside.
  6. 06The same image should run in every environment — configuration differences belong in environment variables, not the image.
  7. 07Restart policies handle single-container crash recovery; orchestrators (Kubernetes) handle recovery and scheduling across many hosts.
  8. 08Multi-stage builds keep compilers and dev dependencies out of the final runtime image.
  9. 09Health checks distinguish 'alive' from 'ready for traffic'; pair them with restart policies and alerting.
  10. 10Avoid relying on the latest tag, running everything as root, or skipping resource limits in production.
03 · Check your understanding

Quiz

Answer each question in your head before revealing the concept below it — this module is most useful the second time through.

Q1. A container and a VM both provide isolation. What's the key mechanism difference?

A: A VM virtualizes hardware and runs its own guest kernel; a container shares the host kernel and is isolated via namespaces/cgroups.

Q2. Why does changing one line of application source usually rebuild quickly?

A: Because Docker's layer cache reuses all unchanged layers (base image, dependencies) and only rebuilds the layer(s) affected by the change.

Q3. You stop a container, then start it again. Is your data still there?

A: Yes — stopping preserves the container and its writable layer. Data is lost only if the container is removed (and wasn't in a volume).

Q4. Your database container's port isn't published to the host. Can your app container still reach it?

A: Yes, as long as both are on the same Docker network — container-to-container traffic doesn't require a published host port.

Q5. A container keeps restarting in a loop. What are the two things you'd check first?

A: docker logs for the crash reason, and docker inspect (or docker stats) for exit code / OOM signs — exit code 137 means SIGKILL, and OOMKilled: true in docker inspect confirms a memory-limit kill.

Q6. Why is deploying with the `latest` tag risky?

A: latest is mutable — the image it points to can change without warning, making deployments non-reproducible and rollbacks unreliable.

04 · One page, everything

Cheat Sheet

The commands and concepts you reach for daily.

bashThe Docker commands used in almost every day-to-day workflow.
docker build -t app:1.0 .          # build an image from a Dockerfile
docker push app:1.0                # push an image to a registry
docker pull app:1.0                # pull an image from a registry
docker run -d --name app-1 \
  -p 8080:80 -e KEY=value \
  --restart on-failure app:1.0     # create + start a container
docker ps                          # list running containers
docker stop app-1                  # stop a container
docker start app-1                 # start a stopped container
docker rm app-1                    # remove a container
docker logs -f app-1               # follow container logs
docker exec -it app-1 sh           # shell into a running container
docker inspect app-1                # full container/config JSON
docker stats app-1                  # live resource usage
docker volume create db-data        # create a named volume
docker network create app-network   # create a user-defined network
docker system prune                 # clean up unused images/containers
Key takeaways
  1. 01Image = template · Container = running instance · Registry = distribution
  2. 02Layers are cached and shared — order Dockerfile instructions least-to-most frequently changed
  3. 03Volumes persist data past container removal — bind mounts map a host path directly
  4. 04Networks give name-based DNS between containers — publish only what truly needs to be public
  5. 05Health checks + restart policies keep single containers self-healing; orchestrators do it at cluster scale