Kubernetes interview questions that test operating skill, not recall

Search this exact phrase and you will find lists of forty, sixty, a hundred Kubernetes interview questions, each with a model answer to memorise. The lists are popular with both sides: candidates rehearse them, interviewers read from them, and everyone performs a small play in which "what is a Pod?" is asked and answered as though either party learned something.

The received wisdom is that more questions mean better screening. We think a question is only as good as what its answer reveals, and most reveal one thing: whether the candidate read the same list you did. The questions below are organised by what they actually probe, with what a strong answer sounds like and the follow-up that separates a rehearsed answer from a real one. Candidates: this is also, deliberately, a guide to what is worth being able to do rather than say.

Four things a question can probe

Recall is the cheapest thing to test and the least predictive: definitions are one search away on the job, and knowing them proves study, not operation. The questions worth asking probe one of four deeper things: whether the candidate holds a working mental model, whether their debugging has an order, whether they understand what choices cost, and whether they have genuinely been present when things broke.

The questions at a glance: the kubectl apply walk-through, the Service selector, first three commands on a CrashLoopBackOff, proving a NetworkPolicy is the culprit, requests and limits at the extremes, the case against a liveness probe, and a failure you caused. Seven questions is not many, and that is deliberate: each one carries follow-ups, and the follow-ups are where the interview actually happens.

Probing the mental model

Walk me through what happens when you run kubectl apply on a Deployment

A strong answer moves through the chain in order: the API server validates and persists to etcd, the Deployment controller notices and creates a ReplicaSet, the ReplicaSet controller creates Pods, the scheduler binds unscheduled Pods to nodes, and each node's kubelet pulls images and starts containers. It does not need to be exhaustive; it needs to be causal. The candidate who says "the controller notices the difference between desired and actual state" has the reconciliation model that all of Kubernetes is built on. The candidate who recites resource-type definitions has a vocabulary.

The follow-up: "Where in that chain would a typo in the image name surface?" This cannot be answered from the list, only from the model: everything up to scheduling succeeds, because nothing before the kubelet ever pulls an image, and the failure appears as ErrImagePull on a scheduled Pod. Watching a candidate reason to that answer is worth more than the first answer entirely.

What does a Service selector do, and what happens when it matches nothing?

This reveals whether Services are understood as a real mechanism (label-selected endpoints, with selectorless Services as the deliberate exception) or a magic word. The strong answer mentions that the Service exists and resolves but has no endpoints, and traffic goes nowhere: a distinction that has cost most operators an hour at some point.

Probing failure reasoning

A Pod is in CrashLoopBackOff: your first three commands, and why

The order matters more than the commands. Strong answers start with evidence the container left behind: kubectl describe pod for events and the last state, then kubectl logs --previous for what the dying container said, and only then wider context. The --previous flag is a small, reliable signal: people who have debugged a crash-looping container know to reach for the previous instance's logs early; people who have not often do not know the flag exists.

The follow-up: "The logs are empty. Now what?" This is where diagnosis order shows. The container may be dying before the process writes anything, which points at the exit code, the image entrypoint, or a failing init sequence rather than application logic. A candidate who asks what the exit code is has an investigative structure; 137 and 143 tell very different stories, and knowing that unprompted is operating experience speaking.

How do you prove a NetworkPolicy is what broke connectivity?

This probes the same skill in a domain where guessing is expensive. Strong answers involve reproducing the path deliberately (a test pod matching the client's labels, or temporarily labelling the policy's scope) rather than reading YAML and asserting.

A rehearsed answer survives the question. It rarely survives the follow-up.

Probing trade-off judgement

How do you set requests and limits, and what goes wrong at each extreme?

This question has no single correct answer, which is the point. Strong answers reason about both failure modes: requests set too low overcommit the node and invite pressure evictions; limits set too tight produce OOM kills under legitimate load; requests equal to limits (cpu and memory, on every container) buys Guaranteed QoS at the price of utilisation. The candidate who mentions observing the actual working set before choosing numbers is describing something they have done, not something they have read.

When would you deliberately not add a liveness probe?

This is the sharper version of the usual probe-definition question. It reveals whether the candidate knows what probes cost: a liveness probe that fails during a long GC pause or a slow dependency turns a degraded service into a restart storm. People who have been paged for that answer this question differently from people who learned that probes are "best practice".

Probing scar tissue

Tell me about a Kubernetes failure you caused

The initial answer matters less than its behaviour under detail. Real incidents survive specifics: what the symptom looked like, what was checked first, what the misleading clue was, what the kernel log or the events actually said, what changed afterwards. Rehearsed or borrowed incidents go abstract exactly when you push for detail, because the detail was never lived. Two or three gentle follow-ups ("what did the events say?", "why was that the wrong first hypothesis?") are usually enough to tell the difference, without ever feeling like an interrogation.

This is the probe most worth protecting time for, and the one the question lists cannot help anyone rehearse.

The honest limit of even good questions

Everything above still happens in a conversation, and conversations measure conversation. On the evidence ladder, interview performance sits at level four of five: heavily confounded by confidence, rehearsal, and interviewer skill, and it systematically flatters fluent talkers over quiet operators. Better questions raise the floor; they do not change what the instrument measures. Time pressure cuts the other way too: four probes done properly fill most of an hour, and the temptation to cover more ground by going shallower is exactly how interviews decay back into recall.

So treat question quality as necessary, not sufficient. The strongest signal remains watching someone operate: a real environment, a real failure, and the diagnosis happening in front of you rather than being narrated from memory.

Where we fit in

For hiring teams, the questions above are the conversation layer, and we would use them exactly as written. The verification layer is where SkillBricks sits: candidates prove the same skills these questions probe by fixing real failures in live Kubernetes environments, with the full process recorded, so by the time you interview, the operating evidence already exists and the conversation can be about judgement and fit. Structured take-homes and paid pair sessions are honest alternatives; both cost more interviewer time than reading a wall. If that ordering appeals, here is how it works for hiring teams.

For candidates, the uncomfortable and liberating truth is the same: the way to answer operating questions well is to have operated. Break a cluster on purpose, fix it, and do it again; these five scenarios are a place to start, and a wall of verified proof means the interview stops being the only place you get to show it.