CKA Troubleshooting Practice Question
Which TWO of the following are valid steps to troubleshoot a pod that is in 'CrashLoopBackOff'?
⚠ Common exam trap
CKA often tests the misconception that 'kubectl exec' can be used on a crashed container, but in CrashLoopBackOff the container is not running, so exec fails, while 'kubectl logs --previous' is the correct way to retrieve crash logs.
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 logs pod-name --previous' to view logs from the previous crash
Option B is correct because when a pod is in CrashLoopBackOff the current container is usually not running, so 'kubectl logs pod-name --previous' retrieves the logs from the last terminated container instance, which is essential for diagnosing why it crashed. Option C is correct because 'kubectl describe pod pod-name' shows the pod's status, container states, restart counts, and the event stream (e.g., Back-off restarting failed container, image pull errors, OOMKilled), giving the key context for the crash loop. Option A is not a valid troubleshooting step here because 'kubectl exec' requires a running container, and a pod in CrashLoopBackOff has no live container to attach to. Option D is not a diagnostic step; 'kubectl rollout restart' merely triggers a new rollout and does not reveal the cause of the crash. Option E is also not troubleshooting; deleting the pod just causes the controller to recreate it, and the new pod will likely crash again for the same underlying reason.
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 exec -it pod-name -- /bin/bash' to inspect the container
Why it's wrong here
Running arbitrary commands with `kubectl exec` requires a live container with an active process; if the pod is in CrashLoopBackOff or the container has already exited, the exec API call fails with "cannot exec into a container that is not running". Even if a bash shell exists, the container image may be distroless and lack a shell, making this approach unreliable. It does not, therefore, help you collect crash artifacts from the failed instance.
- ✓
Run 'kubectl logs pod-name --previous' to view logs from the previous crash
Why this is correct
Logs are the first place to look for process exit reasons. `kubectl logs pod-name --previous` retrieves the captured stdout/stderr from the last crashed container instance, whereas the default `kubectl logs` shows the current (possibly non-existent) container. This lets you see the application's actual error, panic, or stack trace that occurred before the crash, even if the current container is in a CrashLoopBackOff state. This makes it a valid and often essential troubleshooting step.
- ✓
Run 'kubectl describe pod pod-name' to see events and state
Why this is correct
While logs show application output, `kubectl describe pod pod-name` reports Kubernetes-side state, including container statuses, restart counts, resource limits, probe results, and lifecycle events such as FailedScheduling, InsufficientMemory, or OOMKilled. These events are not written to application logs, yet they are common crash triggers. The describe output also shows the last state and reason for the container's termination, such as Error or ExitCode 137, giving a fuller picture of why the pod is failing. This is why it is the other valid diagnostic command.
- ✗
Run 'kubectl rollout restart deployment/pod-name'
Why it's wrong here
Restarting the workload with `kubectl rollout restart deployment/pod-name` triggers a rolling update that creates a new ReplicaSet and terminates existing pods, but it does not capture the reason for the original crash. The old pod's logs and events are lost once the pod is deleted, and the new pods may crash with the same underlying defect. Furthermore, if the object is a bare pod rather than a Deployment, a rollout restart is not even a valid command because a Pod has no rollout concept. As such, it is a mitigation tactic at best, not a troubleshooting step.
- ✗
Run 'kubectl delete pod pod-name' to force restart
Why it's wrong here
Deleting a pod forces the controller (e.g., a ReplicaSet or StatefulSet) to replace it, which can be a quick way to regain a healthy state, but it gives you no diagnostic information about why the original pod crashed. Once the pod is deleted, its logs are gone and the only evidence left is whatever was collected by `kubectl logs --previous` before deletion or in an external log aggregator. The replacement pod will very likely repeat the same failure, so you are back where you started without understanding the cause. This is why deletion is considered a restart, not a troubleshooting action.
Go deeper
Related to this question
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
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.