kubernetes

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Asked in nearly every senior Kubernetes loop, and most candidates answer with a feature list. The scoring answer names the three problems it solves and then argues for not adopting it.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

Everyone can recite the three. The scoring answer is what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

The question that finds out whether you know Kubernetes networking or just use it. The model has three rules and everything about CNI follows from them.

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.

The scheduler is behaving correctly, which is the part that confuses people. It optimises placement at admission time and never revisits, so a cluster drifts out of balance by design.

Both solve the same surface problem and they disagree about how. The answer that scores names what each one makes hard, and notices that the GitOps tool you use changes the calculus.

A specific configuration trap with a clean explanation. Both controllers act on the same signal from opposite directions, and the result oscillates.

Default-deny egress breaks name resolution before it breaks anything else, and every connection times out confusingly. The practitioners are the ones who test with positive AND negative probes and know their CNI's fine print.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Candidates who say 'it keeps N pods alive' have just described the part it does not do.

The senior tells are level-triggered reconciliation and finalizer semantics. The partition question separates people who have written a controller from people who have installed one.

The friendliest DaemonSet question there is, and it still separates people who have operated one from people who have read about one. The scheduling rules hide the traps.

Kubernetes does not see GPUs, it sees an extended resource that something has to advertise. When that advertisement is missing or wrong, the scheduler is behaving correctly and the node is lying.

A Job with a sidecar was broken by design for years: the workload finishes, the proxy does not, and the pod never terminates. Native sidecars fix it by making the container an init container that keeps running.

Changing pod resources historically required recreation, which made vertical autoscaling disruptive for workloads with expensive recovery. In-place resize changes that, with limits worth knowing.

Ingress solved routing by convention and annotation, which meant every controller invented its own. Gateway API's real contribution is not features, it is splitting one object into three so that platform and application teams stop editing the same file.

Route attachment and cross-namespace backend access have different owners. Use route status to find the failing boundary before broadening any permission.

The most-asked scenario question in DevOps interviews, and the one where candidates most often list commands instead of reasoning. Empty logs is the clue, not the obstacle.

The gentlest scheduling question there is, and it still separates people who read the events from people who guess. Check whether the pod has a node before choosing between scheduling and startup diagnosis.

The pods are Running, the dashboard is green, and users get errors. The gap between Running and receiving traffic is where this question lives, and it has a precise answer.

Tests whether you know that Kubernetes waits, and for how long. The default timings surprise most candidates, and they explain why a node failure hurts longer than people expect.

Intermittent DNS is the most-reported and least-understood Kubernetes failure. There are three well-known causes and each leaves a different fingerprint.

Low utilisation with terrible tail latency is not a contradiction. It is the CFS quota doing exactly what it was configured to do. Most candidates have never read nr_throttled.

One disk metric explaining a whole cluster's weirdness is the point of this question. Candidates who restart etcd first turn a slow cluster into a down one.

Same-node good, cross-node bad is not a random clue, it is nearly a diagnosis. One short decision tree separates overlay reachability, encapsulation blocks, MTU and policy.

The reflex is rollback and it is usually right. There is exactly one class of failure where undo makes things worse, and knowing it is the entire interview.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

Every client fails at once, which rules out pods and points at shared PKI. Know which certificates share one expiry clock, and the ten-minute fix that avoids a rebuild.

The pods are Pending, the nodes are Ready, and the GPUs have vanished from allocatable. Something changed on the node under a fleet that nobody considered part of the deploy surface.

Workload authentication, traffic encryption and authorization need separate verification. Admission and RBAC constrain who can deploy a workload that bypasses those controls.

Four tools that solve the same sentence and differ on one question: where does the plaintext end up? In a regulated environment that question decides the answer.

Most clusters fail an RBAC review on the same handful of patterns. Naming them concretely, plus the namespace-first design that prevents them, is what separates operators from tutorial readers.

Naming the replacement is the floor of this question. What scores is the audit-then-warn-then-enforce sequence and an honest answer about the vendor chart you cannot fix.

A shared cluster produces one bill and no answer. Attribution is a measurement problem first and a cultural one second, and the number that changes behaviour is not the one finance asked for.

Everyone quotes the discount. Fewer candidates can describe what happens when a notice arrives late or a worker disappears without completing shutdown and why some workloads shrug it off while others lose hours of compute.

Over-requested CPU and memory can prevent efficient node packing. Cutting them safely is a measurement problem with a reliability trap sitting in the middle of it.

The question that separates people running GPU clusters from people running Kubernetes clusters that happen to have GPUs. The answer is that an integer count cannot express what a GPU workload needs.

Three sharing modes with three different isolation guarantees. MIG partitions the hardware, MPS shares the SMs, time-slicing just interleaves contexts, and picking wrong turns a latency SLO into a lottery.

The default scheduler places pods one at a time, which is exactly wrong for a job that needs all sixteen or none. Two half-placed jobs can hold each other's GPUs forever without either ever starting.

The driver, the container toolkit, the CUDA runtime inside the image and the framework build all have to agree. Upgrade the wrong one first and every pod on the node fails to start with an error that names none of them.

A mixed fleet is the normal state, not a transitional one, because capacity arrives when it arrives. The failure is a scheduler that treats two very different cards as the same countable unit.

GPU cost attribution needs allocation records as well as utilization. Separate exclusive reservations from borrowable quota, then reconcile team charges and idle capacity to the actual bill.