CKA Investigate ImagePullBackOff Practice Question
You run 'kubectl get pods' and see some pods in 'ImagePullBackOff' state. Which command would best help identify the root cause?
⚠ Common exam trap
CNCF often tests the misconception that `kubectl logs` can retrieve startup errors, but in `ImagePullBackOff`, the container never runs, so logs are unavailable and `describe pod` is the correct tool to inspect the kubelet's event stream and container status.
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>
`kubectl describe pod <pod-name>` provides detailed information about the pod, including the status of its containers, events, and error messages from the kubelet. For an `ImagePullBackOff` state, the `describe` output will show the exact reason for the image pull failure (e.g., invalid image name, registry authentication failure, or network issues) in the `Status` and `Events` sections, making it the most direct troubleshooting command.
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 logs <pod-name>
Why it's wrong here
`kubectl logs <pod-name>` is incorrect because logs are captured only after a container has started and emitted output. In an ImagePullBackOff state, the image could not be pulled, so the kubelet never creates the container; therefore there is no stdout/stderr stream to retrieve, and the command will either return an error like "container is not ready" or nothing at all.
- ✓
kubectl describe pod <pod-name>
Why this is correct
`kubectl describe pod <pod-name>` is the correct command because it aggregates the container's current status (Waiting with reason ImagePullBackOff) and the recent pod Events, including the detailed error message from the container runtime, such as "Failed to pull image" with the specific registry response (e.g., "not found" or "unauthorized"). This single command shows the image name, the node, and a timestamped history of pull attempts, making it the fastest path to diagnose why the image pull failed.
- ✗
kubectl get events --field-selector involvedObject.kind=Pod
Why it's wrong here
`kubectl get events --field-selector involvedObject.kind=Pod` is less precise because although it filters events by the object kind Pod, it still lists events for every pod in the current namespace unless you also add an involvedObject.name selector. Even when the relevant event appears, it only shows the raw event message and lacks the container status, image specification, and restart count that `kubectl describe pod` provides, so it can mislead or require additional commands to pinpoint the failing pod.
- ✗
kubectl exec <pod-name> -- cat /var/log/containers
Why it's wrong here
`kubectl exec <pod-name> -- cat /var/log/containers` is wrong because `kubectl exec` attaches to a running container's process namespace. A pod in ImagePullBackOff has no running container—the container is stuck in a waiting state because the image cannot be pulled—so exec cannot attach, and the command fails immediately. Furthermore, even if the pod were running, container logs are read via `kubectl logs`, not from an arbitrary path, and this approach would not reveal the image pull error itself.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓kubectl describe pod <pod-name>Correct answer▾
Why this is correct
`kubectl describe pod <pod-name>` is the correct command because it aggregates the container's current status (Waiting with reason ImagePullBackOff) and the recent pod Events, including the detailed error message from the container runtime, such as "Failed to pull image" with the specific registry response (e.g., "not found" or "unauthorized"). This single command shows the image name, the node, and a timestamped history of pull attempts, making it the fastest path to diagnose why the image pull failed.
✗kubectl logs <pod-name>Wrong answer — click to see why▾
Why this is wrong here
The pod has not started, so there are no logs.
✗kubectl get events --field-selector involvedObject.kind=PodWrong answer — click to see why▾
Why this is wrong here
This would show events but not as detailed as describe pod; still acceptable but less direct.
✗kubectl exec <pod-name> -- cat /var/log/containersWrong answer — click to see why▾
Why this is wrong here
Pod is not running; exec fails.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
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.
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.
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.