Examkin

Question

Difficulty: HardAuto-scaling and Capacity Planning

An enterprise retail platform is preparing for an annual flash sale expected to increase incoming order traffic by 500% within minutes. The order processing service runs on a Compute Engine Managed Instance Group (MIG) that consumes messages from a Cloud Pub/Sub topic. Stress testing reveals that scaling the MIG based on CPU utilization is ineffective because workers spend significant time waiting on external database I/O, leading to delayed scale-out and queue backlog buildup. Additionally, the required peak capacity for the event exceeds the project's current regional N2 CPU limits. Which TWO actions should the Cloud Architect take to ensure operational reliability and seamless capacity scaling during the flash sale?

  1. Configure the MIG autoscaler to scale based on a custom Cloud Monitoring metric tracking Cloud Pub/Sub unacknowledged message queue depth per instance.Answer
  2. B
    Lower the target CPU utilization threshold on the MIG autoscaler to 20% to force earlier instance creation during I/O wait states.
  3. Submit a regional quota increase request for Compute Engine N2 CPUs in the target region well in advance of the sale event.Answer
  4. D
    Rely on Compute Engine dynamic quota expansion to automatically raise the project regional CPU limits when autoscaling demand spikes.
  5. E
    Migrate the processing workload to a Google Kubernetes Engine (GKE) Autopilot cluster to bypass regional Compute Engine CPU quota constraints.

Answer

The Cloud Architect should configure the MIG autoscaler using a custom Cloud Monitoring metric for Cloud Pub/Sub unacknowledged message queue depth and submit a regional Compute Engine N2 CPU quota increase request in advance.
For I/O-bound background worker services consuming from message queues, CPU utilization is an unreliable metric because worker threads spend time blocked on external database operations while keeping CPU usage low. Configuring the Managed Instance Group to scale based on a custom Cloud Monitoring metric tracking Cloud Pub/Sub unacknowledged message count ensures scaling responds immediately to queue backlog. Furthermore, GCP resource quotas represent administrative limits that do not expand automatically; submitting a regional N2 CPU quota request prior to the high-traffic event guarantees that Compute Engine can provision the required VM instances during scale-out.

Step-by-Step Solution

1
Identify the primary autoscaling bottleneck for I/O-bound workloads
Determine that CPU utilization does not reflect worker thread I/O wait times, whereas Cloud Pub/Sub queue depth accurately measures pending backlog.
Queue depth metrics trigger rapid scaling proportional to actual incoming work rather than CPU load.
2
Assess capacity limits and quota requirements
Recognize that anticipated peak instance counts exceed current regional N2 CPU quota limits.
GCP quotas require manual request and approval processes; failure to request quotas in advance will cause instance creation failures when scaling out.

Key Concept

Custom Metric Autoscaling and Proactive Capacity Quota Planning
Rate this question

Topics

Auto-scaling and Capacity Planning

More questions from this topic