Kubernetes Troubleshooting & Scenario Interview Questions

Scenario: "A Pod shows CrashLoopBackOff. Walk me through it."

Say what the status means first — the container starts, exits, and kubelet is restarting it with growing backoff delay, so the app itself is failing, not Kubernetes. Then: kubectl describe pod for the Events (was it OOMKilled? a failed liveness probe forcing restarts?), then kubectl logs --previous for the crash's actual error, since the current attempt's logs are often empty. Common root causes to name: a bad config value, an unreachable dependency (database, downstream service), or a liveness probe misconfigured so aggressively it kills a healthy-but-slow-starting app.

Scenario: "A Pod is Pending and has been for ten minutes."

kubectl describe pod's Events will name the exact reason — walk through the ranked list from Post 9: insufficient CPU/memory on every node, a taint with no matching toleration, an unbound PVC, or a node-affinity rule nothing satisfies. Mention kubectl describe nodes to check for resource pressure cluster-wide if no single Pod-level reason jumps out.

Scenario: "ImagePullBackOff on a brand-new deployment."

In order of likelihood: a typo in the image name or tag, a private registry with a missing or wrong imagePullSecret, or registry rate-limiting. kubectl describe pod's Events line usually states which one outright — read it before guessing.

Scenario: "A Pod keeps getting OOMKilled. Increase the memory limit — good fix or not?"

Good answer: it depends, and say why. If it's one anomalous spike, raising the limit is reasonable. If usage climbs steadily over the Pod's lifetime, that's a memory leak, and raising the limit only buys time before the same crash recurs at a higher ceiling. Check kubectl top pod history or a Grafana panel for the trend shape before deciding which one it is.

Scenario: "The app works via port-forward straight to the Pod, but not through its Service."

This isolates the bug to the Service layer, not the app — say that explicitly, it's the whole point of the port-forward test from Post 14. Then check, in order: does kubectl get endpoints <svc> show any Pod IPs at all (if empty, the Service's selector doesn't match the Pods' labels); does the Service's targetPort actually match the container's listening port; is a NetworkPolicy blocking traffic on that path.

Scenario: "Pods can't resolve each other's Service names."

Check CoreDNS is actually running: kubectl get pods -n kube-system -l k8s-app=kube-dns. If it's healthy, exec into the calling Pod and check its /etc/resolv.conf for a sane nameserver entry, and try resolving with nslookup from inside the Pod to see exactly where resolution fails.

Scenario: "Two Pods in different namespaces can't talk to each other, but same-namespace traffic is fine."

Strong signal it's a NetworkPolicy scoped to a namespace, or the caller is using a short Service name (just my-svc) that only resolves within its own namespace instead of the fully-qualified my-svc.other-namespace.svc.cluster.local. Check both before assuming it's a firewall/CNI issue.

Scenario: "Ingress returns a 404 or 502 for a route that should exist."

Confirm the Ingress Controller Pod itself is running first. Then check the Ingress resource's host/path rules actually match the request, that the backing Service has healthy Endpoints (a 502 with correct routing usually means the backend Service has zero ready Pods), and that a TLS secret referenced by the Ingress actually exists if HTTPS is involved.

Scenario: "A node shows NotReady."

kubectl describe node <name> and read its Conditions: DiskPressure, MemoryPressure, or a kubelet that's stopped reporting entirely (network partition, kubelet crash, or the node genuinely being down). Pods already on that node will eventually be evicted and rescheduled elsewhere once it's confirmed unreachable.

Scenario: "New Pods are stuck Pending cluster-wide, not just one Deployment."

This is a capacity problem, not an app problem — say that distinction out loud. kubectl top nodes to find what's actually full, kubectl describe nodes for pressure conditions, and check whether a Cluster Autoscaler is configured and actually succeeding at adding nodes (its own logs will show IAM or quota failures if it's silently failing to scale).

Scenario: "The API server feels sluggish and kubectl commands are timing out cluster-wide."

Point at etcd health first — it's the most common root cause, since the API server is only as fast as etcd underneath it. Check etcd's own resource usage and disk latency, then check for something hammering the API server with excessive requests (a misbehaving controller in a tight reconcile loop is a classic culprit).

Scenario: "A PersistentVolumeClaim is stuck Pending."

No PersistentVolume satisfies its request — check available PVs' size/access-mode against what the PVC actually asked for, and check the referenced StorageClass exists and its provisioner Pod is healthy if you're relying on dynamic provisioning rather than pre-created PVs.

Scenario: "A 3-replica StatefulSet only ever has Pod-0 running; 1 and 2 never start."

StatefulSets start Pods in strict order (Post 13) — Pod-1 won't even be created until Pod-0 is Running and Ready. So the actual question is why Pod-0 isn't reaching Ready: check its readiness probe and PVC binding first; everything downstream is blocked on that one Pod.

Scenario: "You shipped a new image tag, and the rollout looks stuck partway through."

Check the new ReplicaSet's Pods directly — a stuck rollout almost always means new Pods aren't passing readiness (bad config, can't reach a dependency, crashing outright), so the Deployment is correctly refusing to route traffic to them or scale down the old ones. A PodDisruptionBudget can also block the old ReplicaSet from scaling down if it would violate a minimum-available constraint.

Scenario: "You edited a ConfigMap, but the app is still using the old values."

Env vars sourced from a ConfigMap are only read once, at container start — updating the ConfigMap doesn't push new values into a running container. Volume-mounted ConfigMap files do update live (with a short propagation delay), but most apps don't hot-reload config from disk either. The fix in both cases is usually a rolling restart: kubectl rollout restart deployment/<name>.