Debugging a Pod in CrashLoopBackOff

WHAT THIS TESTS CrashLoopBackOff means a container starts, exits, and Kubernetes keeps restarting it with increasing back-off delays. The interviewer checks whether you gather evidence before acting.

A GOOD ANSWER COVERS First, kubectl describe pod POD_NAME. This surfaces the Events section, the container's restart count, its Last State (often Terminated with an exit code and Reason), and any image-pull or scheduling problems. Second, kubectl logs POD_NAME, and importantly kubectl logs POD_NAME --previous. Because the current container instance may have already died, --previous retrieves stdout and stderr from the prior crashed instance, which usually contains the actual stack trace or error message.

COMMON WRONG ANSWERS Deleting the Pod to force a fresh start, which throws away the failing container's history. Restarting the whole Deployment blindly. Only checking kubectl get pods, which shows the status but not the cause.

LIKELY FOLLOW-UPS What exit code suggests an out-of-memory kill? 137, meaning the container was SIGKILLed, often by the OOM killer when it exceeded its memory limit. How would you debug if logs are empty? Exec into a sidecar or use an ephemeral debug container. How does back-off timing work? Delays grow exponentially up to a cap.

ONE CONCRETE EXAMPLE A service crashes on boot. kubectl describe pod shows Reason: Error and exit code 1, plus an event noting the restart count climbing. kubectl logs --previous reveals a fatal error reading a missing environment variable. The fix is adding the variable via a ConfigMap, not restarting the Pod.