CKA Pod CrashLoopBackOff reason Practice Question
A pod is in CrashLoopBackOff state. Which command shows the last termination reason?
⚠ Common exam trap
The trap here is that candidates often reach for `kubectl logs` first, not realizing that in a CrashLoopBackOff the container may have already restarted, so the logs from the last crash are not visible without the `--previous` flag, whereas `kubectl describe pod` directly shows the last termination reason.
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>
The `kubectl describe pod <pod>` command displays detailed information about the pod, including the container state transitions and the last termination reason in the `Last State` field under the container status. This is the correct way to see why the container previously exited, which is essential for diagnosing a CrashLoopBackOff.
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 logs <pod>
Why it's wrong here
kubectl logs <pod> exposes the container's stdout/stderr output, which may reveal an application-level failure, but it cannot show the kubelet's perspective: the restart count, exit code from the last terminated instance, or the Events stream that records failed liveness probe or container create failures. Since CrashLoopBackOff is a scheduling/restart state set by kubelet rather than an app message, logs alone are insufficient to identify the underlying cause.
- ✓
kubectl describe pod <pod>
Why this is correct
kubectl describe pod <pod> aggregates the full object state with a timeline of Events, including the reason, message, and count for failed probes, image pulls, and container starts. It surfaces the container's current waiting reason (e.g., CrashLoopBackOff), last terminated exit code, and the actual error message from the runtime, which together pinpoint why the pod is repeatedly crashing. This is the standard diagnostic first step for a crash loop.
- ✗
kubectl get pod <pod> -o yaml
Why it's wrong here
kubectl get pod <pod> -o yaml retrieves the live pod manifest and its status section, which contains container states, restart counts, and last termination details, but it lacks the ordered Events that explain the sequence of failures. The YAML output is also overly verbose, mixing spec, metadata, and status, and its status conditions update slowly; it may not show transient probe failures or image pull backoff reasons that describe surfaces from the event log. Thus it is inferior for diagnosing the root cause of CrashLoopBackOff.
- ✗
kubectl top pod <pod>
Why it's wrong here
kubectl top pod <pod> reads metrics from the Metrics API (heapster/metrics-server) and reports current CPU and memory usage of the pod's containers, which is irrelevant for CrashLoopBackOff since the pod is restarting before steady-state usage. It provides no access to container state, restart history, exit codes, or events, so it cannot inform why the crash loop is happening. Resource exhaustion can cause crashes, but top shows usage, not OOM kill reasons or liveness probe failures.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓kubectl describe pod <pod>Correct answer▾
Why this is correct
kubectl describe pod <pod> aggregates the full object state with a timeline of Events, including the reason, message, and count for failed probes, image pulls, and container starts. It surfaces the container's current waiting reason (e.g., CrashLoopBackOff), last terminated exit code, and the actual error message from the runtime, which together pinpoint why the pod is repeatedly crashing. This is the standard diagnostic first step for a crash loop.
✗kubectl logs <pod>Wrong answer — click to see why▾
Why this is wrong here
Shows current logs, not termination reason.
✗kubectl get pod <pod> -o yamlWrong answer — click to see why▾
Why this is wrong here
Shows state but not human-readable termination reason.
✗kubectl top pod <pod>Wrong answer — click to see why▾
Why this is wrong here
Shows resource usage, not status.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
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 726 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.