KubernetesCoreOpsRazorpaySwiggy
GoogleAsked in SRE, DevOps engineer and Platform engineer roundsRead the full interview experience →PASS
GoogleAsked in SRE, DevOps engineer and Platform engineer roundsRead the full interview experience →PASSA pod is stuck in CrashLoopBackOff right after a deploy. Walk me through how you debug it.
The scenario
You shipped a new image of the payments-api ten minutes ago. Three of the five replicas are in CrashLoopBackOff, two old ones are still serving. The on-call channel is asking whether to roll back.
Model answer
Reviewed by Ankit Sharma- 1Stop the bleeding firstthe old ReplicaSet is still serving, so pause the rollout (kubectl rollout pause) or roll back (kubectl rollout undo) if errors are reaching users.
- 2kubectl describe pod <pod>read Last State, the exit code and the Events. Exit 1 usually means the app threw; 137 means it was killed (OOM or a failed liveness probe); 127 means the command wasn't found.
- 3kubectl logs <pod> --previousthe current container has just restarted, so the useful logs are from the one that died.
- 4Compare the new pod spec with the old oneimage tag, env vars, ConfigMap/Secret refs, command/args, resource limits and probes. A missing env var or secret key is the most common cause.
- 5If the logs are empty, run the image with a shell (kubectl debug, or override the command with sleep) and start the process by hand.
- 6Fix forward or roll back, then add a readiness probe and a progress deadline so a bad rollout stops by itself next time.
The follow-up they'll ask
“The logs from the previous container are empty. What next?”
Empty logs usually mean the process never started: a wrong command or entrypoint, a missing binary (exit 127), a permission problem, or the wrong CPU architecture (exec format error). Override the command to sleep, exec in, and run the entrypoint by hand.
Common mistakes
- Reading kubectl logs without --previous and seeing only the new, empty container
- Deleting the pod and hoping it comes back healthy
- Ignoring the exit code in describe
- Not checking whether the old ReplicaSet is still serving before panicking
Practise it in War Zone · 1 free tryChallenge: inspect a running PodCoreOps · 60 min
Break it and fix it →