CKAD Practice Question: Application Environment, Configuration and Security
A pod in the 'staging' namespace is in a CrashLoopBackOff state. You run 'kubectl logs pod -n staging' and see: 'Error: container has been OOMKilled'. The pod YAML has resources: requests: memory: 256Mi, limits: memory: 256Mi. Which change should you make first?
⚠ Common exam trap
CNCF often tests the distinction between requests and limits, and the trap here is that candidates might confuse reducing the request (option C) as a solution, when in fact the OOMKill is caused by hitting the limit, not the request.
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
✓
Increase the memory limit to 512Mi.
The pod is in CrashLoopBackOff due to OOMKill, meaning the container exceeded its memory limit and was terminated. Since the current memory limit is 256Mi and the container needs more, increasing the limit to 512Mi directly addresses the out-of-memory condition. This is the correct first step because it provides the container with the additional memory it requires to run without being killed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Increase the memory limit to 512Mi.
Why this is correct
Raising the memory limit from 256Mi to 512Mi directly addresses the container's memory usage ceiling. OOMKilled occurs when the container's memory footprint exceeds its cgroup memory limit, causing the kernel's OOM killer to terminate the process. Since the container is already crashing at the current 256Mi limit, increasing it to 512Mi provides the necessary headroom for the workload to operate without being killed.
- ✗
Increase the CPU limit to 1.
Why it's wrong here
Adjusting the CPU limit does nothing to mitigate an OOMKilled status because CPU limits are enforced via CPU throttling, not memory isolation. The OOM killer activates in response to memory cgroup pressure, not CPU exhaustion, so raising the CPU limit to 1 cores would leave the container still subject to the same memory limit and thus the same OOM kill.
- ✗
Reduce the memory request to 128Mi.
Why it's wrong here
Reducing the memory request from its current value to 128Mi only affects how Kubernetes schedules the pod onto nodes; it does not alter the memory limit that governs runtime enforcement. A container is killed when its actual memory usage reaches the limit (256Mi), regardless of how low the request is set. Thus, lowering the request leaves the effective limit unchanged and the container will continue to hit OOMKilled at exactly the same point.
- ✗
Set memory request to 512Mi and memory limit to 256Mi.
Why it's wrong here
This configuration is invalid because Kubernetes requires the memory request to be less than or equal to the memory limit; setting request=512Mi and limit=256Mi will produce a validation error and the pod will not be created. Even if it were accepted, the effective limit remains 256Mi, so the container would still be OOM-killed once its memory usage reaches that threshold—the request only influences scheduling, not the point at which the OOM killer intervenes.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 CKAD 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 CKAD exam.