CKS System Hardening Practice Question
A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?
⚠ Common exam trap
Many candidates mistakenly think that restarting the pod (Option C) will fix transient issues, but here the OOMKilled state is a persistent resource constraint, not a transient 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
✓
Increase the memory limit in the pod's container resource specification
The pod is in CrashLoopBackOff due to OOMKilled, meaning the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeds its memory limit. Increasing the memory limit in the container's resource specification allows the container to allocate more memory without being killed, directly addressing the root cause.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the namespace and redeploy all workloads
Why it's wrong here
Deleting the namespace destroys every workload and its data to fix one container's memory limit, which no OOMKilled event justifies. Namespace deletion is for decommissioning or hard resets, not remediation. Raising the container's memory limit or request addresses the actual cgroup eviction that triggered the kill.
- ✓
Increase the memory limit in the pod's container resource specification
Why this is correct
Raising the container's memory limit directly addresses the OOMKilled termination, which occurs when the container exceeds its configured memory limit and the kernel kills the process. Since the pod ran successfully for days before failing, the workload's memory demand has grown beyond the current ceiling, so increasing the limit satisfies that constraint.
- ✗
Delete and recreate the pod to clear the crash loop
Why it's wrong here
Deleting and recreating the pod without changing the resource limits will result in the same OOMKilled event.
- ✗
Increase the CPU request for the container
Why it's wrong here
OOMKilled is a memory cgroup eviction, so raising the CPU request changes nothing about the kernel's memory accounting. CPU requests govern scheduling share and throttling, relevant when a pod is CPU-starved or unschedulable. The failing axis here is memory, so the memory limit or request must be adjusted instead.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 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.