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.

• ✗

  The memory limit is lower than the memory request

  Why it's wrong here

  Kubernetes resource definitions allow a container's memory limit to be equal to or greater than its memory request. In the scenario implied by the problem context, a memory limit of 128Mi is indeed higher than a request of 64Mi, which is a perfectly valid configuration. This setup does not inherently cause an Out-Of-Memory (OOM) kill; rather, an OOM event would only occur if the container's actual memory usage surpassed the configured 128Mi limit, not due to the request/limit relationship itself.

• ✗

  The node has swap enabled

  Why it's wrong here

  Kubernetes nodes are typically configured with swap disabled to ensure predictable memory accounting and consistent Quality of Service (QoS) guarantees, as swap can obscure actual memory pressure. Even if swap were enabled on the node, the container's memory limit, enforced by cgroups, would still be respected by the kernel's Out-Of-Memory (OOM) killer. The OOM killer would terminate the process once its Resident Set Size (RSS) exceeded the configured limit, irrespective of available swap space, making swap enablement not the direct cause of an OOM kill due to exceeding a limit.

• ✓

  The container's memory usage exceeds the configured limit

  Why this is correct

  When a container's memory consumption, specifically its Resident Set Size (RSS), exceeds the `memory.limit_in_bytes` enforced by its cgroup, the Linux kernel's Out-Of-Memory (OOM) killer is invoked. This mechanism is designed to protect the host system from memory exhaustion by terminating processes that have surpassed their allocated memory resources. In this specific scenario, the container was terminated precisely because its application attempted to allocate or utilize memory beyond the 128Mi limit, triggering the OOM killer to reclaim system resources.

• ✗

  The container is using too much CPU

  Why it's wrong here

  CPU limits in Kubernetes, configured via cgroups, primarily lead to CPU throttling, not process termination. When a container attempts to use more CPU cycles than its allocated limit, the kernel restricts its access to CPU time, causing the application to run slower or experience latency. An Out-Of-Memory (OOM) event, however, is exclusively related to memory resource exhaustion, where the kernel terminates a process to free up physical memory. Therefore, excessive CPU usage would not directly result in an OOM kill.