Top 30 Intermediate Docker & Kubernetes Interview Questions and Answers
30 intermediate multiple-choice Docker & Kubernetes interview questions, past the definitions: how the pieces fit together, what breaks in practice, and the trade-off behind a choice. They come from 30 bites in the Docker & Kubernetes library, the middle slice of the 144 Docker & Kubernetes interview questions in the library. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
Containers, Helm, orchestration, service mesh
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
A container needs its own eth0 and routing table while its init process appears as PID 1. Which clone flags are required to create it?
Show the answer
Answer: c · CLONE_NEWNET and CLONE_NEWPID
CLONE_NEWNET creates a new Network namespace for isolated interfaces and routing tables, while CLONE_NEWPID creates a new PID namespace so the container's init becomes PID 1. Option A is tempting because it includes the correct PID flag, but CLONE_NEWNS isolates mount points rather than network devices.
Read the full bite: Name three Linux namespaces and explain what each one isolates.
Question 2 of 30
Which component ultimately enforces CPU and memory limits after the container runtime writes the cgroup configuration at startup?
Show the answer
Answer: d · The Linux kernel scheduler and memory manager, using the configured cgroup values
The Linux kernel scheduler and memory manager enforce cgroup limits continuously using values written by the runtime at startup. It is a common misconception that the Docker daemon actively monitors and throttles containers, but the daemon only configures limits while the kernel handles enforcement.
Read the full bite: How do containers enforce CPU and memory limits via cgroups?
Question 3 of 30
Once runc has started the container process, which statement accurately describes its subsequent behavior?
Show the answer
Answer: b · It exits and becomes stateless, leaving containerd to handle stop, delete, and event monitoring.
runc is a short-lived CLI tool that exits after starting the isolated process, while containerd retains lifecycle ownership. The belief that runc stays resident as a daemon is a common misconception; it is stateless and does not monitor cgroups or namespaces after launch.
Read the full bite: Describe the relationship between containerd and runc in starting a container.
Question 4 of 30
Which statement correctly describes the relationship between OCI image layers and OverlayFS in container runtime?
Show the answer
Answer: b · OCI specifies layer tarballs and manifests, while OverlayFS is the in-kernel driver that assembles them at runtime
OCI governs the packaging and distribution of images as tarballs and manifests, while OverlayFS is solely a Linux kernel filesystem driver that mounts those layers at runtime. Distractor B is a common misconception that conflates the runtime driver with the image specification itself.
Question 5 of 30
Why does copying all source before npm install slow down rebuilds after a code change?
Show the answer
Answer: a · The COPY of changed source invalidates the install layer and everything after it
Cache invalidation cascades from the first changed instruction, so copying edited source before install busts the install layer; npm install does respect the cache when its inputs are unchanged.
Read the full bite: Optimize Dockerfile layer caching for npm install
Question 6 of 30
What is the primary benefit of copying only the compiled binary into a minimal final stage of a multi-stage build?
Show the answer
Answer: d · It produces a smaller image with no toolchain or source, reducing attack surface
Discarding the compiler and source yields a small, hardened production image; multi-stage builds do not remove the kernel dependency, add encryption, or make a binary architecture-independent.
Read the full bite: Multi-stage builds for compiled languages
Question 7 of 30
Why is docker exec -it preferred over docker attach when opening a shell to debug a running container?
Show the answer
Answer: d · exec starts a new process, leaving PID 1 untouched, while attach can kill it on Ctrl-C
exec spawns a separate process so the main process is unaffected, whereas attach connects to PID 1's stdio and Ctrl-C can terminate it; attach is not deprecated and exec does run inside the container.
Read the full bite: Debug a running container with the Docker CLI
Question 8 of 30
How does docker image prune (without -a) differ from docker image prune -a?
Show the answer
Answer: d · prune removes only dangling images; -a also removes unused tagged images
Plain prune targets only untagged dangling images, while -a additionally removes any tagged image not referenced by a container; -a is not merely a prompt flag and neither command removes containers.
Read the full bite: What is a dangling image and how to prune it
Question 9 of 30
Why can Compose services resolve each other by name on the default network but containers on Docker's legacy default bridge cannot?
Show the answer
Answer: a · Compose creates a user-defined bridge, which includes embedded DNS, unlike the legacy default bridge
Compose's per-project network is a user-defined bridge with embedded DNS enabling name resolution, whereas Docker's legacy default bridge lacks automatic DNS; Compose neither disables DNS nor uses host networking by default.
Question 10 of 30
Why does adding plain depends_on: [db] often fail to fix a web app crashing on startup against a slow database?
Show the answer
Answer: b · depends_on only orders container start; it does not wait for the database to become ready
Short-form depends_on controls start order but not readiness, so the app may start before the DB accepts connections; you need a healthcheck plus condition: service_healthy. depends_on is neither deprecated nor reversed.
Read the full bite: Manage startup order and readiness in Compose
Question 11 of 30
When should a Compose service use the build directive instead of image?
Show the answer
Answer: d · When the service runs your own application code with no published image
build compiles an image from your local Dockerfile, which is needed for custom application code; stock third-party services use image to pull from a registry, and the size and network claims are irrelevant.
Read the full bite: Compose image directive versus build directive
Question 12 of 30
In a typical web-plus-database Compose setup, which storage choice fits each service best?
Show the answer
Answer: b · Bind mount the source code in dev; named volume for the database data
Bind mounts suit live-reloading source in development, while named volumes give Docker-managed, portable durability ideal for database data; bind-mounting production DB files couples data to a fragile host path.
Question 13 of 30
A pod is stuck in ImagePullBackOff. What is the most informative first troubleshooting step?
Show the answer
Answer: a · Run kubectl describe pod and read the Events to see the exact failure reason
The Events section names the specific cause (auth, wrong name, or network), guiding the fix. Recreating blindly (C) or restarting kubelets (D) wastes time without diagnosis.
Read the full bite: Debugging ImagePullBackOff on a private registry
Question 14 of 30
Why does running apt-get clean in a separate RUN instruction fail to shrink the image?
Show the answer
Answer: c · The cache already persists in the earlier layer, and a later layer cannot delete data from a prior one
Each layer is additive; deleting files in a later layer leaves them in the earlier layer's size. Cleaning must happen in the same RUN that created the cache, so option C is correct.
Read the full bite: Three techniques to shrink a Docker image
Question 15 of 30
When an arm64 host pulls redis:7 that has a manifest list, what does it receive?
Show the answer
Answer: b · The arm64-specific image manifest and layers selected from the index
The index maps platforms to per-arch manifests, so the host selects and pulls its matching variant. It is not merged (C), not emulated by default (D), and one tag serves all arches (A).
Question 16 of 30
After the apiserver stores a new Pod in etcd, what assigns it to a specific Node?
Show the answer
Answer: a · The kube-scheduler watches for unscheduled Pods and binds one to a suitable Node
The scheduler filters and scores Nodes, then writes a binding via the apiserver. kubectl does not pick Nodes (C), and the kubelet only acts on Pods already assigned to its Node (B).
Question 17 of 30
If etcd loses quorum, what is the immediate effect on the cluster?
Show the answer
Answer: c · The control plane cannot accept state changes, but already-running Pods keep running
Without quorum etcd cannot accept writes, so scheduling and changes stop, yet the data plane continues on last-known state. Running Pods are not killed (D) and etcd cannot self-rebuild from kubelets (A).
Question 18 of 30
Why is the reconciliation loop described as level-triggered rather than edge-triggered?
Show the answer
Answer: b · It acts on the current gap between desired and actual state, so it corrects drift even if it missed events
Level-triggered means evaluating current state against desired on every pass, making it resilient to missed events and drift. Edge-only triggering (D) or one-shot runs (A) would fail to self-heal.
Question 19 of 30
Why is a StatefulSet, not a Deployment, the right choice for a clustered database?
Show the answer
Answer: c · Each Pod needs a stable identity and its own persistent volume that survives rescheduling
A StatefulSet gives stable ordinal names, stable DNS, and per-Pod persistent storage that databases require. Deployments treat Pods as interchangeable and can mount volumes (B) but not per-Pod stable ones.
Question 20 of 30
During a rolling update triggered by an image change, what does the Deployment controller actually do with the old ReplicaSet?
Show the answer
Answer: d · Scales it down gradually and retains it at zero for rollback
The old ReplicaSet is scaled down progressively and kept at zero so rollout undo can restore it. Pods are never edited in place, and the old ReplicaSet is not deleted right away.
Question 21 of 30
When you run kubectl rollout undo, how does Kubernetes restore the previous version so quickly?
Show the answer
Answer: b · It scales the previously retained ReplicaSet back up and the bad one down
The old ReplicaSet was kept at zero, so undo just scales it up again. Rollback does not rebuild images or restore data; it only changes the workload's pod template back.
Question 22 of 30
What is the key behavioral difference between a failing liveness probe and a failing readiness probe?
Show the answer
Answer: c · Liveness restarts the container; readiness removes the Pod from Service endpoints
Liveness failure restarts the container, while readiness failure only stops traffic by removing the Pod from endpoints. The first option reverses the two; neither merely logs.
Question 23 of 30
Why is emptyDir the right volume for shared, temporary cache that should vanish when the Pod terminates?
Show the answer
Answer: d · It is created with the Pod, shareable across its containers, and deleted when the Pod is removed
emptyDir lives and dies with the Pod and is mountable by every container in it. PersistentVolumes persist and hostPath ties data to a node, neither of which fits throwaway cache.
Read the full bite: Sharing ephemeral cache between containers in a Pod
Question 24 of 30
A Pod in namespace A must reach Service my-service in namespace B. Which DNS name works?
Show the answer
Answer: c · my-service.B.svc.cluster.local
Cross-namespace resolution requires the form service.namespace.svc.cluster.local. The bare name resolves only within namespace A, the reversed-segment form is invalid, and qualifying with A points at the wrong namespace.
Question 25 of 30
Why is an Ingress preferable to creating a separate LoadBalancer Service for each of several HTTP apps?
Show the answer
Answer: d · Ingress consolidates host/path routing and TLS behind one IP, avoiding a costly cloud load balancer per service
Ingress provides layer-7 host/path routing behind a single load balancer and IP, saving the cost of one cloud LB per service. It does require a controller, operates at layer 7, and LoadBalancers can serve HTTP.
Question 26 of 30
How does DNS resolution of a headless Service differ from a standard ClusterIP Service?
Show the answer
Answer: a · It returns the individual A records of the backing Pods instead of a single virtual IP
A headless Service (clusterIP: None) resolves to the Pods' own IPs as multiple A records, enabling direct addressing. A standard ClusterIP returns one virtual IP that kube-proxy load-balances.
Question 27 of 30
kubectl get endpoints shows no addresses for a Service that exists, while its target Pods are Running. What is the most likely cause?
Show the answer
Answer: a · The Service selector does not match the Pods' labels, or the Pods are not Ready
Empty endpoints means no Pods match the selector or none are Ready, since only ready, matching Pods become endpoints. DNS being down would not empty endpoints, and Services are not node-bound.
Read the full bite: Debugging Service connectivity between Pods
Question 28 of 30
An auditor finds Kubernetes Secrets stored base64-encoded in etcd. What does this encoding actually provide?
Show the answer
Answer: d · No confidentiality; it is a reversible encoding only
Base64 is a keyless reversible encoding that anyone can decode, so it provides no confidentiality. It is not encryption and does nothing to stop an attacker with etcd or RBAC read access.
Read the full bite: Are base64-encoded Kubernetes Secrets actually secure?
Question 29 of 30
Why must private-registry credentials be supplied via a dockerconfigjson Secret and imagePullSecrets rather than container environment variables?
Show the answer
Answer: a · The kubelet pulls the image before any container or its env exists
Image pulling happens in the kubelet before the container starts, so container env vars do not exist yet; the kubelet needs a dockerconfigjson Secret referenced by imagePullSecrets. Env vars are not encrypted and are irrelevant to pull-time auth.
Read the full bite: How do you let Pods pull from a private registry?
Question 30 of 30
Within one namespace, how do you stop a particular Pod from reading a Secret via the API while other Pods can?
Show the answer
Answer: d · Give the Pod a ServiceAccount whose Role omits that Secret
API access to Secrets is authorized by the Pod's ServiceAccount through RBAC, so a dedicated ServiceAccount with a Role that excludes the Secret denies access. NetworkPolicy governs network traffic, and immutability prevents edits, neither controls who can read.
Read the full bite: How do you restrict a Pod's access to a Secret?
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.