CKA Troubleshooting Practice Question
You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. What command would you run to see the reason for the crash?
⚠ Common exam trap
The CKA exam often tests your ability to troubleshoot failing pods. Candidates sometimes confuse `kubectl describe pod` (which shows metadata, events, and container exit codes/termination reasons) with `kubectl logs <pod-name> --previous` (which retrieves the actual application logs from the failed container). Both are critical troubleshooting steps, but `describe` is the primary tool for checking the high-level termination reason and exit code.
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>
B is correct because `kubectl describe pod <pod-name>` provides detailed information about the pod, including the container state, restart count, and the last termination reason (e.g., 'Error' or 'OOMKilled') along with its exit code. To view the actual stdout/stderr logs of the crashed container, you would use `kubectl logs <pod-name> --previous`.
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 top pod <pod-name>
Why it's wrong here
kubectl top reports CPU and memory consumption from metrics-server, giving no container termination reason. It suits capacity and resource-usage checks, but diagnosing a crash requires the previous container's logs or termination details, which top never exposes.
- ✓
kubectl describe pod <pod-name>
Why this is correct
kubectl describe pod surfaces the container's last terminated state, exit code and events, which reveal why the process exited and triggered the restart loop. Logs show application output but not the termination reason, so describe is the direct diagnostic for CrashLoopBackOff.
- ✗
kubectl rollout status deployment <deployment-name>
Why it's wrong here
rollout status reports deployment rollout progress and replica availability, not individual container exit reasons. It suits confirming whether a deployment update completed, but a CrashLoopBackOff cause lives in the container's previous logs, which rollout status does not read.
- ✗
kubectl get events --field-selector involvedObject.name=<pod-name>
Why it's wrong here
Events show scheduling and lifecycle messages, but a crash loop's cause sits in the container's own output, and events often omit the exit reason. Events suit diagnosing scheduling or image-pull failures; container termination reasons need kubectl logs --previous.
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
Log Analysis
Log analysis is the process of reviewing and interpreting system-generated records to understand what happened in an application or infrastructure.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.