Kubernetes interview questions that actually predict skill
Most Kubernetes interview questions test vocabulary, not skill. Here are scenario questions that predict debugging ability, with strong and weak answers.
Search for Kubernetes interview questions and you'll find the same fifty items, endlessly recycled: "What is a pod?" "Explain the difference between a Deployment and a StatefulSet." "What does etcd do?" Every one of them has a canonical answer, every canonical answer is on the first page of Google, and every candidate with a chatbot open in another tab can recite them flawlessly.
Here's the uncomfortable part: even honest perfect answers to those questions tell you almost nothing. Plenty of engineers can define a ReplicaSet and still freeze the first time a rollout wedges at 2 AM. The job is not defining Kubernetes. The job is debugging it.
So stop asking definition questions. Ask scenario questions - and grade the process, not the vocabulary.
Why trivia fails and scenarios predict
A definition question tests recall. A scenario question tests the loop that actually gets exercised on-call: observe, hypothesize, test, verify. That loop is hard to fake, hard to memorize, and - conveniently - the thing you're hiring for.
The other advantage: scenario questions have texture. A weak answer to "what is a liveness probe?" sounds identical to a strong one. A weak answer to "your pods are restarting every 90 seconds and the app team swears nothing changed" sounds completely different from a strong one, because the strong answer contains a method.
Scenario-based Kubernetes interview questions (steal these)
These work in a plain conversation with no lab at all. Real prompts, and what to listen for.
1. "A deployment's pods are stuck in Pending. Walk me through your first five minutes."
Strong answer: starts with kubectl describe pod and reads the Events section
before touching anything. Names the branching causes in some sensible order,
insufficient CPU/memory on nodes, taints without matching tolerations, nodeSelector or
affinity mismatch, unbound PVC, resource quota - and says how each one would show up in
the events. Bonus points for "I'd check whether it's one pod or all of them, because that
splits scheduling problems from node problems."
Weak answer: "I'd restart the deployment." Or jumps straight to a cause ("probably not enough nodes") with no mention of how they'd confirm it. Guessing isn't diagnosis; it's a coin flip with kubectl access. The full diagnostic tree is in our guide to pods stuck in Pending - the interview question is essentially "can you reconstruct that tree from first principles?"
2. "This pod is in CrashLoopBackOff. The logs are empty. Now what?"
Strong answer: knows why the logs might be empty (container dies before logging, or
you're looking at the current container instead of the previous one) and reaches for
kubectl logs --previous, then kubectl describe pod for the exit code and Last State.
Distinguishes exit code 1 (app error) from 137 (killed - OOM or failed liveness probe)
from 0 (the container isn't a long-running process at all). We wrote up the whole tree in
the CrashLoopBackOff field guide; a
strong candidate rebuilds a good chunk of it live.
Weak answer: "Check the logs." The logs are empty; that was the prompt. Candidates who loop on the same check when it returns nothing are showing you exactly what they'll do during an incident.
3. "You bumped a ConfigMap but the app still serves old config. Why might that be?"
Strong answer: knows env vars from ConfigMaps are set at container start and never
update; volume-mounted ConfigMaps do update (eventually), except when mounted with
subPath. Proposes verification - exec in and cat the file - before proposing a fix, and
knows the standard fixes (checksum annotations, a rollout restart).
Weak answer: "ConfigMaps update automatically." Half-true, and the half that's wrong causes the outage.
4. "A service returns 'connection refused' from inside the cluster. Where do you look?"
Strong answer: kubectl get endpoints first - an empty endpoints list means the
selector doesn't match pod labels or nothing is Ready. Checks targetPort vs containerPort,
then readiness probes, then NetworkPolicy. The order matters: it goes from cheapest check
to most expensive.
Weak answer: immediately blames DNS or "the network" without a test that would distinguish either.
5. The judgment question: "Prod is degraded. Deleting the namespace and re-applying would probably fix it. Do you?"
This one has no command-line content at all, and it's the best predictor on the list.
Strong answer: asks what's in the namespace first - PVCs? Load balancer services with external IPs? Secrets not in git? - and reaches for the smallest intervention that could work, keeping the destructive option as a last resort with a stated rollback story.
Weak answer: "Sure, it's declarative, just re-apply." That candidate will one day delete something that wasn't in git. We call this dimension blast radius - what you broke or risked while fixing - and it separates senior from junior more cleanly than any definition question ever has.
How to grade the answers
Don't score "got the right cause." Score the process:
- Evidence first. Did they ask what the events/logs/exit codes say before proposing causes?
- Ordered hypotheses. Cheapest check first, most likely cause first - or random walk?
- Verification. Did they say how they'd confirm the fix worked, or declare victory at "it should work now"?
- Blast radius. Did the proposed fix risk more than the outage?
Correctness is worth something, but far less than you'd think - a candidate can land on the right answer by luck and the wrong answer by a reasonable process on incomplete information. Grade the reasoning you can see.
The ceiling on talking, and the upgrade path
Verbal scenarios are a real improvement over trivia, but they have a ceiling: you're grading a description of debugging, not debugging. Some people narrate beautifully and flail at a real terminal; some quiet candidates are surgical the moment their hands are on a keyboard. And a rehearsed candidate can memorize the shape of a good answer to every question above - this article just helped them.
The structural fix is to put candidates in front of an actually broken cluster and watch: a live work sample with a real fault, a time box, and a recording you can replay. That's harder to fake than any conversation, it's fairer to the hands-on-but-nervous candidate, and it's the same argument that killed the take-home, the take-home test is dead for proxy reasons, and trivia dies of the same disease. If you're comparing tools for this, we've surveyed the DevOps assessment platform landscape honestly, including where our own product doesn't fit.
Ask scenarios. Grade process. And when you can, stop asking and start watching.
FAQ
What are the best Kubernetes interview questions for senior engineers?
Scenario questions with ambiguity in them: a pod stuck Pending, a CrashLoopBackOff with empty logs, a rollout that never completes. Senior candidates distinguish themselves by the order of their checks, how they handle a wrong hypothesis, and their caution about destructive fixes - not by knowing more definitions.
Should I ask candidates to define Kubernetes objects at all?
A couple of quick definitional warm-ups are fine to settle nerves and catch outright misrepresentation. Just don't let them carry weight in the decision - they're the cheapest questions to prepare for and the least correlated with on-call performance.
How do I interview for Kubernetes skills without a live cluster?
Use the scenario questions above and insist on specifics: which command, what output you'd expect, what you'd do if that check comes back clean. Push one level past the rehearsed answer. It's a workable stopgap - but a live broken environment, even a small one, gives you signal a conversation can't.
Do scenario questions disadvantage candidates who haven't seen that exact failure?
Less than you'd fear - a good scenario rewards method over recognition, and you should credit a sound process that explores the wrong branch. If a candidate has genuinely never touched the area, swap scenarios; you're probing reasoning, not coverage.
Faultybox runs your candidates through a real broken cluster and shows you exactly how they fixed it - replay included. Free pilot in beta → join