CKS Monitoring, Logging and Runtime Security Practice Question
An admin runs 'kubectl get pods' and sees a pod in 'CrashLoopBackOff' state. The pod's containers have a restart policy of 'Always'. What is the most likely cause?
⚠ Common exam trap
Candidates often confuse CrashLoopBackOff (container starts but fails) with ImagePullBackOff (container never starts due to image issues), leading them to mistakenly select image-related options like missing pull secrets.
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 container's command fails immediately after start
A CrashLoopBackOff state indicates that the container starts, fails, and is repeatedly restarted by kubelet due to the 'Always' restart policy. The most likely cause is that the container's command or entrypoint fails immediately after start (e.g., a non-zero exit code from a misconfigured binary or script), triggering the restart loop. Unlike resource or node-level issues, this is a container-level failure that produces the rapid restart pattern characteristic of CrashLoopBackOff.
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 image pull secret is missing
Why it's wrong here
A missing image pull secret prevents the kubelet from authenticating to a private container registry. Because the image cannot be downloaded, no container is ever started, and the pod reports ImagePullBackOff or ErrImagePull after repeated pull attempts. This is fundamentally different from CrashLoopBackOff, which requires a container to have started successfully and then exited with a failure.
- ✗
The pod's resource requests exceed node capacity
Why it's wrong here
When a pod's resource requests exceed the total allocatable capacity of any available node, the Kubernetes scheduler cannot place the pod. The pod remains in the Pending phase, and the kubelet never creates the container, so there is no process that can start and crash. A running container is a prerequisite for CrashLoopBackOff; scheduling failures produce unschedulable or pending pods instead.
- ✗
The node is out of memory
Why it's wrong here
A node-level out-of-memory condition causes the kernel OOM killer to terminate processes or the kubelet to evict pods, resulting in OOMKilled or Evicted statuses. The kubelet does not classify node memory pressure as a container restart failure, so it does not enter CrashLoopBackOff. While a container that repeatedly hits its own memory limit may be OOMKilled and restarted, Kubernetes reports that as OOMKilled rather than the generic 'back-off restarting failed container' state.
- ✓
The container's command fails immediately after start
Why this is correct
If the container's main command exits with a non-zero code immediately after startup, the kubelet sees a stopped container and, with the default restartPolicy of Always, schedules another attempt. Each restart fails again, and the kubelet applies exponential backoff, eventually reporting CrashLoopBackOff. This is the exact scenario the exam question refers to: a successfully launched container that fails at runtime, not a scheduling or image-pull problem.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 CKS 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 CKS exam.