mediumMultiple Choice
Google ACE Practice Question: Your GKE application's pods are being evicted…
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?
⚠ Common exam trap
Google Cloud often tests the misconception that increasing node resources or adding nodes (autoscaling) solves eviction, when the real issue is the lack of resource requests that determines eviction priority under memory pressure.
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
✓
Set memory requests and limits for all pods to match their actual memory usage.
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.
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 memory requests and limits for all pods to match their actual memory usage.
Why this is correct
Setting memory requests (and limits equal to requests) for every pod converts them from BestEffort or Burstable QoS to Guaranteed QoS, which places them last in the kubelet eviction order when memory pressure occurs. Requests also inform the scheduler, allowing it to place pods on nodes based on actual memory footprint, reducing the chance of overcommitting a node and triggering pressure in the first place. This directly fixes the root cause because it ensures every pod signals its memory needs and gets the appropriate eviction priority.
- ✗
Increase the node machine type to have more memory.
Why it's wrong here
Increasing the node machine type gives each node more memory capacity, which may delay or reduce memory pressure, but it does not change the QoS class of pods running without requests. BestEffort pods (no requests/limits) are still evicted first whenever pressure does occur, and they can cause resource contention that forces eviction of other pods. This is an expensive, temporary mitigation that masks the misconfiguration rather than fixing the pod resource declarations, and it wastes capacity because pods still do not declare their true memory usage.
- ✗
Configure pod disruption budgets (PDBs) to prevent eviction.
Why it's wrong here
Pod disruption budgets (PDBs) only constrain voluntary disruptions such as node drains, cluster autoscaler scale-down, or maintenance operations, not kubelet-driven evictions. When a node is under memory pressure, the kubelet evicts pods based on QoS class and memory usage, and it is not blocked by PDBs because this is an involuntary, node-level enforcement action. Therefore, a PDB cannot protect a BestEffort pod from being evicted to resolve an Out of Memory condition; it is a tool for availability during planned operations, not for resource pressure.
- ✗
Enable cluster autoscaler to add nodes before memory pressure occurs.
Why it's wrong here
Cluster autoscaler only reacts to pending (unschedulable) pods by adding nodes; it does not monitor node memory utilization or preemptively scale before pressure builds. Running pods that are experiencing memory pressure are already scheduled, so they never trigger the autoscaler, and kubelet will still evict them based on eviction thresholds. This approach fails to prevent the evictions because it addresses capacity planning at the cluster level rather than the pod-level resource guarantees that determine eviction priority.
Go deeper
Related to this question
Learn chapter
GCP Resource Hierarchy: Org, Folder, Project
Key term
GKE
GKE is Google's managed Kubernetes service that automates deploying, scaling, and managing containerized applications in the cloud.
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
About these practice questions
This ACE question is part of Courseiva's 775-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.