40 Docker and Kubernetes Interview Questions, Answered

September 29, 202614 min readBytePatterns

40 Docker and Kubernetes interview questions on images, networking, Pods, rollouts, Services, probes, autoscaling and storage, checked against official docs.

A container round tests two things: whether you know what the tools promise, and whether you know what breaks first. These forty questions start with Docker — images, layers, ports, volumes — and end with a Kubernetes deployment you could defend on a whiteboard.

Every answer is short on purpose: the length you can say out loud in under a minute. Every behaviour described was checked against the Docker and Kubernetes documentation linked at the end. Where a number appears, it is a documented default as of September 2026; defaults change between versions, so say "by default" in the room.

How to use this list

Answer each question aloud before reading ours. If your answer names a feature but not what it costs, it is half an answer: the follow-up is always "and when does that hurt?". Each group links to the lesson that animates it.

Containers and images

The containers lesson animates questions 1 and 2; the images lesson animates 4 and 5.

1. What is a container, and how is it different from a virtual machine?

A virtual machine runs a whole guest operating system with its own kernel. A container is an isolated process with the files it needs, and every container on a host shares the host's kernel. Sharing the kernel is why more of them fit on one machine — and why the boundary between them is thinner than a VM's.

2. What do namespaces and cgroups do?

Namespaces limit what a process can see: each aspect of a container — its processes, network, mounts — runs in its own namespace. Control groups limit what it can use, such as CPU and memory. Docker writes --memory and --cpus into the container's cgroup, and Kubernetes enforces requests and limits through the same mechanism.

3. What is the difference between an image and a container?

An image is a read-only template with instructions for creating a container, built from immutable layers. A container is a runnable instance of an image: the image's layers plus a writable layer of its own. Delete the container and that writable layer is destroyed with it.

4. How does the build cache work, and how should a Dockerfile be ordered?

Each instruction produces a layer, and Docker reuses cached layers. When a layer changes, it and every layer after it are rebuilt. So put expensive, rarely changing steps first — copy the dependency manifest, install — and the frequently edited source last. Then a code change reuses the cached dependency layer.

5. What is a multi-stage build?

A Dockerfile with several FROM instructions, each starting a new stage. A later stage uses COPY --from to take only the artifacts it needs from an earlier one, leaving compilers and intermediate files behind. Name stages with AS so reordering the file does not break the copy.

6. CMD versus ENTRYPOINT?

ENTRYPOINT makes the container run as an executable; CMD supplies default arguments, and only the last CMD counts. Arguments to docker run are appended to an exec-form ENTRYPOINT and replace CMD. Prefer the exec form: the shell form runs under /bin/sh -c, so your process does not receive signals directly.

7. COPY versus ADD?

COPY copies files from the build context into the image, and it is the one for plain copying. ADD does more — it is the tool when you need to download a remote artifact as part of the build — so reach for it only when you need that.

8. How do you keep images small, safe and reproducible?

Use multi-stage builds, exclude irrelevant files with .dockerignore, and pin the base image to a digest so a re-pointed tag cannot change your build. If the service can run without privileges, switch to a non-root user with USER. One concern per container keeps images focused and easy to scale.

Networking and data in Docker

The networking lesson animates questions 9 to 11; the Compose lesson animates 13.

9. What does `-p 8080:80` do, and what does EXPOSE do?

-p 8080:80 maps port 8080 on the host to port 80 in the container. Without a host address, Docker publishes on every host address, so the port is reachable from outside the machine; -p 127.0.0.1:8080:80 keeps it local. EXPOSE publishes nothing: it is documentation between whoever builds the image and whoever runs it.

10. How do containers find each other?

On a user-defined bridge network, containers reach each other by container name as well as by IP. On the default bridge network they can only use IP addresses. In Compose, every service joins the project's default network and is reachable by its service name, on the container port.

11. Volumes versus bind mounts?

Data written to a container's writable layer disappears when the container is removed. A volume is persistent storage created and managed by Docker, and its contents outlive any container that uses it. A bind mount maps a host path into the container — handy for live code in development, but tied to the host's directory layout.

12. How much CPU and memory can a container use?

By default, as much as the host kernel's scheduler allows: there is no limit until you set one. --memory sets a hard memory limit and --cpus caps CPU. Without them, one runaway container can starve its neighbours.

13. What is Docker Compose for, and where does it stop?

Compose declares an app's services, networks and volumes in one compose.yaml and starts them with one command. depends_on orders startup but, by default, waits only until a dependency is running, not ready; condition: service_healthy plus a healthcheck waits for ready. docker compose down keeps named volumes unless you pass -v. Compose drives one Docker Engine — spreading and rescheduling across machines is an orchestrator's job.

Kubernetes building blocks

The objects lesson animates questions 15 to 17.

14. What runs in a Kubernetes cluster?

The control plane: the API server, which exposes the Kubernetes HTTP API; etcd, the consistent key-value store for all API data; the scheduler, which assigns Pods to nodes; and the controller manager, which runs the controllers. On every node: the kubelet, which makes sure Pods are running, a container runtime, and usually kube-proxy, which maintains the network rules behind Services.

15. What is a Pod, and why not manage containers directly?

A Pod is the smallest deployable unit: one or more containers sharing network and storage, so they can talk over localhost. Pods are ephemeral and are not rescheduled — if a node dies, a controller creates a replacement Pod with a new UID. That is why you almost never create bare Pods.

16. ReplicaSet versus Deployment?

A ReplicaSet keeps a stable number of Pods matching its selector running. A Deployment manages ReplicaSets and adds declarative updates: change the Pod template and it creates a new ReplicaSet, scales it up and the old one down. Use Deployments, and never edit the ReplicaSets they own.

17. What does "declarative" mean in Kubernetes?

You describe the desired state; controllers are control loops that watch the actual state and act to move it toward the desired one — the thermostat model. Delete a Pod a Deployment owns and the ReplicaSet recreates it, because the desired count did not change.

18. When do you use a DaemonSet, a Job or a CronJob?

A DaemonSet runs a copy of a Pod on every node (or a chosen subset) — log collectors, node monitoring, storage daemons. A Job runs Pods until a given number complete successfully, retrying failures. A CronJob creates Jobs on a repeating schedule.

19. What are init containers and sidecars?

Init containers run before the app containers, one after another, and each must finish successfully before the next starts — waiting for a dependency, rendering config. Sidecar containers keep running alongside the main container for the Pod's life, for example a log or proxy helper. Init containers do not support probes; sidecars do.

20. What does a namespace isolate?

Names: resource names must be unique within a namespace, not across them. Namespaces scope namespaced objects such as Deployments and Services, but not cluster-wide ones such as nodes, StorageClasses and PersistentVolumes. They cannot be nested, and they are where resource quotas and RBAC Roles apply.

Scheduling and rollouts

The rollout lesson animates questions 21 to 23.

21. How does the scheduler choose a node?

In two steps. Filtering removes nodes where the Pod cannot run — not enough free resources for its requests, constraints it does not satisfy. Scoring ranks the rest, and the Pod is bound to the highest-scoring node. If no node passes filtering, the Pod stays Pending until one does.

22. How does a rolling update work?

The Deployment scales a new ReplicaSet up and the old one down in steps. maxSurge caps how many Pods may exist above the desired count and maxUnavailable how many may be missing; both default to 25%, with surge rounded up and unavailable rounded down, and they cannot both be zero. A new Pod counts only once it is ready, so a version that never becomes ready stalls the rollout instead of replacing the old Pods.

23. How do you roll back, and what starts a rollout?

kubectl rollout undo returns to the previous revision, and --to-revision picks a specific one; old ReplicaSets are kept for this, 10 by default. A rollout is triggered only when the Pod template changes — scaling a Deployment does not start one.

24. Taints and tolerations versus node affinity?

Node affinity attracts Pods to certain nodes. A taint makes a node repel Pods, and a toleration lets a Pod be scheduled onto a node with a matching taint — it allows, it does not require. The effects are NoSchedule, PreferNoSchedule and NoExecute, which also evicts running Pods that do not tolerate it.

25. How do you keep replicas from landing in one zone?

With a topology spread constraint: topologyKey: topology.kubernetes.io/zone, a maxSkew of 1, and whenUnsatisfiable: DoNotSchedule for a hard rule or ScheduleAnyway for a preference. A zone outage then costs a share of capacity instead of the service.

Networking in Kubernetes

The Services lesson animates questions 26 to 28.

26. What is a Service, and which types exist?

A Service gives a label-selected set of Pods one stable virtual IP and DNS name, and Kubernetes keeps its EndpointSlices current as Pods come and go. ClusterIP, the default, is reachable only inside the cluster. NodePort also opens a port on every node, from 30000–32767 by default. LoadBalancer exposes it through the cloud provider's load balancer, and ExternalName maps it to an outside DNS name. A headless Service (clusterIP: None) returns the Pod IPs themselves.

27. How does service discovery work?

Through DNS. A Service gets a name of the form my-svc.my-namespace.svc.cluster-domain.example; from a Pod in the same namespace, the short name my-svc resolves, and from another namespace you add the namespace, as in my-svc.other-ns.

28. Ingress, Gateway API or a LoadBalancer Service?

A LoadBalancer Service is one external entry for one Service, and it also carries protocols other than HTTP. An Ingress routes HTTP and HTTPS by host and path to many Services and can terminate TLS, but only if an Ingress controller is running. The Ingress API is frozen, and the project recommends Gateway API — GatewayClass, Gateway, HTTPRoute — for new work.

29. How do you restrict which Pods can talk to each other?

With NetworkPolicies, enforced by the network plugin — create one on a plugin that does not support them and nothing happens. Pods accept all traffic until a policy selects them; after that, only what some policy allows gets through. Policies only add allowed connections; there is no deny rule.

Configuration and access

The config lesson animates questions 30 and 31.

30. ConfigMap versus Secret, and how does a Pod consume them?

A ConfigMap holds non-confidential key-value data; a Secret holds small sensitive values such as passwords and tokens. Each is limited to 1 MiB. A Pod consumes them as environment variables or as files in a volume. Environment variables are set when the container starts and do not change; mounted files are updated eventually, except through subPath.

31. Are Kubernetes Secrets secure?

Not by default. Their values are base64-encoded, not encrypted, and they are stored unencrypted in etcd; anyone with API or etcd access can read them, as can anyone allowed to create Pods in the namespace. Enable encryption at rest, grant least-privilege RBAC, limit which containers mount them, and consider an external secret store.

32. How does RBAC work?

A Role grants permissions within one namespace; a ClusterRole grants them cluster-wide or on cluster-scoped resources. A RoleBinding or ClusterRoleBinding grants a role to users, groups or service accounts. Permissions are purely additive — there are no deny rules — so least privilege means granting less, not denying more.

Health, resources and scaling

The probes lesson animates questions 33 and 34; the autoscaling lesson animates 35 to 37.

33. Liveness, readiness and startup probes?

A failing liveness probe makes the kubelet restart the container. A failing readiness probe removes the Pod from its Services' endpoints without restarting anything. A startup probe disables the other two until it succeeds, for slow starters. Liveness needs the most care: misconfigured, it restarts containers under heavy load and pushes that load onto the rest.

34. What is CrashLoopBackOff, and what happens when a Pod is deleted?

A container that keeps exiting is restarted with an exponential back-off delay, capped at five minutes — CrashLoopBackOff is that waiting state, not the cause; read the logs of the previous attempt. On deletion, containers receive SIGTERM, get a grace period (30 seconds by default) to finish, then SIGKILL, and the Pod is taken out of Service endpoints while it terminates.

35. Requests versus limits?

The scheduler places Pods by their requests; limits are enforced at run time. A container may use more than its request when the node has room, never more than its limit. Past its CPU limit it is throttled; past its memory limit it can be OOM-killed. Set a limit without a request and the request defaults to the limit.

36. What are QoS classes?

Guaranteed: every container has CPU and memory requests equal to its limits. Burstable: at least one request or limit, but not Guaranteed. BestEffort: none at all. Under node pressure, BestEffort Pods are evicted first, then Burstable, and Guaranteed last.

37. How does the HorizontalPodAutoscaler choose a replica count?

desiredReplicas = ceil(currentReplicas × currentMetric / desiredMetric). Four Pods at 90% CPU against a 60% target gives ceil(4 × 1.5) = 6. CPU utilization is measured against the containers' requests, so without requests the HPA will not act on it. A default tolerance of 0.1 ignores small deviations, and scale-down waits out a stabilization window, 300 seconds by default.

38. HPA, VPA or node autoscaling?

The HPA changes how many Pods run. Vertical Pod Autoscaling changes Pods' resource requests to match actual use. Node autoscaling — Cluster Autoscaler or Karpenter — adds nodes when Pods are Pending for lack of room and consolidates underused ones, judging by requests, not live usage. They compose: the HPA adds Pods, and node autoscaling finds them somewhere to run.

Storage and disruptions

The storage lesson animates question 39.

39. PV, PVC, StorageClass and StatefulSet — how do they fit?

A PersistentVolumeClaim requests storage: a size and an access mode. A PersistentVolume satisfies it, provisioned by an admin or dynamically through a StorageClass, and the two bind one to one. ReadWriteOnce means a single node mounts it read-write. A StatefulSet gives each replica a stable name (db-0, db-1) and its own claim from a volumeClaimTemplate, starts replicas in order, and keeps the claims when you scale down. Dynamically provisioned volumes default to the Delete reclaim policy, so deleting a claim deletes its data.

40. What is a PodDisruptionBudget?

A limit on how many Pods of an application may be down at once from voluntary disruptions, such as a node drain during an upgrade: minAvailable: 2 means the eviction API will not take the app below two. It cannot prevent involuntary disruptions — a node crash still happens, and still counts against the budget.

Watch it run

The animation below is the design lesson's walkthrough: a checkout API behind an Ingress and a Service, three replicas spread across zones, and each safeguard lit on the step where its failure happens. Step through it and name the question each frame answers.

Design a Deployment on Kubernetes

Step 1 of 13

The brief: a checkout API that stays up, scales with traffic, and updates safely. Start at the front door.

The same interactive animation as the lesson — step through it with the controls.

How to say it in an interview

Walk the request path, then the failures. "Traffic enters through an Ingress to a ClusterIP Service; three replicas are spread across zones with readiness probes, so a zone loss costs a third of capacity, not the service. The HPA scales on CPU against the requests, a PodDisruptionBudget keeps drains from evicting too many at once, and rollouts use maxUnavailable: 0 so capacity never dips." Each clause names a mechanism and the failure it handles — that is what separates a design from a list of objects.