CKA Troubleshooting Practice Question
A pod is in 'ImagePullBackOff' state. Which TWO are valid first troubleshooting steps?
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
✓
Verify the image exists in the configured registry
Option C is correct because ImagePullBackOff commonly results from the referenced image not existing in the registry (wrong tag, deleted image, or private repo requiring credentials), so verifying the image exists in the configured registry is a valid first step. Option D is correct because a simple typo in the image name or tag in the pod spec will cause the kubelet to fail pulling the image, and checking the spelling is a fast, direct troubleshooting action. Option A is not a typical first step since network policies rarely block egress to registries by default and the error would more likely be a timeout or connection refused rather than ImagePullBackOff. Option B is unrelated because insufficient node CPU/memory produces Pending or Evicted states, not image pull failures. Option E is not a first step because restarting the kubelet is disruptive and does not address the root cause of an image pull error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check for network policies blocking egress to the registry
Why it's wrong here
An egress NetworkPolicy does not govern the kubelet's image pull because NetworkPolicy selects pod-to-pod or pod-to-external traffic, while the kubelet pulls from the node's network stack, outside the pod network namespace. If a node-level firewall or registry authentication were at fault, the events would show connection timeouts or unauthorized errors, not the image-not-found messages that typically accompany ImagePullBackOff. Therefore checking NetworkPolicy is secondary and not one of the two direct causes to verify first.
- ✗
Check node CPU/memory resources
Why it's wrong here
Node CPU/memory pressure prevents the scheduler from placing the pod, leaving it in Pending, or causes eviction of running pods, not ImagePullBackOff. Once the pod is successfully scheduled, the kubelet begins pulling images regardless of the node's allocatable resources; resource limits affect running containers, not the pull phase. Since ImagePullBackOff reflects repeated pull failures from the registry, checking compute resources is a red herring.
- ✓
Verify the image exists in the configured registry
Why this is correct
ImagePullBackOff almost always follows a kubelet event that includes the exact registry response, such as 'manifest unknown', 'not found', or 'unauthorized'. Verifying the image exists in the configured registry, with the exact tag or digest specified in the pod spec, is the most direct confirmation of the root cause. Use `docker manifest inspect` or `skopeo inspect` against that registry, and remember that images can be deleted or made private after a pod was previously running. This check targets the registry artifact itself.
- ✓
Check the image name spelling in the pod spec
Why this is correct
A simple typo in the image name or tag in the pod spec—such as `nginx:1.29` instead of `nginx:1.29.0` or a mis-spelled repository name—causes the registry to return an image-not-found error. The kubelet then retries with exponential backoff, leaving the pod in ImagePullBackOff. Inspecting the `image:` field in `kubectl get pod -o yaml` and comparing it character-by-character with the registry's valid tags is quick, essential, and distinct from checking whether a valid image exists externally.
- ✗
Restart the kubelet on the node
Why it's wrong here
Restarting the kubelet does not change the image reference, the registry credentials, or the remote repository, so the exact same pull error occurs again after the daemon returns. The ImagePullBackOff state is a deliberate backoff timer during which the kubelet keeps allowing future pull attempts; restarting the node agent simply resets that timer and gives a false sense of progress. Moreover, restarting the kubelet on a busy node disrupts all pod lifecycle operations and should never be used as a fix for an image pulling issue.
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
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
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.