CKA Troubleshooting Practice Question
Exhibit
Refer to the exhibit. $ kubectl get pods -n production NAME READY STATUS RESTARTS AGE api-6f4d7b9d4c-abcde 0/1 CrashLoopBackOff 5 3m $ kubectl describe pod api-6f4d7b9d4c-abcde -n production ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m40s default-scheduler Successfully assigned production/api-6f4d7b9d4c-abcde to node-1 Normal Pulled 3m30s kubelet Container image "nginx:1.21" already present on machine Normal Created 3m30s kubelet Created container api Normal Started 3m30s kubelet Started container api Warning BackOff 1s (x5 over 3m) kubelet Back-off restarting failed container
Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?
⚠ Common exam trap
Many candidates think `kubectl describe pod` or `kubectl get deployment` is needed to check the pod's status or configuration, but the fastest way to see the crash reason is the previous container's logs, not the current (restarted) container's logs which may be empty.
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 api-6f4d7b9d4c-abcde -n production --previous
The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.
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 node node-1
Why it's wrong here
kubectl describe node node-1 surfaces node-level data such as capacity, allocatable resources, taints, conditions, and kubelet events; it never inspects the containers inside individual pods. A CrashLoopBackOff is a pod-level condition driven by the container runtime reporting a failed exit, and this command cannot reveal the container's exit code, stderr, or restart reason. At best, node pressure could explain why kubelet evicted or restarted a pod, but it does not show why the api container itself is crashing.
- ✗
kubectl top pod api-6f4d7b9d4c-abcde -n production
Why it's wrong here
kubectl top pod api-6f4d7b9d4c-abcde -n production displays live CPU and memory consumption gathered from the metrics-server; it is a resource telemetry tool, not a diagnostic tool for container failures. Even if resource limits are being hit, CrashLoopBackOff is fundamentally caused by the application process terminating unexpectedly or failing its startup, health checks, or initialization — none of which appear in a metrics snapshot. High usage might be a consequence of a crash loop, but the command provides no access to the previous container's logs, exit code, or error message.
- ✗
kubectl get deployment api -n production -o yaml
Why it's wrong here
kubectl get deployment api -n production -o yaml emits the desired state of the Deployment: the pod template, container image, environment variables, resource limits, and probe configurations. Because it reflects the declarative spec, it contains no live per-pod restart counters, termination messages, or container logs, so the actual CrashLoopBackOff reason stays hidden. While Deployment status may show available replicas or conditions, it does not tell you whether the current pod's container exited with code 1 or 137, nor what stderr output the previous instance produced before dying.
- ✓
kubectl logs api-6f4d7b9d4c-abcde -n production --previous
Why this is correct
kubectl logs api-6f4d7b9d4c-abcde -n production --previous is the correct command because it fetches the stdout/stderr from the previous, now-terminated container instance in the pod. In a CrashLoopBackOff, the currently restarted container usually has no useful logs — it may not have started, or it immediately restarted before writing anything — while the last crashed instance carries the actual error that triggered the restart. This gives you the application-level failure message (e.g., uncaught exception, missing config, listen EADDRINUSE) needed to fix the root cause; pair it with kubectl describe pod to see the last exit code and restart count.
Go deeper
Related to this question
Learn chapter
Configuring Storage Classes and Dynamic Provisioning
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.