KCNA Cloud Native Application Delivery Practice Question
A DevOps engineer notices that after a Helm upgrade, the new pods are crash looping with 'ImagePullBackOff'. What is the most likely cause?
⚠ Common exam trap
CNCF often tests the distinction between pre-start errors (ImagePullBackOff, ErrImagePull) and runtime errors (CrashLoopBackOff, probe failures), so candidates mistakenly associate any pod failure with liveness probes or resource constraints rather than image availability.
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
✓
The Helm chart has a wrong image tag
The 'ImagePullBackOff' error indicates that Kubernetes is unable to pull the container image from the registry. The most common cause during a Helm upgrade is a misconfigured or incorrect image tag in the Helm chart's values or templates, which causes the kubelet to fail when attempting to pull the specified image. This is distinct from runtime issues like probe failures or resource constraints, which would manifest as different error states.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The pod's liveness probe is misconfigured
Why it's wrong here
A misconfigured liveness probe causes repeated container restarts after the image starts, producing CrashLoopBackOff, not ImagePullBackOff. The kubelet reports ImagePullBackOff before any container runs, so probe configuration cannot be the cause; it would be correct when pods start then restart endlessly.
- ✓
The Helm chart has a wrong image tag
Why this is correct
ImagePullBackOff means the kubelet cannot pull the specified image, most commonly because the tag referenced in the chart does not exist in the registry. A Helm upgrade that changed the image tag would produce exactly this crash-looping symptom.
- ✗
The service account lacks permissions
Why it's wrong here
ImagePullBackOff means the kubelet cannot pull the container image, so the failure lies with registry credentials, image name or tag, or network access to the registry. Service account permissions govern API access to cluster resources, not image retrieval; that would be the cause of authorisation errors when a pod calls the Kubernetes API.
- ✗
The deployment's resource requests exceed node capacity
Why it's wrong here
ImagePullBackOff means the kubelet cannot pull the container image, so resource requests are irrelevant — pods would instead stay Pending if requests exceeded node capacity. Resource requests matter when scheduling pods onto nodes, making this tempting when pods fail to start after a change.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 KCNA 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 KCNA exam.