A candidate who can define a Deployment, a Service, and a ConfigMap without pausing still fails the round when the interviewer asks why a pod has been stuck in CrashLoopBackOff for ten minutes. The definitions are table stakes. What separates the people getting offers from the people getting polite rejections is whether they can debug a cluster they have never seen, out loud, with nothing but kubectl and a description of the symptoms.
That split shows up in how the questions are laid out. The first few minutes confirm you know the objects. Everything after that is scenario work: something is broken, here is what kubectl get pods prints, walk me through what you do next. If you have only read about Kubernetes and never watched a rollout wedge itself in production, the gap becomes obvious inside two questions.
The objects you are expected to know cold
A pod is the smallest deployable unit, one or more containers that share a network namespace and reach each other on localhost. You almost never create a bare pod. You create a Deployment, which owns a ReplicaSet, which owns the pods, and the reason that indirection matters is rollouts. The Deployment updates the ReplicaSet, old pods drain as new ones come up, and if the new ones fail their health checks the rollout stalls instead of taking the service down with it.
A Service gives that shifting set of pods a stable identity. Pods get a new IP every time they restart, so anything pointing at a raw pod IP breaks constantly. A Service is a stable virtual IP and DNS name that balances traffic across whatever pods currently match its label selector. ConfigMaps and Secrets inject configuration and credentials so you are not baking them into images. If you can explain the Deployment to ReplicaSet to pod ownership chain, and why a Service selector is label-based rather than IP-based, you have cleared the part of the interview that only exists to filter.
CrashLoopBackOff is the question they actually weight
This is the most common scenario question, and interviewers ask it because it separates people who have operated clusters from people who have only deployed to one. CrashLoopBackOff is not an error in itself. It means the container starts, exits, and the kubelet restarts it with an exponentially growing delay, backing off up to five minutes so a broken pod does not hammer the node. The status tells you the container keeps dying. It tells you nothing about why.
The answer they want is a sequence, not a guess. Start with kubectl describe pod and read the events and the last state. If the last state shows exit code 137, the kernel out-of-memory killer took it and the container went over its memory limit. Exit code 1 or 2 is usually the application throwing on startup, a missing environment variable or a config file that never got mounted. Then read the logs from the instance that already died, not the one currently booting:
kubectl describe pod api-7d9f8
kubectl logs api-7d9f8 --previousThe --previous flag is the tell. Candidates who reach for it have done this before, because the running container’s logs are empty or misleading during the backoff window and the crash you care about already happened. Mention it before the interviewer prompts you and you can watch them relax.
Readiness, liveness, and the probe that quietly restarts everything
The probe question is where senior candidates give themselves away, because the three probe types do different jobs and people conflate them. A liveness probe answers whether the container is wedged and should be killed. When it fails past its threshold, the kubelet restarts the container. A readiness probe answers whether the container can serve traffic right now. When it fails, the pod’s IP is pulled from the Service endpoints so no requests reach it, but nothing gets restarted. A startup probe protects a slow-booting app by holding off the liveness check until the app has come up.
The classic incident, and a favorite thing to hand you for diagnosis, is a liveness probe with a timeout shorter than the app’s real startup or garbage-collection pause. The app is fine. The probe times out anyway, the kubelet decides the container is dead and restarts it, the restart takes just as long, and you get a crash loop with clean application logs and no obvious cause. The fix is a startup probe or a longer initialDelaySeconds, and naming that failure mode before the interviewer finishes describing it is exactly the operational signal they are screening for. The official pod lifecycle docs spell out the probe semantics if you want to pin down the thresholds.
What happens to a StatefulSet pod when its node goes NotReady
Most candidates answer this one wrong, which is why it makes a good filter. A node stops heartbeating and goes NotReady. For a Deployment pod, the controller notices the pod is gone after the eviction timeout and schedules a replacement elsewhere, because one replica is interchangeable with another. For a StatefulSet, the pod does not automatically move. The control plane cannot tell a dead node apart from a node that is merely unreachable, and a StatefulSet gives each pod a stable identity and usually a specific volume. Rescheduling mysql-0 onto a new node while the original might still be running and writing to its disk risks two processes writing the same data.
So the StatefulSet pod sits in Terminating or Unknown until the node comes back or an operator forcibly deletes it. That caution is the entire reason StatefulSets exist. If you say it just reschedules, you have told the interviewer you have never run a database on Kubernetes, and for a platform or infrastructure role that tends to close the line of questioning.
How a request actually reaches a pod
Networking questions go one level below the Service abstraction. A ClusterIP Service has no real process listening on that virtual IP. kube-proxy programs the node’s iptables or IPVS rules so packets aimed at the ClusterIP get rewritten to a real pod IP picked roughly at random. NodePort opens the same port on every node and forwards inward. A LoadBalancer asks the cloud provider for an external load balancer that points at those node ports. Inside the cluster, a pod finds a Service by name because CoreDNS resolves my-service.my-namespace.svc.cluster.local down to the ClusterIP.
A sharp follow-up asks what an Ingress adds. A Service balances at L4. An Ingress plus an ingress controller such as NGINX or Envoy does host- and path-based HTTP routing, terminates TLS, and lets many services share one external address. Knowing that an Ingress object is inert without a controller running to act on it is the kind of detail that reads as real experience rather than exam prep.
The failure states worth memorizing
Scenario questions almost always start from one of a handful of pod states. Knowing the likely cause and the first command to run for each is most of what a debugging round rewards.
| Pod status | What it means | Most common cause | First command to run |
|---|---|---|---|
| CrashLoopBackOff | Container starts then exits, restarted with a growing delay | App error on startup, or hit its memory limit (exit code 137) | kubectl logs <pod> –previous |
| ImagePullBackOff / ErrImagePull | Kubelet cannot pull the container image | Wrong image tag, or a private registry with no imagePullSecret | kubectl describe pod <pod> |
| Pending | Pod accepted by the API server but not scheduled to any node | No node with enough CPU or memory, or an unsatisfiable affinity or taint | kubectl describe pod <pod> (read Events) |
| OOMKilled | Container exceeded its memory limit and was killed by the kernel | Memory limit set too low, or a leak in the app | kubectl describe pod <pod> (Last State) |
| Terminating (stuck) | Pod will not finish deleting | A finalizer still pending, or a NotReady node holding a StatefulSet pod | kubectl get pod <pod> -o yaml (check finalizers) |
| Init:0/1 | Stuck in an init container before the main container starts | Init container failing, or waiting on a dependency that never comes up | kubectl logs <pod> -c <init-container> |
Requests, limits, and who gets evicted first
Requests and limits come up constantly, because getting them wrong is how real clusters fall over. A request is what the scheduler reserves, the number it uses to decide whether a pod fits on a node. A limit is the hard ceiling the container is allowed to reach. Cross a memory limit and the container is OOMKilled with no grace period. CPU behaves differently and trips people up: a CPU limit throttles the container instead of killing it, so an app that looks slow under load may just be pinned against its CPU ceiling.
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "256Mi" # hard cap; over this the container is OOMKilled
cpu: "500m" # CPU is throttled here, not killed
# requests below limits -> Burstable QoS classThe part interviewers probe is what happens under node pressure. A pod whose limits equal its requests for both CPU and memory gets the Guaranteed class and is evicted last. A pod with requests below its limits is Burstable. A pod with nothing set is BestEffort and is the first thing the kubelet kills when a node runs short on memory. Shipping a production workload with no requests set tells the scheduler to treat your app as disposable, and saying that plainly shows you understand the tradeoff instead of just the YAML.
The through-line in all of it is that these interviews reward people who have watched things break and then fixed them. You can build that in an afternoon. Run Kind or Minikube locally, deploy something small, then break it on purpose. Set a memory limit of 10Mi and watch the OOMKill land. Point a Service selector at a label no pod carries and see the endpoints go empty. Give a liveness probe a one-second timeout on an app that needs five seconds to boot, and sit with the crash loop it creates. Candidates who do this stop sounding like they read the docs and start sounding like they have been paged at 3 a.m., which is the one thing the interview is really trying to find out.
Keep sharpening your system design:
