CKA Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  spec.template.spec.containers[].resources.limits.memory

  Why this is correct

  The container's memory limit is implemented as a cgroup v2 (or v1) limit on the memory cgroup to which that container belongs. When the container's resident set size plus page cache exceeds this limit, the kernel's out-of-memory (OOM) killer selects a process in that cgroup — usually the container's main PID — and kills it, resulting in OOMKilled. Increasing spec.template.spec.containers[].resources.limits.memory raises this cgroup ceiling, giving the container more usable memory headroom before the kernel decides to kill its process, which is exactly why this field addresses the reported OOMKilled status.

• ✗

  spec.template.spec.containers[].resources.requests.memory

  Why it's wrong here

  A memory request is a scheduling hint: it tells the scheduler how much memory a container must be guaranteed on a node, and it contributes to Kubernetes' QoS classification. Requests do not set any kernel-level memory ceiling, so a container can consume far more than its request without being killed by the cgroup OOM killer. The kernel enforces the memory limit (limits.memory), not the request; therefore, increasing requests.memory alone neither raises the actual memory allotment nor prevents OOMKilled—it only affects where the Pod may be scheduled and how node resource reservations are accounted for.

• ✗

  spec.template.spec.containers[].resources.requests.cpu

  Why it's wrong here

  CPU requests are entirely orthogonal to memory management: they are used for scheduler placement (so the node can admit the Pod) and for CPU share weighting in the Completely Fair Scheduler (CFS). Changing requests.cpu has no effect on the memory cgroup limit or the kernel's memory accounting, and it cannot influence whether the OOM killer targets this container. OOMKilled is a memory-resource event, not a CPU-resource event, so a CPU request adjustment cannot alter the container's memory capacity or its OOM status.

• ✗

  spec.template.spec.containers[].resources.limits.cpu

  Why it's wrong here

  A CPU limit, typically expressed in millicores and enforced via CFS quota, caps how much CPU time the container can use, but it imposes no constraint on memory usage. When a container exceeds its memory limit, the kernel invokes the OOM killer irrespective of how much CPU quota remains; CPU throttling merely slows execution and does not prevent memory exhaustion. Because the OOM killer acts on memory cgroup violations, raising limits.cpu does not create additional memory capacity and thus cannot stop an OOMKilled event caused by memory pressure.

Go deeper

Related to this question