CKA Troubleshooting Practice Question
A pod is in CrashLoopBackOff. The YAML for the initContainer is:
apiVersion: v1 kind: Pod metadata: name: myapp spec: initContainers: - name: init image: busybox command: ['sh', '-c', 'sleep 5 && exit 1'] containers: - name: app image: nginx
What is the most likely reason for the CrashLoopBackOff?
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 init container exits with non-zero exit code
Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.
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 main container image nginx is not pulled successfully
Why it's wrong here
An image pull failure is reported as ImagePullBackOff or ErrImagePull, not CrashLoopBackOff. These statuses occur before the container runtime attempts to start the container because the kubelet cannot fetch the image from the repository. In contrast, CrashLoopBackOff indicates the container was successfully started and then exited with an error, so an inaccessible or missing image cannot be the cause here.
- ✗
The init container command is misspelled
Why it's wrong here
A misspelled command would cause the container to fail during the container runtime's exec phase, producing a specific error such as 'executable file not found' or 'container command not found' in the container status. This is not the same as a process that runs and then exits with a non-zero status, which is what triggers CrashLoopBackOff. The misspelling is merely one possible root cause of a non-zero exit, not the Kubernetes-level status itself, so it is not the definitive explanation.
- ✓
The init container exits with non-zero exit code
Why this is correct
The init container's role is to run to completion before the main container starts; if it fails, the pod cannot proceed. When an init container exits with a non-zero exit code, the kubelet restarts the pod according to the restartPolicy, causing the pod to enter CrashLoopBackOff after repeated failures. This is the standard mechanism for Init:CrashLoopBackOff, so a non-zero exit code is the correct explanation.
- ✗
The pod has insufficient memory
Why it's wrong here
Insufficient memory does not directly produce CrashLoopBackOff; the kernel OOM killer terminates the offending container with exit code 137 and the container status is reported as OOMKilled. While OOMKilled can eventually lead to a CrashLoopBackOff after several restarts, the immediate and distinguishing status is OOMKilled, not the generic CrashLoopBackOff. Thus, memory pressure is not the specific reason for CrashLoopBackOff in this scenario.
Go deeper
Related to this question
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.