Docker & Kubernetes Interview Questions

Interviewers for DevOps, platform, and backend roles routinely probe whether you understand containers and orchestration well enough to reason about them under pressure, not just recite command syntax. This topic walks through commonly asked questions, organized from Docker fundamentals through Kubernetes operations, with answers that explain the underlying mechanism rather than just the surface-level fact. Use it to check your own understanding: if you can explain each answer in your own words without re-reading it, you are in good shape.

An image is a read-only, layered template containing an application's filesystem and metadata (entrypoint, environment variables, exposed ports). A container is a running (or stopped) instance of an image with its own thin writable layer on top, plus its own process namespace, network namespace, and filesystem view. You can start many containers from the same image; each gets isolated runtime state, but they all share the same underlying read-only image layers on disk, which is why starting a new container is fast and cheap.

A multi-stage build lets you compile or build an application in one stage that has the full toolchain (compilers, build dependencies, SDKs) and then copy only the compiled artifacts into a slim final stage based on a minimal base image. This keeps the shipped image small and reduces its attack surface, because build tools, source code, and intermediate files never end up in the final image. A typical pattern is FROM golang:1.22 AS build to compile a binary, followed by FROM alpine and COPY --from=build /app/bin /app/bin to produce the runtime image.

Any data written to the container's writable layer is deleted permanently when the container is removed, because that layer only exists for the life of the container. To persist data beyond a container's lifecycle, you must use a volume (managed by Docker, e.g. via docker volume create) or a bind mount (a path on the host mapped into the container). Volumes are the preferred mechanism for stateful data like databases because they are portable across hosts with volume drivers and are not tied to the host's directory structure the way bind mounts are.

A Pod is the smallest deployable unit in Kubernetes; it wraps one or more containers that share the same network namespace (so they can talk to each other over localhost) and can share volumes. Kubernetes schedules Pods rather than bare containers because many real workloads need a tightly coupled helper alongside the main container, such as a sidecar for log shipping or a service-mesh proxy, and those containers need to share network identity and lifecycle. Containers within a Pod are always co-located on the same node and are started, stopped, and rescheduled together.

A Service uses a label selector; any Pod whose labels match the selector is added as an endpoint. kube-proxy (or the CNI's equivalent) watches the Endpoints/EndpointSlice objects and programs iptables or IPVS rules on each node so that traffic to the Service's virtual IP is load-balanced across the matching, ready Pods. Because matching is purely label-based and dynamic, Pods can be added or removed (by a Deployment scaling or a rollout) and the Service automatically picks up the change without any manual reconfiguration.

Start with kubectl describe pod <name> to see recent events (OOMKilled, failed liveness probes, image pull errors) and kubectl logs <name> --previous to see the logs from the last crashed instance, since the current instance may not have logged anything useful yet. Common root causes are the application exiting due to a missing environment variable or config, a liveness probe that is too aggressive and kills a slow-starting process, or the container being OOMKilled because its memory limit is too low. If the container never starts at all, check the exit code in the Pod status and the events for scheduling or image-pull issues first.