CKA Troubleshooting Practice Question
You run 'kubectl get pods' and see that a pod is in CrashLoopBackOff. Which THREE of the following are valid next steps? (Select 3)
⚠ Common exam trap
The CKA exam often tests the misconception that 'kubectl top' or deleting the pod is a valid troubleshooting step for CrashLoopBackOff, when in fact these actions either provide irrelevant metrics or mask the issue without diagnosis.
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
✓
Run 'kubectl describe pod pod-name' to check events
Option A is correct because 'kubectl describe pod pod-name' surfaces the pod's Events section, which shows why the kubelet restarted the container (e.g., OOMKilled, failed liveness probe, image pull issues) and the backoff timing. Option B is correct because 'kubectl logs pod-name' retrieves the container's stdout/stderr, which typically contains the application error that caused the process to exit and enter CrashLoopBackOff; adding --previous shows logs from the prior crashed instance. Option C is correct because the jsonpath query reads .status.containerStatuses[0].state.waiting.reason, which directly returns the waiting reason such as CrashLoopBackOff along with the last termination state, confirming the container's current status. Option D is not appropriate because 'kubectl top pod' only reports live CPU/memory usage from the metrics server and does not explain why the container is crash-looping. Option E is not a valid diagnostic step because deleting the pod merely recreates it (or removes it if managed by a controller) without revealing the root cause, so it does not help troubleshoot the failure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run 'kubectl describe pod pod-name' to check events
Why this is correct
kubectl describe pod pod-name aggregates the pod's current state, recent events, container statuses (waiting/running/terminated), restart counts, and last termination reason into a human-readable summary. This surfaces CrashLoopBackOff events with timestamps, showing whether the container exited due to an error, OOMKill, or probe failure. It is the first step for diagnosing why Kubernetes is restarting the container.
- ✓
Run 'kubectl logs pod-name'
Why this is correct
kubectl logs pod-name streams the container's stdout/stderr, exposing the application-level output that preceded the crash, such as stack traces, panic messages, or missing configuration errors. For a container in CrashLoopBackOff, the log shows the last attempt's output, and adding --previous retrieves logs from the prior crashed instance if available. This pinpoints the app fault, whereas describe shows Kubernetes-level events.
- ✓
Run 'kubectl get pod pod-name -o jsonpath={.status.containerStatuses[0].state.waiting.reason}'
Why this is correct
kubectl get pod pod-name -o jsonpath={.status.containerStatuses[0].state.waiting.reason} directly queries the Pod's status field in the Kubernetes API, extracting the exact machine-readable reason like CrashLoopBackOff, OOMKilled, or ImagePullBackOff without human formatting. This is useful for scripting and automation and avoids parsing describe's verbose output. It reveals the API's view of the container's current state but not underlying app logs.
- ✗
Run 'kubectl top pod pod-name'
Why it's wrong here
kubectl top pod pod-name displays current CPU and memory usage metrics from the metrics server, which is helpful for capacity monitoring but irrelevant to diagnosing a crash loop. A pod in CrashLoopBackOff may not be running long enough to report metrics, or no metrics are collected at all. This command cannot reveal why the container is crashing and will not show events, exit codes, or application errors.
- ✗
Run 'kubectl delete pod pod-name'
Why it's wrong here
kubectl delete pod pod-name removes the pod immediately; if it is managed by a ReplicaSet or Deployment, the controller will recreate it, potentially with the same crash loop. This action neither retrieves diagnostic information nor resolves the underlying problem, and it might briefly increase downtime. It is a remediation step after diagnosis, not a diagnostic tool, and should be avoided when the goal is understanding the failure.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
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.
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.