CKA Troubleshooting Practice Question
You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)
⚠ Common exam trap
The CKA exam often tests the misconception that `kubectl exec` can be used to debug a crashing pod, but in CrashLoopBackOff the container is not running, so exec fails; candidates must remember to use `kubectl logs --previous` to access logs from the terminated instance.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
kubectl describe pod pod-name
`kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
kubectl describe pod pod-name
Why this is correct
kubectl describe pod pod-name is correct for CrashLoopBackOff because it displays the pod's full lifecycle events, container states, restart counts, and the last reason/exit code from the previous terminated container. Those events often reveal the root cause, such as image pull failures, failed readiness/liveness probes, or OOMKilled. It also shows the current backoff state and timestamps, making it the first diagnostic command to run.
- ✗
kubectl delete pod pod-name
Why it's wrong here
kubectl delete pod pod-name is not a useful diagnostic step because it merely removes the current pod object. If the pod is controlled by a Deployment, ReplicaSet, StatefulSet, or DaemonSet, a new pod is created with a fresh backoff timer, but the old pod's events, logs, and crash history are discarded. You lose the very information needed to understand why the container failed, and the new pod will likely fall into the same CrashLoopBackOff.
- ✓
kubectl logs pod-name --previous
Why this is correct
kubectl logs pod-name --previous is correct in a CrashLoopBackOff situation because the currently running container may be between restarts or have no useful output yet. The --previous flag retrieves the stdout/stderr from the last terminated container instance, which often contains the panic, exception, or fatal error that caused the exit. This is the fastest way to see the crash output without waiting for the next restart cycle.
- ✗
kubectl exec -it pod-name -- sh
Why it's wrong here
kubectl exec -it pod-name -- sh is ineffective because CrashLoopBackOff means the container is repeatedly crashing and restarting, so there is no stable running container to attach to. Even during the brief moments the container starts, exec may fail immediately if the process dies before the shell is established, and the underlying issue is in the startup path rather than an interactive environment. The command also requires at least one running container, which usually does not exist in this state.
- ✗
kubectl rollout restart deployment
Why it's wrong here
kubectl rollout restart deployment is not the appropriate first step because CrashLoopBackOff is a pod-level runtime failure, not a rollout or deployment configuration issue. Restarting the Deployment forces a new ReplicaSet and new pods, but if the underlying container command, image, or environment is broken, the new pods will still enter CrashLoopBackOff. It also obscures the diagnostic trail and is irrelevant when the pod is not managed by a Deployment or is not yet ready for a rollout-level intervention.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Pod Failure Troubleshooting
Pod failure troubleshooting is the process of identifying and resolving issues that cause Kubernetes pods to crash, restart, or become unavailable.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
About these practice questions
One of 302 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.