Google ACE Practice Question: A production GKE cluster is running low on node…

Answer analysis

Option-by-option breakdown

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

• ✓

  Resize the node pool to add more nodes: `gcloud container clusters resize`

  Why this is correct

  Resizing the node pool with `gcloud container clusters resize CLUSTER --node-pool=POOL --num-nodes=N` immediately adds worker nodes, increasing the cluster's total allocatable CPU and memory so that Pending Pods can be scheduled. On GKE, if cluster autoscaler is enabled, it already performs this action automatically; manually resizing is the deterministic fallback. Resizing is non-disruptive and does not terminate existing Pods, making it the ideal solution.

• ✗

  Delete existing Pods to free resources for the Pending Pods

  Why it's wrong here

  Deleting existing Pods would evict running workloads, causing downtime and potentially losing state, and does not add new capacity to the cluster. Even if you delete a Pod, the Deployment or StatefulSet controller will recreate it immediately, so the freed resources vanish and the new Pending Pod may still have nowhere to go. The question specifically forbids deleting Pods, and this approach fails to address the root cause of insufficient node resources.

• ✗

  Change the Pending Pods' resource requests to zero

  Why it's wrong here

  Setting resource requests to zero changes a Pod's QoS class to BestEffort, which makes the scheduler ignore its actual usage and allows it to be placed anywhere, but this is a dangerous anti-pattern that leads to resource contention and unpredictable eviction behavior. It also does not create any new capacity; it only masks the problem by allowing the scheduler to overcommit nodes. Additionally, modifying the Deployment triggers a rolling update, and the cluster may still refuse to schedule if the node has no available memory even for the Pod's runtime overhead.

• ✗

  Upgrade the Kubernetes control plane version

  Why it's wrong here

  Upgrading the Kubernetes control plane only changes the version of the API server, scheduler, and controller managers; it does not add CPU, memory, or nodes to the cluster. Therefore, Pods that are Pending because of insufficient node capacity will remain unschedulable. Indeed, a control-plane upgrade can briefly disrupt the API server and does not address the underlying resource shortfall.

Go deeper

Related to this question