GCP-ACE - Ensuring the successful operation of a cloud solution (30% of the exam) - Section 3.1
Manage compute resources, including connecting to Compute Engine instances, working with snapshots and images, managing GKE node pools and Kubernetes resources, configuring horizontal and vertical Pod autoscaling, and deploying new versions and traffic splits for Cloud Run applications.
Operate running compute: connect to Compute Engine instances, create and schedule snapshots and images, and manage GKE node pools, Pods, Services, and StatefulSets. Configure horizontal and vertical Pod autoscaling and GKE Autopilot resource requests, deploy new Cloud Run revisions, and split traffic between revisions to run gradual rollouts.
Compute Engine snapshotsGKE node poolsHorizontal Pod autoscalingCloud Run revisionsTraffic splitting
Practice question for this objective
lock_openFree sampleEnsuring the successful operation of a cloud solutionmedium
A Deployment serves a web API whose traffic rises and falls through the day, and the team wants more identical replicas during peaks and fewer during quiet periods. Which autoscaler matches this goal, and what does it change?
AThe Vertical Pod Autoscaler, because it adds and removes Pod replicas according to the memory requests that have been recorded for the workload over time.
BThe Horizontal Pod Autoscaler, because it changes the number of Pod replicas in the Deployment in response to observed metrics such as average CPU utilisation.check_circle Correct
CThe cluster autoscaler, because it edits the replicas field of the Deployment directly whenever the CPU on the underlying nodes crosses a set threshold.
DThe Vertical Pod Autoscaler, because it raises the CPU and memory requests of each running Pod so that a single replica alone can absorb the daily peak.
Distinguish horizontal Pod autoscaling, which changes replica count, from vertical Pod autoscaling, which changes per-Pod resource requests. The Horizontal Pod Autoscaler scales a workload by increasing or decreasing the number of Pod replicas to match a target metric, whereas vertical autoscaling changes the resources given to each Pod rather than how many Pods run.
Why A is wrong: This is tempting because the VPA also reacts to usage, but it does not change replica count; it adjusts the CPU and memory requests of Pods instead.
Why B is correct: The HPA adjusts the replica count of a workload up or down to track a target metric, which is exactly the behaviour of adding replicas at peak and removing them when traffic falls.
Why C is wrong: The cluster autoscaler resizes node pools rather than editing a Deployment, so it never sets the replica count and does not perform the scaling the team wants.
Why D is wrong: This correctly describes VPA behaviour but not the requirement; the team asked for more identical replicas, which is horizontal scaling, not larger single Pods.
Exam traps in Ensuring the successful operation of a cloud solution
Answers that look right on this material and are not. Each one is a distractor from a different question in the GCP-ACE bank for this domain.
You export each revision as a separate service and place an external load balancer in front, because a single Cloud Run service can serve only one revision at a time.
errorWhy it is wrong: A Cloud Run service can split traffic across its own revisions natively, so an extra service and load balancer are unnecessary and the premise that only one revision can serve is wrong.
A snapshot and a custom image are interchangeable, so either one can be set as the boot source of an instance template with no difference in how instances are created.
errorWhy it is wrong: This is tempting because both derive from a disk, but instance templates and the create-instance flow expect an image as the boot source, so the two are not simply interchangeable.
Add --async so the deployment returns immediately and the new revision is held out of the serving path until the operation finishes in the background.
errorWhy it is wrong: Tempting because it sounds like a safe staged rollout, but --async only controls whether the CLI waits for the operation; the revision still becomes the latest and takes all traffic by default.