CKAD Application Design and Build 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 node has insufficient CPU

  Why it's wrong here

  A pending pod indicates the scheduler cannot place it on any node. If the limiting factor were CPU, `kubectl describe pod` would report an event such as `Insufficient cpu`, not the memory-related message observed here. CPU is also compressible in practice: nodes can oversubscribe CPU and handle contention through throttling, whereas memory cannot be reclaimed after allocation. Therefore, an insufficient CPU condition is not the cause of this pending state.

• ✗

  The container was killed due to out-of-memory

  Why it's wrong here

  OOMKilled is a container runtime state that can only occur after a container has been successfully started and scheduled onto a node, then exceeded its memory limit while running. A pod stuck in `Pending` has not yet reached the point where its containers are created and executed; it is still awaiting a node placement. The event for this situation would be a scheduling failure, not a container kill. Confusing a post-start OOM kill with a pre-scheduling pending state conflates two completely separate life-cycle phases.

• ✓

  The pod's memory request exceeds available node memory

  Why this is correct

  When a pod requests more memory than is allocatable on any node in the cluster, the Kubernetes scheduler cannot find a suitable placement and leaves the pod in `Pending` with an event such as `0/3 nodes are available: insufficient memory`. Memory is a non-compressible resource, so the scheduler treats a memory request as a hard guarantee and refuses to place the pod where satisfying it would overcommit available allocatable memory. Since no candidate node can accommodate the specified memory request, the pod remains unscheduled until capacity is freed or the request is reduced.

• ✗

  The container image does not exist

  Why it's wrong here

  A missing container image is an image-registry problem discovered only after the pod is scheduled onto a node, when the container runtime attempts to pull the image. In that case the pod would move from `Pending` to `ContainerCreating` and eventually report `ImagePullBackOff` or `ErrImagePull` in its status and events. A pod that remains `Pending` with no node assignment has not even reached the image-pull stage. Therefore, the reported pending state cannot be explained by a nonexistent image.