Kubernetes interview scenarios that reveal operational judgment

Published 3 August 2026 · 12 minute read

Strong Kubernetes interviews test how you reason through incomplete information. The best answer names the next evidence, explains what it would prove, chooses a safe intervention, and defines recovery.

A reliable answer pattern

1. Restate the symptom and likely scope.
2. Name the first two or three hypotheses.
3. Choose the highest-signal command or data source.
4. Explain how the result changes the hypothesis.
5. Describe the smallest safe repair.
6. Define objective recovery proof.
7. Add one prevention or observability improvement.

12 production-style scenarios

1. Pods are Running, but the Service has no traffic

Compare Service selectors with Pod labels, then inspect EndpointSlices and readiness. A Running Pod may not be a ready backend. Repair only the mismatched selector, port, or readiness condition and prove an in-cluster request succeeds.

2. A new deployment is stuck in CrashLoopBackOff

Inspect current and previous logs, container state, command, environment, mounted configuration, and exit code. Do not repeatedly restart the Pod. Explain whether the failure occurs before or after application startup.

3. The rollout is stalled with one unavailable replica

Read Deployment conditions, ReplicaSets, Pod events, probes, and image pull state. Decide whether the previous revision is known good enough for rollback or whether a forward-fix has lower risk.

4. A Pod remains Pending after a capacity increase

Scheduler events should lead the answer. Check requests, node allocatable resources, taints, affinity, topology constraints, PVC binding, and admission gates. More nodes do not help when an impossible selector remains.

5. An application receives `Forbidden` from the API

Identify the ServiceAccount, verb, API group, resource, namespace, and binding. Use `kubectl auth can-i --as` to reproduce. Restore the narrow permission rather than granting cluster-admin.

6. The HPA shows unknown metrics

Verify Metrics Server, target resource requests, HPA conditions, and API availability. CPU utilization cannot be calculated when the target containers have no CPU requests.

7. The Gateway returns 503 while Pods are Ready

Read Gateway and HTTPRoute status conditions, parent references, backend reference resolution, Service port, and EndpointSlices. Route acceptance and backend readiness are separate facts.

8. A PVC is Pending

Inspect StorageClasses, access modes, requested size, binding mode, topology, provisioner events, and quota. Do not invent a static PV before understanding dynamic provisioning.

9. A node drain is blocked

Inspect PodDisruptionBudgets, unmanaged Pods, local storage, DaemonSets, and current capacity. Explain how you would add capacity or adjust the budget without removing availability protection blindly.

10. NetworkPolicy breaks DNS

First prove the CNI enforces policy. Inspect selected Pods and egress rules. Allow UDP and TCP 53 to the intended DNS endpoints or namespace, then prove both allowed and denied paths.

11. New Pods remain Pending, but existing workloads run

Suspect the scheduler or scheduling constraints. If the scheduler static Pod is unavailable, the API can still accept objects and existing Pods continue. Confirm component state and restore it.

12. Deployment replicas stop reconciling

If the API accepts the new desired replica count but no ReplicaSet changes, inspect controller-manager health and logs. This distinguishes persistence of desired state from controller execution.

What interviewers listen for

Practice out loud

Use a timer. Spend the first minute framing the symptom and hypotheses, the next minutes describing evidence and intervention, and the final minute defining recovery and prevention. Avoid dumping commands without explaining why each one matters.