Cloud Digital Leader Scaling with Google Cloud operations Practice Question
A large online retailer operates a microservices-based e-commerce platform on Google Kubernetes Engine (GKE) across multiple zones. The application consists of several stateless services that handle customer traffic, inventory, and order processing. Recently, the company migrated its relational database to Cloud Spanner to achieve global scalability and strong consistency. After the migration, during peak shopping periods (e.g., Black Friday), the application experiences significant performance degradation. The operations team monitors CPU utilization of the pods and finds it consistently below 60% even under heavy load. However, Cloud Spanner metrics show high query latency and increased number of transactions waiting for lock conflicts. The team suspects that the bottleneck is now the database, not the compute. The application is designed to scale horizontally by adding more pod replicas. The team wants to ensure that scaling decisions are based on the actual performance bottleneck. What should they do?
⚠ Common exam trap
Google Cloud often tests the misconception that CPU utilization is always the correct metric for scaling, but in this scenario, the bottleneck is the database, so candidates must recognize that custom metrics (like Spanner latency) are needed to scale the application appropriately.
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
✓
Modify the Horizontal Pod Autoscaler (HPA) to scale based on a custom metric that reflects Cloud Spanner query latency.
The Horizontal Pod Autoscaler (HPA) can be configured to scale based on custom metrics, such as Cloud Spanner query latency. Since the bottleneck is the database, scaling pods based on CPU utilization (which remains low) would not resolve the issue; instead, scaling based on Spanner latency ensures that the application adds replicas only when the database can handle more connections, reducing lock contention and improving overall performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Scale the GKE cluster to use larger node instances.
Why it's wrong here
Resizing the GKE node pool to larger instances increases the CPU and memory capacity of individual nodes, which can alleviate local resource pressure in pods, but it does not address the true bottleneck: Cloud Spanner's query latency. Spanner contention typically stems from partition hotspots or transaction conflicts on the database side, not from client compute resources. In fact, larger nodes would allow more concurrent pods, potentially increasing the load on Spanner and worsening latency. This approach only treats a symptom (under-provisioned compute) while ignoring the database-side root cause.
- ✗
Increase the CPU request limit for the pods to allow higher CPU usage.
Why it's wrong here
Raising the CPU request limit for the pods allocates more compute to each container, preventing CPU throttling at the pod level. However, CPU is already sufficient; the latency is incurred while waiting for Cloud Spanner's response over the network. Increasing CPU limits cannot reduce Spanner's internal processing time or network round-trip, nor does it reduce the contention causing high query latency. It would only waste resources and could increase cloud costs without any improvement in the observed response time.
- ✗
Reduce the number of pods to decrease Spanner load.
Why it's wrong here
Reducing the number of pods does reduce the total number of concurrent clients, but the overall workload from end users (the retailer's traffic) remains unchanged. Each pod would then receive a higher proportion of the traffic, causing higher CPU/memory usage and potentially exhausting the pod's connection pool or thread pool, which typically increases latency. Since the same volume of queries is still sent to Cloud Spanner, the database-side load is not meaningfully reduced; the per-pod contention with Spanner actually intensifies, worsening the end-to-end latency.
- ✓
Modify the Horizontal Pod Autoscaler (HPA) to scale based on a custom metric that reflects Cloud Spanner query latency.
Why this is correct
Configuring the Horizontal Pod Autoscaler to use a custom metric based on Cloud Spanner query latency ensures that the number of pods scales in direct response to the real bottleneck. You can expose a metric such as the 99th percentile query latency from Spanner via Google Cloud Monitoring, and the HPA can use this via the Kubernetes Metrics API. When Spanner latency increases, the autoscaler adds more pods to distribute outstanding queries, reducing per-pod concurrency and preventing timeouts. This is preferable to CPU-based autoscaling because it captures database-side health and aligns scaling decisions with the actual user-facing performance.
Visual reference
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Autoscaler
An Autoscaler is a cloud service that automatically increases or decreases the number of virtual machines (instances) or resources based on real-time demand, so your application always has enough capacity without wasting money on idle servers.
Key term
SQL
SQL is a standardized programming language used to manage and manipulate relational databases, enabling querying, updating, and data retrieval.
About these practice questions
Courseiva writes every GCDL question from scratch — 829 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This GCDL 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 GCDL exam.