Google ACE Deploying and Implementing a Cloud Solution 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.

• ✗

  Enable node auto-repair on the node pool

  Why it's wrong here

  Node auto-repair is a GKE feature that detects unhealthy nodes (via health checks) and automatically recreates them, but it operates only within the existing node pool's zonal scope. If an entire zone loses power or network connectivity, auto-repair cannot provision replacement nodes in a healthy zone because the node pool's resources are confined to the affected zone. It addresses node-level failures (e.g., a hung kubelet), not zone-level availability, so it does not satisfy the requirement to keep the application running through a zone outage.

• ✗

  Create a zonal cluster in a single zone

  Why it's wrong here

  Creating a zonal cluster places both the control plane and all worker nodes in a single compute zone. That means the Kubernetes API server, scheduler, and every application pod share one failure domain; if the zone becomes unavailable, the cluster cannot serve requests and the deployment becomes unreachable. Multiple replicas within the same zonal cluster are still colocated on that zone's infrastructure, so they provide only pod-level redundancy, not protection against zone-level disasters. Production workloads with resilience requirements should use a regional cluster to spread the control plane and nodes across multiple zones.

• ✗

  Set the deployment replicas to 1

  Why it's wrong here

  Setting replicas to 1 gives you a single pod instance, which provides no headroom for rolling updates or node evictions: if that pod's node fails, the Deployment controller must reschedule it, causing downtime while a replacement pod is pulled and started. It also does not react to workload demand; CPU-based load will quickly saturate a single replica, and without an HPA the Deployment will not add capacity. The scaling requirement is addressed by Horizontal Pod Autoscaler, but the replica count baseline should be at least 2 for meaningful availability, not 1.

• ✓

  Enable horizontal pod autoscaling on the deployment with CPU target utilization

  Why this is correct

  Horizontal Pod Autoscaler (HPA) continuously observes the average CPU utilization of the pods in a Deployment (via metrics-server) and automatically adjusts the `replicas` field to keep utilization near the configured target, e.g., 70%. This directly fulfills the stated need to scale the application based on load — when CPU usage rises, HPA adds pods; when it drops, HPA removes excess pods. Note that HPA is about pod-level elasticity and does not by itself provide zone resilience; to meet the production requirement fully, you would combine HPA with a regional multi-zone cluster so that scaled-out pods can be scheduled across failure domains.

• ✓

  Create a regional cluster with nodes in multiple zones

  Why this is correct

  A regional GKE cluster runs a replicated control plane (normally three copies) across distinct zones in the region, and its node pool can be configured with nodes in two or more zones. If one zone fails, the control plane remains available in the other zones, and the workloads running on nodes in the healthy zones continue to operate. This architecture provides genuine zone-failure resilience, protecting against an entire availability zone going down, which is essential for production workloads. Unlike HPA, this is a capacity-distribution decision made at the cluster or node-pool level, not an automatic scaling policy.

Go deeper

Related to this question