Examkin

Question

Difficulty: HardDesigning Infrastructure for Technical Requirements and High Availability

A financial analytics company runs an I/O-intensive reporting application on a Compute Engine Regional Managed Instance Group (MIG) behind an External HTTP(S) Load Balancer. During sudden high-volume processing events, backend instances experience severe memory saturation and active connection pool exhaustion, leading to dropped client requests while CPU utilization stays consistently below 25%. Furthermore, during a recent brief upstream database latency spike, the load balancer marked all backend instances as unhealthy simultaneously because the health check probes an endpoint that performs a live query on the database. Which architectural modification best resolves both the autoscaling failure and the cascading health check failure?

  1. Configure MIG autoscaling using Custom Cloud Monitoring metrics for memory utilization and database connection pool saturation, and point the load balancer health check to a lightweight local application status endpoint that does not probe downstream database dependencies.Answer
  2. B
    Lower the target CPU utilization threshold for the MIG autoscaler from 60% to 15%, and point the load balancer health check to a lightweight local application status endpoint that does not probe downstream database dependencies.
  3. C
    Configure MIG autoscaling using Custom Cloud Monitoring metrics for memory utilization and database connection pool saturation, while increasing the load balancer health check check interval and timeout settings for the deep database query endpoint.
  4. D
    Migrate the compute workload to a Google Kubernetes Engine (GKE) Autopilot cluster equipped with Horizontal Pod Autoscaling (HPA) based on standard CPU metrics, and configure the ingress health check to probe the database query endpoint.

Answer

Configure MIG autoscaling using Custom Cloud Monitoring metrics for memory utilization and database connection pool saturation, and point the load balancer health check to a lightweight local application status endpoint that does not probe downstream database dependencies.
The correct solution addresses both root causes directly. For I/O-bound applications that exhaust memory or connection pools without increasing CPU load, MIG autoscaling must be configured using custom metrics published to Cloud Monitoring. Additionally, load balancer health checks should probe a shallow, local HTTP endpoint on the application server (evaluating local process health) rather than querying backend databases, preventing transient database latency from causing cascading instance removals.

Step-by-Step Solution

1
Analyze the scaling bottleneck metric mismatch
Identified that CPU utilization remains low (<25%) during memory and I/O connection pool exhaustion, demonstrating that CPU-based autoscaling is ineffective.
I/O-bound workloads require custom metrics such as memory utilization or active connection counts to accurately signal horizontal scale-out.
2
Evaluate load balancer health check failure mode
Identified that probing deep database endpoints causes cascading service outages during transient database latency.
Load balancer health checks must evaluate local web server instance health, not downstream infrastructure availability, to avoid misinterpreting database slowdowns as compute node failures.
3
Synthesize the high-availability architectural design
Combine Custom Cloud Monitoring metric autoscaling with shallow local application health probes.
This dual change ensures accurate autoscaling under load and prevents cascading instance failures during database degradation.

Key Concept

Designing High Availability Autoscaling and Health Checking for I/O-Bound Workloads
Rate this question

Topics

Designing Infrastructure for Technical Requirements and High Availability