Google PCA Manage and provision cloud infrastructure Practice Question
A company runs a critical application on Compute Engine instances in a managed instance group (MIG) across three zones in us-central1. The application uses a Cloud Spanner database. Recently, the application experienced increased latency and timeouts during peak hours. The operations team noticed that the MIG's CPU utilization is consistently above 80% during peak hours, and the autoscaler is configured to scale based on CPU utilization with a target of 60%. However, the autoscaler is not adding new instances quickly enough, causing performance degradation. The team also observed that new instances take over 5 minutes to become healthy and serve traffic. The health check is a simple TCP check on port 8080. The application startup script downloads large configuration files from Cloud Storage. What should the team do to improve the autoscaling response time and reduce latency?
⚠ Common exam trap
The trap here is that candidates focus on tuning the autoscaler parameters (CPU target, health check intervals) rather than identifying the actual bottleneck—the instance startup time—which is a common misconception that autoscaling speed is purely a function of scaling policy settings.
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
✓
Create a custom Compute Engine image that includes the application and configuration, and use it in the MIG.
The primary bottleneck is the long instance startup time (over 5 minutes) caused by downloading large configuration files from Cloud Storage at boot. By creating a custom Compute Engine image that bakes the application and configuration into the image, new instances can start serving traffic almost immediately, drastically reducing the time before they become healthy and the autoscaler can consider them in scaling decisions. This directly addresses the root cause of slow autoscaling response, as the autoscaler cannot add instances faster than they become healthy.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the minimum number of instances in the MIG to handle peak load.
Why it's wrong here
Raising the minimum instance count provisions capacity ahead of demand but leaves the five-minute startup bottleneck untouched, so new instances still cannot serve traffic quickly during peaks. It is tempting because it guarantees baseline headroom, and would be correct if the workload were steady and predictable rather than spiky.
- ✗
Reduce the autoscaler target CPU utilization to 40% so it scales earlier.
Why it's wrong here
Lowering the target to 40% triggers scaling sooner, yet each new instance still takes over five minutes to become healthy, so added capacity arrives too late. It is tempting because it is a one-line autoscaler change, and would be correct if instance startup were already fast and the delay were purely detection lag.
- ✓
Create a custom Compute Engine image that includes the application and configuration, and use it in the MIG.
Why this is correct
Baking the application and configuration into a custom image removes the startup script's download of large files from Cloud Storage, cutting the over-five-minute initialisation delay. Instances therefore become healthy faster, letting the autoscaler add capacity quickly enough to hold CPU near the 60% target.
- ✗
Change the health check to HTTP and reduce the initial delay and check intervals.
Why it's wrong here
Switching to HTTP and shortening delays speeds health-check detection, but the five-minute delay comes from downloading large configuration files at startup, which health-check tuning cannot shorten. It is tempting because health checks control when instances join the pool, and would be correct if slow detection, not slow bootstrapping, were the bottleneck.
Go deeper
Related to this question
Learn chapter
Resource Monitoring and Logging with Cloud Operations
Key term
Latency
Latency is the time delay between a request being sent over a network and the response being received, often measured in milliseconds.
Key term
CAN
A CAN (Controller Area Network) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other without a host computer.
About these practice questions
One of 807 original PCA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCA 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 PCA exam.