KCNA Kubernetes Fundamentals Practice Question
A developer deploys a pod that continuously restarts. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?
⚠ Common exam trap
The KCNA exam often tests the distinction between exit codes and probe failures; the trap here is that candidates confuse exit code 137 with a liveness probe failure, but exit code 137 specifically points to a SIGKILL, not a probe timeout or command failure.
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 is exceeding its memory limit and being OOM-killed.
Exit code 137 (128 + 9) indicates the container was killed by SIGKILL. In Kubernetes, this most commonly occurs when the container exceeds its memory limit, triggering the OOM (Out-Of-Memory) killer. The kubelet enforces the resource limits specified in the pod spec, and when memory usage surpasses the limit, the kernel terminates the process with SIGKILL, resulting in exit code 137.
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 container is exceeding its memory limit and being OOM-killed.
Why this is correct
Exit code 137 equals 128 plus signal 9 (SIGKILL), which the kernel sends when a container exceeds its memory limit. The kubelet then reports the OOMKilled reason. Persistent restarts with this code therefore indicate the pod's memory limit is too low for its workload, not an application crash.
- ✗
The liveness probe is failing and restarting the container.
Why it's wrong here
A failing liveness probe triggers a restart, but the container is terminated gracefully with SIGTERM, producing exit code 143, not 137. It is tempting because probe failures are a common restart cause, yet 137 specifically indicates SIGKILL, which the kubelet sends when a container exceeds its memory limit.
- ✗
The init container is failing and blocking the main container.
Why it's wrong here
A failing init container leaves the pod stuck in Init state with the main container never starting, so no exit 137 from the main container appears. It is tempting because init failures do cause restart loops, but exit 137 specifically signals SIGKILL from exceeding the container's memory limit.
- ✗
The pod is hitting a resource quota limit at the namespace level.
Why it's wrong here
A namespace ResourceQuota blocks pod admission or rejects new pods; it does not terminate a running container with SIGKILL, so exit 137 would not arise this way. It is tempting because quotas do prevent scheduling, but the correct cause is the container's own memory limit being exceeded, which the kernel kills.
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.