CKA Troubleshooting Practice Question
You have a Pod that is in CrashLoopBackOff. Which TWO of the following commands would be most helpful in diagnosing the issue?
⚠ Common exam trap
The trap here is that candidates often pick `kubectl logs <pod-name>` (option D) without `--previous`, not realizing that in a CrashLoopBackOff the current container may have no useful logs, while the previous terminated container holds the error details.
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 logs <pod-name> --previous
Option B, `kubectl logs <pod-name> --previous`, is correct because CrashLoopBackOff means the container has already restarted, so the `--previous` flag retrieves the logs from the last terminated container instance, which typically contains the actual crash/error output that caused the failure. Option C, `kubectl describe pod <pod-name>`, is correct because it shows the Pod's status conditions, container states (Waiting/Terminated with reason and exit code), restart count, and recent events such as image pull errors, OOMKilled, or failed probes, which are essential for pinpointing why the container keeps crashing. Option A, `kubectl get events --all-namespaces`, is not the best choice because it returns a broad cluster-wide event stream that is noisy and not scoped to the specific Pod, making it less efficient than describing the Pod itself. Option D, `kubectl logs <pod-name>`, is not the most helpful here because without `--previous` it targets the current container instance, which may not have produced logs yet or may not exist if the container is stuck restarting. Option E, `kubectl top pod <pod-name>`, is incorrect because it only reports CPU and memory usage metrics and provides no diagnostic information about the crash cause.
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 get events --all-namespaces
Why it's wrong here
While this command retrieves events across the entire cluster, it creates unnecessary noise and is highly inefficient for troubleshooting a specific pod. The relevant lifecycle events for the crashing pod are already aggregated and more easily viewed directly via the pod's description command.
- ✓
kubectl logs <pod-name> --previous
Why this is correct
When a container crashes and restarts, standard log commands only show the output of the currently running instance. Appending the `--previous` flag retrieves the stdout and stderr logs from the prior, terminated instance of the container, which typically contains the stack trace or error that caused the crash.
- ✓
kubectl describe pod <pod-name>
Why this is correct
This command provides a detailed breakdown of the pod's current state, including the container's termination state, exit code, and the last state's reason. It also lists the pod's event history at the bottom, highlighting recent scheduling, pulling, or execution failures.
- ✗
kubectl logs <pod-name>
Why it's wrong here
Running this command without the `--previous` flag only streams logs from the currently active, restarted container instance. Because the pod is in a restart loop, the current container may have just started and not yet reached the error state, leaving the actual crash logs inaccessible.
- ✗
kubectl top pod <pod-name>
Why it's wrong here
This command queries the Metrics Server to display the real-time CPU and memory consumption of the pod's active containers. It does not provide historical crash data, exit codes, termination reasons, or application logs necessary to diagnose why a container is repeatedly failing.
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
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.