Start with kubectl describe pod for events and the last exit code, then kubectl logs with --previous to read the crashed container's output. Exit code 137 usually means an OOM kill, so check memory limits; exit 1 or 2 usually means the app failed at startup, often a missing config, secret, or unreachable dependency. Confirm the image tag actually exists and check whether an aggressive liveness probe is causing the loop.
Why interviewers ask this
It is a practical competence check: can you actually operate a cluster under pressure or do you only know the concepts. Interviewers want a specific command sequence, the meaning of the common exit codes, and awareness that a crash loop is sometimes caused by the platform (probes, resource limits, node pressure) rather than the application code.
How to structure your answer
- Give the command sequence in order, starting with describe.
- Read the exit code and translate it to a class of cause.
- Use --previous logs, since the current container may not exist yet.
- Check platform causes: limits, probes, secrets, image pull, node pressure.
- Say how you would stabilize while debugging.
Example answer
kubectl describe pod first, because the events section usually tells you outright whether it is an image pull failure, a missing secret, or an OOM kill, and it gives you the last terminated state with the exit code. Then kubectl logs with --previous, since the running container has already been replaced and its logs are gone. Exit 137 is a SIGKILL and nine times out of ten that is the memory limit, so I compare the limit against actual usage rather than guessing. Exit 1 with a stack trace is an application startup failure, usually config. I also check the liveness probe, because I have seen a perfectly healthy Java service crash loop purely because it needed 40 seconds to warm up and the probe gave it 10. To debug calmly I will scale the deployment, exec into a copy with the command overridden to sleep, and reproduce there rather than fighting the restart timer.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you debug a container that crashes before it writes any logs?
- What does exit code 137 tell you, and what would you check next?
- How do you keep a crashing pod alive long enough to inspect it?
Related site reliability engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions