›What's the difference between an image and a container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, env, exposed ports) — a template. A container is a running (or stopped) instance of that image, with its own writable layer on top and its own process, network namespace and lifecycle. Many containers can run from the same image simultaneously.
›How do Docker image layers work, and why do they matter for build speed?
Each instruction in a Dockerfile (RUN, COPY, ADD) creates a cached, immutable layer. A rebuild reuses every
layer up to the first one whose inputs changed, then rebuilds everything after it. Ordering instructions from
least- to most-frequently-changing (dependencies before application code) keeps rebuilds fast by maximizing cache
hits.
›What is a multi-stage build, and what problem does it solve?
A Dockerfile with multiple FROM stages, where later stages selectively COPY --from= artifacts out of earlier
ones. It lets you build with a full toolchain (compilers, dev dependencies) in one stage and ship only the compiled
output in a slim final image — smaller image, smaller attack surface, no build tooling in production.
›Why does a container exit immediately after starting?
A container's lifecycle is tied to its PID 1 process — as soon as that process exits, the container stops,
regardless of whether other background processes were started. The usual causes: the image's CMD is a one-shot
script rather than a long-running foreground process, or the actual application crashed on startup — check
docker logs and the exit code from docker ps -a first.
›What's the difference between CMD and ENTRYPOINT?
ENTRYPOINT sets the fixed executable a container always runs; CMD supplies default arguments to it (or the
whole command, if ENTRYPOINT isn't set) that can be overridden at docker run. Combining both — a fixed
ENTRYPOINT with a default CMD — gives you a container that behaves like a configurable binary.
›How does container networking differ from a VM's?
Containers on the same Docker network share the host's kernel and are connected through a virtual bridge, with each container getting its own network namespace (its own interfaces, routing table, ports) — cheap enough to create one per container. A VM virtualizes hardware itself, including a full separate kernel — much heavier isolation, much higher overhead per instance.
›What's the difference between a bind mount and a named volume?
A bind mount maps a specific path on the host into the container — the host's filesystem and permissions apply directly, useful for local development. A named volume is managed entirely by Docker, portable across hosts in orchestrated setups, and is the recommended way to persist data a container writes.
›Why avoid running a container process as root?
A process running as root inside a container that escapes container isolation (via a kernel exploit or
misconfiguration) has root privileges on the host too. Most production images should run as an unprivileged user —
either via a USER instruction in the Dockerfile or a runAsNonRoot policy at the orchestrator level.
›How would you reduce a Docker image's size?
Use a slim or distroless base image, combine related RUN commands to avoid extra layers holding since-deleted
files, clean up package manager caches in the same layer they're created, and use a multi-stage build to leave
build-only tooling out of the final image entirely.