Docker · Advanced interview

Containers are normal Linux processes isolated by kernel features. Namespaces give each container its own view of resources — PID (process tree), NET (network stack), MNT (mounts), UTS (hostname), IPC, and user namespaces. cgroups limit and account for resource usage (CPU, memory, I/O). Together with a layered root filesystem, these make a process feel like it has its own machine while sharing the host kernel.

An image is a stack of read-only layers; a container adds a thin writable layer on top, unified by a storage driver like overlay2 into a single filesystem view. Reads come from whichever layer has the file; when a container writes to a file from a lower layer, it's copied up to the writable layer first (copy-on-write). This makes containers cheap to start and storage-efficient since layers are shared, but heavy writes to large files have copy-up cost.

BuildKit is the modern build engine with parallel execution of independent build stages, better and more granular caching (including remote cache export/import), build secrets and SSH mounts that don't end up in image layers, and improved multi-platform builds. It makes builds faster and more secure — for example, mounting a secret during RUN without baking it into history. It's the default in modern Docker.

Run as a non-root user (USER), use minimal/distroless base images to cut attack surface, drop unneeded Linux capabilities and use a read-only root filesystem where possible, never bake secrets into images, scan images for vulnerabilities in CI, pin base image digests, and keep them updated. Defense in depth: least privilege in the container plus a hardened host and runtime.

Pin base images by digest, minimize dependencies, and scan images (Trivy, Grype, Docker Scout) in CI to catch known CVEs before deploy. Sign images and verify provenance (cosign/SLSA) so you only run trusted artifacts, generate an SBOM to track what's inside, and rebuild regularly to pick up patches. The goal is knowing exactly what's in an image and that it hasn't been tampered with.

Linux capabilities split root's powers into units; you drop all and add back only what's needed (--cap-drop ALL) so a compromised process can't, say, modify the network. seccomp profiles restrict which syscalls the container may make, shrinking the kernel attack surface. A read-only root filesystem (with tmpfs for scratch) stops attackers writing to the container. These reduce the blast radius of a breakout.

Pin everything: base images by digest, package versions, and dependency lockfiles, so the same inputs produce the same image. Avoid pulling 'latest' or unpinned installs, control build args, and use BuildKit caching deterministically. Reproducible builds make security auditing and debugging possible because an image's contents are predictable from its source.

Using BuildKit/buildx you build for multiple platforms (e.g. linux/amd64 and linux/arm64) and push a manifest list — a single tag that points to per-architecture images. The registry then serves the right image for each host's architecture automatically. This matters now that ARM (Apple Silicon, Graviton) and x86 are both common, so one tag works everywhere.

Distroless and scratch-based images contain only your app and its runtime — no shell, package manager, or extra utilities — which minimizes size and vulnerabilities. The trade-off is debuggability: you can't docker exec a shell into them, so you debug via sidecars, ephemeral debug containers, or copying tools in temporarily. For production, the security and size win usually outweighs the inconvenience.

Keep secrets out of images and build args (they persist in layers/history) and out of plain environment variables where possible (they leak via inspect and child processes). Use a secrets manager (Vault, cloud secret stores) or orchestrator secrets mounted as files with tight permissions, injected at run time and rotated. The principle: secrets are provided to the running container, never built into the artifact.

Compose is great for a single host and development, but once you need multi-host scheduling, self-healing, rolling updates with health gating, autoscaling, service discovery across nodes, and declarative desired-state management, you move to Kubernetes (or Swarm/Nomad). The signal is operating many services across multiple machines with availability requirements that manual host management can't meet.

Treat containers as cattle: emit structured logs to stdout shipped to a central store, expose metrics (Prometheus) for resource and app health, and add distributed tracing across services. Tag telemetry with container/service identifiers, set resource and restart policies, and alert on health and resource saturation. Because containers are ephemeral, you never debug on the box — you rely on aggregated telemetry.