After deploying a new tax-forms API image, Pods enter CrashLoopBackOff. What systematic first path best identifies why the container exits?
Select an answer to reveal the explanation.
Short Explanation
CrashLoopBackOff is the cluster saying the app keeps falling over on boot. Describe for the exit clue, logs for the last words, then fix the image, command, or config. Scaling to zero just hides the patient.
Full Explanation
After a new tax-forms API image rolls out into CrashLoopBackOff, the systematic first path is evidence before drastic cluster changes: kubectl describe on the Pod (or Deployment’s Pods) for container exit codes, termination reasons, and Warning Events, then kubectl logs on the current stream and --previous if the current instance has not yet written useful output. Those artifacts usually reveal bad commands, missing config, failed migrations, or broken dependencies so you can fix the image, command, args, or ConfigMap/Secret wiring and redeploy. That loop is the CKAD-standard crash diagnosis for municipal apps.
Immediately scaling the Deployment to zero and waiting for a cluster upgrade fails because it abandons root-cause analysis; upgrades rarely “clear” an application crash caused by a bad image. Applying a NetworkPolicy that denies all egress fails as a first step because blocking egress may add failures and does not explain why the process already exits on start. Changing the ServiceAccount token audience until the phase becomes Succeeded fails conceptually: Pod phase Succeeded is for completed Jobs/Pods with restartPolicy that finished, not a long-running API Deployment, and token audience tweaks are unrelated to typical CrashLoopBackOff from app start errors.
Exam caveat: distinguish CrashLoopBackOff (process starts then exits) from ImagePullBackOff (image never runs) and from probe-driven restarts. Operational check: kubectl describe pod → note Reason/Exit Code → kubectl logs <pod> --previous → patch image/command/config → watch new Pods leave CrashLoopBackOff with Ready=True.