Long-Term Fix for Pod Eviction on GKE

A monitoring alert fires at 3 AM — the team's GKE Pods are being evicted. Investigation shows node memory is at 98%. Pods without resource requests are being evicted first. What is the long-term fix to prevent evictions?

Quick Answer

The answer is to add explicit memory requests and optionally limits to all Pod specs. This is the correct long-term fix for GKE pod eviction under memory pressure because without resource requests, Pods are classified as BestEffort or Burstable under Kubernetes’ Quality of Service (QoS) classes, making them the first to be evicted by the kubelet when node memory hits 98%. By defining memory requests, you give the scheduler the data it needs to place Pods only on nodes with sufficient available memory, preventing overcommitment at the scheduling level rather than just reacting to evictions. On the Google Associate Cloud Engineer exam, this scenario tests your understanding of Kubernetes resource management and QoS tiers—a common trap is choosing a short-term fix like increasing node size or adding more replicas, which doesn’t address the root cause of missing requests. Memory tip: “No request means no rest”—Pods without requests are always first to be evicted under pressure.

⚠ Common exam trap

Google Cloud often tests the misconception that raising limits or adding capacity is the fix, but the real issue is the absence of requests, which prevents the scheduler from making informed placement decisions and leaves Pods in the lowest QoS class.

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

✓

Add explicit memory requests (and optionally limits) to all Pod specs

B is correct because setting explicit memory requests ensures the Kubernetes scheduler can accurately place Pods on nodes with sufficient resources, preventing the node from being overcommitted. Without requests, Pods are treated as burstable or best-effort, making them the first candidates for eviction under the kubelet's Quality of Service (QoS) classes when node memory pressure hits 98%. This is a long-term fix because it enforces proper resource governance at the scheduling level, not just a reactive measure.

Answer analysis

Option-by-option breakdown

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

✗
Set higher memory limits on the Pods being evicted
Why it's wrong here
Higher memory limits allow Pods to use more memory, which may increase node memory pressure — not a fix for eviction caused by missing requests.
✓
Add explicit memory requests (and optionally limits) to all Pod specs
Why this is correct
Pods without requests have BestEffort QoS and are evicted first. Setting memory requests elevates Pods to Burstable QoS. Matching requests and limits creates Guaranteed QoS — the most eviction-resistant class.
✗
Disable node-level eviction by modifying kubelet configuration
Why it's wrong here
Disabling eviction lets nodes run out of memory and crash — eviction is a safety mechanism. The fix is sizing Pods correctly.
✗
Add more nodes to the cluster to increase available memory
Why it's wrong here
Adding nodes helps capacity, but doesn't fix the root cause — Pods without requests can continue to consume unbounded memory, causing the same issue on the new nodes.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on ACE

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Your GKE application's pods are being evicted frequently during periods of high traffic. You notice that pods without resource requests are being evicted first. The nodes are running at ~85% memory utilization. What should you do to reduce pod eviction?

medium

✓ A.Set memory requests and limits for all pods to match their actual memory usage.
B.Increase the node machine type to have more memory.
C.Configure pod disruption budgets (PDBs) to prevent eviction.
D.Enable cluster autoscaler to add nodes before memory pressure occurs.

Why A: Setting memory requests and limits for all pods to match their actual memory usage ensures that the Kubernetes scheduler can accurately allocate resources and make informed scheduling decisions. Without requests, pods are treated as BestEffort QoS class, making them the first candidates for eviction under memory pressure (when nodes exceed ~85% utilization). By defining requests, pods are classified as Burstable or Guaranteed, which gives them higher priority during eviction and prevents unnecessary disruptions.

Last reviewed: Jun 30, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

This ACE practice question is part of Courseiva's free Google Cloud 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 ACE exam.