A DevOps engineering team operates a data ingestion service running on a Compute Engine regional Managed Instance Group (MIG). The worker instances process tasks pulled from a Cloud Pub/Sub subscription. During high-volume periods, incoming message traffic fluctuates rapidly with intermittent 2-to-3-minute lulls between bursts. The team observes the following issues: VM Thrashing: The MIG autoscaler repeatedly scales out during bursts and scales in during short lulls, causing high instance churn and initialization overhead. Work Disruption: Instances are deleted while still finishing active message processing. Which autoscaler configuration should the team implement to resolve these issues?

Configure scale-in controls with a stabilization period and set max scaled-in replicas to restrict the rate of instance removal.: ### What scale-in controls and stabilization periods are **Scale-in controls** in Compute Engine Managed Instance Groups (MIGs) allow administrators to regulate the pace at which the autoscaler removes VM instances. By defining a **stabilization period** (a lookback window up to several hours) and a **max scaled-in replicas** constraint (either a fixed number or percentage), the autoscaler prevents rapid, abrupt reductions in capacity during transient drops in load. ### How it meets the requirements - **Mitigates VM thrashing:** During short traffic lulls (e.g., 2–3 minutes), the stabilization window keeps the autoscaler evaluating the peak load observed across the specified lookback window rather than reacting instantly to momentary troughs. This prevents instances from being torn down immediately before the next traffic burst arrives. - **Prevents work disruption:** Setting `maxScaledInReplicas` restricts the rate of instance deletions per time unit, providing a gradual scaling curve that gives running instances adequate time to finish inflight messages and drain workloads cleanly. ### Key advantages - **Smooth capacity transitions:** Eliminates the "sawtooth" pattern of rapid provisioning and deprovisioning in bursty environments. - **Cost and performance predictability:** Balances compute resource costs against the overhead and latency penalty of frequent VM cold starts. - **Customizable lookback windows:** Allows teams to set stabilization periods from 0 to 3,600 seconds (or longer depending on configuration) based on workload burst cycles. - **Native control plane integration:** Operates entirely within the managed MIG autoscaling policy without custom orchestration code. ### Why this is optimal Scale-in controls are purpose-built in Google Cloud to handle bursty workloads where short-term metric drops would otherwise trigger premature scale-in events, directly eliminating VM thrashing while protecting in-progress tasks.

Mig Autoscaling Scale In Controls Stabilization | Professional Cloud DevOps Engineer

Mig Autoscaling Scale In Controls Stabilization

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A DevOps engineering team operates a data ingestion service running on a Compute Engine regional Managed Instance Group (MIG). The worker instances process tasks pulled from a Cloud Pub/Sub subscription.

During high-volume periods, incoming message traffic fluctuates rapidly with intermittent 2-to-3-minute lulls between bursts. The team observes the following issues:

VM Thrashing: The MIG autoscaler repeatedly scales out during bursts and scales in during short lulls, causing high instance churn and initialization overhead.
Work Disruption: Instances are deleted while still finishing active message processing.

Which autoscaler configuration should the team implement to resolve these issues?

Increase the autoscaler cool-down period to 30 minutes to suppress metric collection while instances are running.

Configure scale-in controls with a stabilization period and set max scaled-in replicas to restrict the rate of instance removal.

Set the autoscaling mode to 'Only scale out' and configure a Cloud Scheduler job to issue periodic scale-in API requests.

Enable predictive autoscaling in 'Optimize for availability' mode and switch the target metric from Cloud Pub/Sub queue depth to CPU utilization.

Professional Cloud DevOps Engineer

Mig Autoscaling Scale In Controls Stabilization

Related questions