Cloud Digital Leader Scaling with Google Cloud operations Practice Question
A large enterprise runs a critical application on Google Cloud consisting of Compute Engine instances behind a TCP load balancer. The application experiences intermittent slow response times that last for about 10 minutes before returning to normal. This pattern has been occurring every few days at random times. The operations team has configured Cloud Monitoring alerts for CPU and memory, but no alerts have fired. They have also reviewed the load balancer logs and see no errors, but the latency spikes. The application logs show no errors during these periods. The team suspects a resource bottleneck but cannot find it. Further investigation reveals that the application makes synchronous calls to an external authentication service for each request. What is the most likely cause and corrective action?
⚠ Common exam trap
Google Cloud often tests the misconception that all latency originates from internal infrastructure (load balancers, autoscalers, or CPU), when the real cause is an external dependency's synchronous call pattern that creates a hidden bottleneck without triggering resource alerts.
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
✓
The application is making synchronous calls to an external authentication service that occasionally has latency spikes; implement caching and asynchronous processing.
The intermittent latency spikes lasting ~10 minutes, with no errors in application or load balancer logs and no CPU/memory alerts, point to an external dependency issue. The synchronous calls to the external authentication service are the likely bottleneck: if that service experiences transient latency, every request is blocked, causing the application's response time to spike. Caching authentication tokens and using asynchronous processing (e.g., a queue or background refresh) decouples the application from the external service's variability, eliminating the cascading latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The TCP load balancer is experiencing connection draining issues; switch to a proxy-based load balancer.
Why it's wrong here
Connection draining on a TCP load balancer is designed to gracefully terminate existing connections when instances are removed, and would manifest as connection resets or failed requests during scale-in events, not as intermittent application slowdowns. Since load balancer logs show no errors, the LB layer is healthy and this is not the source of the issue; the cause is more likely at the application or external dependency level.
- ✗
The instance group's autoscaler is configured with a cooldown period that is too long; reduce the cooldown period.
Why it's wrong here
An autoscaler cooldown period only delays the addition or removal of instances after a scaling decision, but if there are no resource utilization alerts, the instances are not hitting the thresholds that would trigger autoscaling in the first place. Without evidence of CPU, memory, or request-based pressure, a long cooldown would be irrelevant because the system is not actively attempting to scale, so reducing it would have no effect on intermittent slowdowns.
- ✓
The application is making synchronous calls to an external authentication service that occasionally has latency spikes; implement caching and asynchronous processing.
Why this is correct
Synchronous calls to an external authentication service introduce a hard dependency where any latency spike in that service directly blocks the application's request threads, causing intermittent slowdowns that correlate with the external service's variability. Implementing caching for authentication results and switching to asynchronous processing decouples the critical path, absorbs latency spikes, and improves overall response time consistency—especially since the rest of the infrastructure is healthy.
- ✗
The virtual machine instances are suffering from CPU throttling due to sustained use of burstable CPU; move to a machine type with more CPUs.
Why it's wrong here
Burstable CPU instances throttle only after accumulated CPU credits are exhausted due to sustained high usage, and such throttling would produce sustained performance degradation and trigger CPU utilization or throttling alerts. The absence of CPU alerts indicates the instances are not credit-starved, so moving to a larger machine type treats a symptom that isn't present; the intermittent nature of the slowdowns points instead to variable external dependencies rather than local compute limits.
Visual reference
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Load balancer
A load balancer is a device or software that distributes incoming network traffic across multiple servers so no single server gets overwhelmed.
Key term
Compute Engine
Compute Engine is Google Cloud's Infrastructure-as-a-Service (IaaS) offering that lets you create and run virtual machines on Google's infrastructure.
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.