Examkin

Question

Difficulty: Very hardAuto-scaling and Capacity Planning

An enterprise e-commerce platform processes asynchronous order validation events using Cloud Pub/Sub and a Managed Instance Group (MIG) of Compute Engine worker instances. During major promotional events, message ingestion rates spike abruptly, resulting in severe processing backlogs. The worker workload is primarily I/O-bound due to database validation calls, causing default CPU-based autoscaling to react too slowly. Additionally, during a recent peak event, scale-out attempts failed because the project hit the regional compute engine vCPU quota. Which TWO architectural and operational strategy changes should the Cloud Architect implement to ensure autoscaling reliability and sufficient operational capacity during peak traffic? (Select TWO.)

  1. Configure the Managed Instance Group autoscaling policy to use a custom Cloud Monitoring metric tracking Cloud Pub/Sub unacknowledged message queue depth per instance, and combine it with predictive scaling or scheduled capacity rules.Answer
  2. Proactively analyze historical peak demand and submit regional vCPU and resource quota increase requests well in advance of anticipated promotional events.Answer
  3. C
    Lower the target CPU utilization threshold on the existing Managed Instance Group autoscaler to 20% average CPU to trigger faster instance provisioning during queue spikes.
  4. D
    Migrate the stateless worker nodes from Compute Engine Managed Instance Groups to a dedicated Google Kubernetes Engine (GKE) Enterprise cluster to bypass GCP regional quota constraints.
  5. E
    Enable dynamic automated API quota burst management in Cloud Monitoring to request immediate quota increases automatically whenever MIG scale-out signals hit regional limits.

Answer

The architect should configure the Managed Instance Group autoscaler using a custom Cloud Monitoring metric tracking Cloud Pub/Sub queue depth (combined with scheduled/predictive scaling) and proactively request regional vCPU quota increases prior to expected traffic events.
The correct solution addresses both the metric responsiveness issue and the hard infrastructure boundary. Scaling based on Pub/Sub unacknowledged message depth accurately measures work backlog for I/O-bound tasks, while scheduled/predictive scaling pre-provisions baseline capacity for known events. Concurrently, submitting regional vCPU quota increases beforehand guarantees that GCP infrastructure has allocated sufficient capacity ceiling to allow the Managed Instance Group to scale out when traffic peaks.

Step-by-Step Solution

1
Identify the performance bottleneck and metric misalignment
Recognize that I/O-bound tasks waiting on external services exhibit low CPU utilization, making CPU metrics ineffective for triggering timely scale-out events.
Autoscaling metrics must reflect actual work backlog; for message-driven microservices, queue depth or message age metrics directly correlate with required processing capacity.
2
Select appropriate queue-based and predictive autoscaling policies
Implement custom metric autoscaling based on Pub/Sub `num_undelivered_messages` target per instance, supplemented with scheduled autoscaling for planned events.
Queue-based metrics scale instances proportional to work waiting to be done, preventing backlog spikes and SLA breaches.
3
Perform capacity planning and quota verification
Calculate maximum required instance count during peak events and submit quota increase requests for regional vCPUs ahead of time.
GCP compute quotas are enforced at runtime; failing to secure sufficient quota beforehand causes instance creation failures regardless of autoscaler policies.

Key Concept

Queue-Based Autoscaling and Proactive Regional Quota Management
Rate this question

Topics

Auto-scaling and Capacity Planning

More questions from this topic