Examkin

Question

Difficulty: HardAuto-scaling and Capacity Planning

An enterprise financial institution operates a critical transaction ledger service on Compute Engine Managed Instance Groups (MIGs). The application is heavily network I/O-bound and database connection-bound during peak trading hours. During recent market volatility, transaction latency spiked significantly because the MIG autoscaler failed to add instances, even though overall CPU utilization remained low at approximately 35%35\%. When the operations team attempted an emergency manual scale-out to absorb the load, instance creation failed due to exceeding the regional compute API resource limits. Which combined auto-scaling configuration and capacity planning strategy should a Cloud Architect implement to ensure system reliability during sudden market volatility events?

  1. Configure the MIG autoscaler using a custom Cloud Monitoring metric that tracks active database connection pool utilization, and proactively request regional quota increases alongside target capacity reservations prior to high-volatility periods.Answer
  2. B
    Migrate the ledger workload to Google Kubernetes Engine (GKE) with a Horizontal Pod Autoscaler (HPA) targeting CPU utilization, relying on Cluster Autoscaler to dynamically provision node capacity on demand.
  3. C
    Lower the MIG autoscaler target CPU utilization threshold from 80%80\% down to 15%15\% to trigger earlier scaling, relying on Compute Engine's automatic just-in-time quota adjustment mechanisms.
  4. D
    Retain CPU-based MIG autoscaling while adding a secondary metric for memory utilization, and configure compute instances across multiple global regions without requesting quota adjustments.

Answer

Configure the MIG autoscaler using a custom Cloud Monitoring metric that tracks active database connection pool utilization, and proactively request regional quota increases alongside target capacity reservations prior to high-volatility periods.
For I/O-bound or connection-bound applications where CPU usage remains low during latency degradation, auto-scaling policies must evaluate custom metrics (such as active database connections or request queue depth). Additionally, auto-scaling cannot succeed if regional resource quotas are exceeded; proactive quota requests combined with Compute Engine capacity reservations ensure physical capacity and administrative limit availability during high-demand events.

Step-by-Step Solution

1
Identify the primary bottleneck for the workload
Recognize that CPU utilization (35%35\%) is not saturated, whereas database connection pool saturation represents an I/O bottleneck.
Standard CPU metrics will not trigger auto-scaling when the bottleneck is I/O or external resource pool limits.
2
Select an appropriate autoscaling signal
Implement a custom Cloud Monitoring metric representing database connection pool exhaustion or pending request queues.
Custom metrics allow autoscalers to scale out instances based on true workload indicators rather than CPU/memory defaults.
3
Address infrastructure capacity constraints
Submit regional quota increase requests and establish Compute Engine capacity reservations in advance of anticipated volatility events.
Regional quota increases prevent API provisioning failures, and reservations ensure required Compute Engine VM capacity is guaranteed in target zones.

Key Concept

Custom Metric Autoscaling and Capacity Reservation Management
Rate this question

Topics

Auto-scaling and Capacity Planning

More questions from this topic