Kubernetes Troubleshooting Interview Questions: Pods, Networking, Storage, and Incidents

Kubernetes troubleshooting interviews reward a disciplined path from symptom to scope to evidence. Start with the workload and namespace, then inspect scheduling, container state, service endpoints, DNS, network policy, volumes, and node health in that order. The Kubernetes documentation's debugging guides are useful because they separate Pod failures, Services, StatefulSets, and storage or networking concerns. A good answer includes commands, hypotheses, what each result means, and the safe mitigation—not a list of kubectl flags.

Quick answer

Question	What the evidence supports	Practical move
A Pod is Pending—where start?	Inspect scheduling events, resource requests, node selectors, taints, and capacity before debugging the container.	Use describe and events to identify the scheduler decision.
A Pod is Running but unavailable	Check readiness, Service endpoints, ports, DNS, and network policy.	Separate process health from traffic routing.
A container restarts	Inspect termination reason, exit code, logs, probes, and resource limits.	Distinguish crash, OOM, and probe failure.
A volume will not mount	Check PVC binding, access mode, node attachment, and filesystem or permission errors.	Trace the storage object chain.
What makes an incident answer strong?	A reversible mitigation plus a plan to prove recovery.	Do not delete the Pod before capturing evidence.

Read this article in three layers. An official provider or employer source establishes what the product or process says. A candidate report can suggest a useful preparation drill, but it does not prove that every candidate sees the same configuration. The final layer is an inference: a tactic that follows from the evidence. Keeping those layers separate prevents a familiar platform name from turning into an invented universal rule.

Build a layer-by-layer triage tree

Begin with kubectl get for the workload, Pods, and namespace, then use describe and events to understand scheduling or admission. A Pending Pod is not a container bug. A Running Pod with zero traffic is not necessarily an application crash. State the layer before choosing a command: scheduler, kubelet, container, Service, DNS, network policy, storage, or node. Kubernetes' troubleshooting documentation is organized around these distinctions, and interviewers want to see the same scope control.

Pod lifecycle and probes

For a restarting container, inspect the last termination state, exit code, logs from the previous container, and resource limits. A liveness probe can kill a healthy-but-slow process; a readiness failure can remove a Pod from Service endpoints without restarting it. Ask whether the failure is deterministic and whether it began after a rollout or config change. Mitigate with a rollback or probe correction only after capturing the evidence that identifies the failure mode.

Networking and Services

A Service routes only to matching ready endpoints. Check labels, selector, endpoints or EndpointSlices, targetPort, and the process's bind address. Then test DNS from a temporary debug Pod and inspect NetworkPolicy or CNI health. A connection timeout, connection refusal, and DNS failure point to different layers. Do not jump to an ingress controller until the Service and Pod path works. Say which packet path you are testing and what a successful observation would prove.

Storage and stateful workloads

Trace the object chain: Pod volume reference, PersistentVolumeClaim, PersistentVolume, StorageClass, node attachment, mount, and filesystem permissions. A PVC stuck Pending is a provisioning or binding issue; a mount error after scheduling is a node or driver issue. StatefulSet recovery also depends on identity and ordered rollout. Preserve the claim and data while investigating. A destructive delete is not a first response unless the incident plan explicitly authorizes it.

Capacity, scheduling, and nodes

A scheduler decision depends on resource requests, taints, tolerations, affinity, topology, and available capacity. Once scheduled, a container can still be OOM-killed because its limit is too low or its workload changed. Inspect node conditions, pressure, kubelet events, and recent deployments. The best interview answer separates requested resources from observed use and explains whether a rollout, autoscaler, or node failure changed the system.

Incident communication and recovery proof

During an incident, state impact, scope, mitigation, and the next observation. A rollback may restore traffic while leaving the root cause unknown; a scale-out may hide a leak. Capture the version, events, logs, and metrics before they rotate. After recovery, verify readiness, error rate, latency, queue depth, and data integrity from the user path. Then write the follow-up change with an owner and rollback plan. Kubernetes fluency includes safe operations, not just commands.

A focused preparation and recovery plan

Step	What to do	Evidence to keep
1. Confirm	Read the invitation, role page, or assessment landing page. Record the deadline, timezone, timer, allowed tools, identity checks, and accommodation contact.	A screenshot or saved message with private details redacted.
2. Baseline	Complete one representative exercise without changing the rules. Measure correctness, time, and the point where you became uncertain.	The prompt, your approach, and a short error log.
3. Diagnose	Separate a content problem from a platform, network, account, or evidence problem. Do not refresh repeatedly while a timer is running.	Timestamped notes, browser version, and visible error text.
4. Rehearse	Repeat the narrow skill this article identifies. Add one adversarial case and one explanation of what would change at larger scale.	A corrected solution or one-page decision record.
5. Escalate	If the official owner must change a deadline, reopen a session, or explain a report, send a concise factual request.	The original invite, incident timeline, and requested remedy.

Frequently asked questions

How do you debug a Pending Pod?

Read scheduler events and check requests, capacity, taints, affinity, and admission before inspecting container logs.

Why is a Pod Running but the Service empty?

Check readiness, labels, selectors, ports, EndpointSlices, DNS, and network policy.

How do you diagnose CrashLoopBackOff?

Inspect previous logs, exit code, termination reason, probes, config, and resource limits.

What is the first storage check?

Trace PVC binding, PV, StorageClass, attachment, mount, and permissions without deleting data.

What should an incident answer include?

A hypothesis, evidence command, reversible mitigation, recovery proof, and follow-up control.

Before you start

Turn the article into a small decision record before you act. Write the exact question you need to answer, the source that could answer it, and the consequence of being wrong. For an assessment, that might be whether the timer stops, whether a second display is allowed, or whether a previous result can be reused. For a technical interview, it might be whether the system promises per-key ordering, whether the verifier can prove a loop is bounded, or whether a cache update can be replayed. This framing keeps preparation tied to the target rather than to a list of fashionable keywords.

Next, separate hard constraints from choices. A deadline, access rule, memory limit, privacy boundary, or source-of-truth requirement is a constraint. A page size, data structure, model pair, retry policy, or practice order is a choice that you should justify. Write one default choice, one alternative, and the signal that would make you switch. Interviewers and recruiters can then see judgment instead of a memorized answer.

Finally, decide what evidence will close the loop. Save a confirmation, a source position, a benchmark row, a test result, a metric, or a recovery ticket. Do not collect private assessment content or credentials. The evidence should be sufficient for the next person to reproduce the decision without exposing information they are not authorized to see. If the evidence is missing, label the conclusion provisional and ask the owner for the exact next action. That discipline is useful whether the page is about a hiring platform, a production system, or a candidate-reported study.

A final quality check is simple: remove any claim that depends on an unnamed company policy, an undated forum anecdote, or a number whose denominator you cannot explain. Replace it with the narrower fact, the verification step, or the limitation. Readers usually need a safe next move more than a confident-sounding prediction. That editorial boundary also makes the draft easier to update when a platform changes its controls or a new hiring cycle starts. Use the same discipline for every source and every handoff.

How to decide what to trust

The live invitation and the instructions shown inside the assessment outrank a generic article. The provider's current help center explains default product behavior, but employers can choose different question types, timers, proctoring controls, report fields, or deadlines. An official employer page establishes the published role or event context; it does not establish every team's interview sequence. Candidate reports are useful when they identify the role, date, and product, yet they remain samples. When two sources disagree, record the conflict instead of averaging it into a made-up number. If a technical incident is involved, preserve the state first, then use the platform's support route or the recruiter who owns the invitation. This approach is slower than guessing, but it gives the reader an action that can be defended and repeated.

Final takeaway

A strong Kubernetes answer moves from the failing layer to evidence, then chooses the smallest reversible fix and proves recovery from the user path.

Sources and Further Reading

• Kubernetes troubleshooting applications
• Kubernetes debug Pods
• Kubernetes Services and networking
• Kubernetes documentation

Research note: Sources checked 2026-09-06. Platform settings, recruiting schedules, and technical documentation can change; verify the exact invitation or current release before acting.