CKA Troubleshooting Practice Question
You deploy a pod with resource limits but no requests. The pod gets OOMKilled. What is the most likely reason?
⚠ Common exam trap
Watch out — candidates often confuse OOMKilled with resource scheduling issues (Option D) or probe failures (Option A), but OOMKilled specifically indicates the container was terminated by the kernel for exceeding its memory limit, not for node-level insufficiency or health check failures.
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 tried to use more memory than the limit
When a pod has a memory limit set but no memory request, the Linux kernel enforces the limit via cgroups. If the container's processes attempt to allocate more memory than the limit, the kernel's Out-Of-Memory (OOM) killer terminates the container, resulting in an OOMKilled status. This is the most direct cause of the OOMKilled event.
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 failing
Why it's wrong here
A failing liveness probe causes kubelet to restart the container according to the pod's restartPolicy, resulting in a restart event with a probe failure reason, not an OOMKilled termination. The container's process is still within its cgroup memory limit; the kernel has not killed it for exceeding memory. Therefore the container's last state would indicate 'Error' or probe failure, never 'OOMKilled'.
- ✗
The container's entrypoint command is invalid
Why it's wrong here
An invalid entrypoint command makes the container crash immediately upon start, typically exiting with a non-zero exit code and triggering CrashLoopBackOff. This is a process-level failure unrelated to memory accounting or cgroups, so the container's termination reason would not be OOMKilled. The kernel never intervenes because the process never consumes enough memory to hit the limit.
- ✓
The container tried to use more memory than the limit
Why this is correct
When a container's memory usage exceeds its cgroup memory limit, the kernel's OOM killer terminates the container process, and kubelet records the reason as OOMKilled. Even with no explicit request, the limit is enforced as a hard cap, so the container is killed precisely for trying to allocate more memory than that cap. This is the only condition that sets the OOMKilled termination reason.
- ✗
The node does not have enough memory for the limit
Why it's wrong here
If the node lacks sufficient memory to schedule the pod, the pod remains in Pending state, not running, and the scheduler emits events like 'Insufficient memory' and never starts the container. OOMKilled is a post-scheduling, runtime condition that occurs when the container's own cgroup limit is exceeded, not when the node is under memory pressure. The container must be scheduled and running before it can be OOMKilled.
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.