You push a new version of a service and within two minutes the pods are all showing CrashLoopBackOff. The team is watching you share your screen. Walk me through exactly what you do.

The follow-ups they ask next

• The logs are completely empty. Now what?

  Empty logs means it died before the app printed anything. Look at describe for image entrypoint errors, a failing init container, a mounted secret that does not exist, or a readonly filesystem. kubectl get events sorted by timestamp is your friend.

• How would you stop this reaching production next time?

  Talk about readiness and liveness probes, a canary or a rolling update with maxUnavailable set low, and running the exact image in a staging namespace with the production config shape.

• The restart count is 400 and the backoff is now 5 minutes. Does that change anything?

  Say that the exponential backoff caps around 5 minutes, so the pod is effectively dead. It also means this has been broken for a while, so check whether an alert should have fired and did not.

What the interviewer is listening for

• Defines CrashLoopBackOff as backoff between restarts, not as a crash type
• Rolls back to protect users before hunting the root cause
• Knows kubectl logs --previous exists and says why it matters
• Reads exit codes 1, 137 and 143 and maps them to real causes

What sinks the answer

• Suggests deleting the deployment or the namespace to make it go away
• Spends ten minutes on root cause while the service is down
• Only reads the current container logs and concludes there is nothing there
• Cannot say what CrashLoopBackOff literally means