Google PCA Ensure solution and operations reliability 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.

• ✗

  CPU requests are too low, causing throttling and eventual crash.

  Why it's wrong here

  Insufficient CPU requests cause throttling and latency, not OOMKills, which the kernel triggers on memory limit breach. It tempts because resource starvation looks similar, but low CPU requests would be the correct diagnosis for performance degradation rather than container termination.

• ✗

  The node pool is too small, causing memory pressure on the node.

  Why it's wrong here

  Node memory pressure evicts pods by priority and QoS class, producing Evicted status, not OOMKilled, which the kernel raises when a container exceeds its own cgroup limit. It tempts because undersized nodes cause memory problems, and would be correct for diagnosing eviction or scheduling failures.

• ✗

  Memory limits are set higher than the node's allocatable memory.

  Why it's wrong here

  A limit exceeding node allocatable memory prevents scheduling rather than causing OOMKills; the kubelet rejects pods whose limits exceed capacity. It tempts because oversized limits look dangerous, but it is correct reasoning only when diagnosing Pending pods, not runtime memory exhaustion.

• ✓

  The application has a memory leak that eventually exceeds the limit.

  Why this is correct

  Requests and limits only cap consumption; they cannot prevent a leak from growing until the container exceeds its limit and is OOMKilled. Since configuration is already correct, the remaining cause is application-level: unbounded allocation that eventually surpasses the configured memory limit.

Go deeper

Related to this question