Google ACE Practice Question: A production GKE service processes payments and…

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 the Deployment replica count to 6 — node upgrades will only affect half at a time

  Why it's wrong here

  Simply increasing the Deployment replica count to 6 does not create any availability guarantee for voluntary disruptions. Without a PodDisruptionBudget, GKE's node drain during upgrades can evict Pods on multiple nodes in parallel, potentially taking down all 6 replicas if those nodes are processed together. The Deployment controller can reschedule evicted Pods, but there is no mechanism forcing the drain to pause until a minimum number of Pods are running, so the payment service could still drop below 3 available replicas. Additionally, if the cluster does not have at least 6 schedulable nodes, some replicas remain unschedulable, giving a false sense of resilience.

• ✓

  Create a PodDisruptionBudget with minAvailable: 3 targeting the payment service Pods

  Why this is correct

  A PodDisruptionBudget with minAvailable: 3 is the correct mechanism because it constrains voluntary evictions, such as those triggered by GKE node upgrades or cluster autoscaler scale-down. When the eviction API is called to drain a node, the PDB controller checks that evicting the Pod would not reduce the total available replicas below 3; if it would, the drain is blocked or delayed. Because the payment service runs exactly 3 replicas, minAvailable: 3 means no Pod can be voluntarily evicted at a time, keeping the service fully available throughout the disruption. The PDB must use a selector that matches the Deployment's Pod labels to enforce this guarantee correctly.

• ✗

  Add node affinity rules pinning all 3 replicas to specific long-lived nodes

  Why it's wrong here

  Adding node affinity rules that pin all 3 replicas to specific long-lived nodes actually harms availability rather than protecting it. If those nodes require an upgrade, experience a kernel panic, or are otherwise taken out of service, the hard affinity constraint prevents the Pods from being scheduled onto other nodes, causing the Deployment to remain stuck with fewer than 3 replicas. Node affinity does not affect the order or pacing of GKE's node drain process, so it cannot guarantee that Pods are evicted one at a time. This approach also concentrates the deployment on a small failure domain, increasing the risk of simultaneous downtime if the pinned nodes fail together.

• ✗

  Enable cluster autoscaler with minNodeCount=3 — this preserves Pod availability

  Why it's wrong here

  Enabling the cluster autoscaler with minNodeCount=3 does not preserve Pod availability because the minimum node count only controls the size of the node pool, not how many Pods are evicted during a disruption. During a node upgrade, GKE can drain nodes and evict the payment service Pods from multiple nodes at once without consulting any per-workload PDB, potentially taking down all replicas even though 3 nodes still exist. The cluster autoscaler's scale-down logic does respect PodDisruptionBudgets when removing nodes, but minNodeCount alone is not a substitute for a PDB—it simply prevents the cluster from shrinking below 3 nodes. This option addresses node pool capacity, not the payment service's availability during evictions.

Go deeper

Related to this question