Examkin

Question

Difficulty: Very hardManaging Compute Engine Resources

Your organization runs an enterprise web application on a Compute Engine Managed Instance Group (MIG) configured with autoscaling. The application requires 4 minutes (240 seconds) after VM boot to download artifacts, initialize local caches, and pass health checks. During sudden load spikes, the autoscaler initiates multiple scale-out events in rapid succession before previously launched instances complete startup, leading to over-provisioning and resource instability. Furthermore, the operations team needs to collect detailed OS-level RAM usage metrics from these VM instances inside Cloud Monitoring. Which set of actions should you take to resolve both issues?

  1. Set the autoscaling policy cool-down period to at least 240 seconds, and install the unified Google Cloud Ops Agent on the VM instances.Answer
  2. B
    Increase the target CPU utilization threshold in the autoscaling policy to 90%, and install the legacy Stackdriver Monitoring agent on the VM instances.
  3. C
    Reconfigure the instance template to provision Spot VMs to accelerate instance creation times, and assign the primitive Owner role to the VM service account.
  4. D
    Submit a GCP quota increase request for Compute Engine regional vCPUs, and perform an immediate hard reset on all instances in the MIG.

Answer

Configure the autoscaling policy cool-down period to at least 240 seconds (4 minutes) to allow new instances to complete application initialization before further scaling decisions are evaluated, and deploy the Google Cloud Ops Agent to collect guest OS memory metrics.
The correct approach requires setting the MIG autoscaling cool-down period (`--cool-down-period`) to match or exceed the 4-minute application startup duration. This ensures the autoscaler ignores instance metrics until initialization completes. Installing the Google Cloud Ops Agent is the recommended solution to collect OS-level memory metrics, as default Compute Engine metrics only cover hypervisor-visible metrics like CPU and disk I/O.

Step-by-Step Solution

1
Analyze the autoscaling behavior during instance startup
Identified that the 4-minute application boot time causes the autoscaler to falsely perceive unresolved load capacity, triggering premature scale-out events.
The cool-down period defines how long the autoscaler waits after a new instance is created before observing its metrics for subsequent scaling decisions.
2
Configure the MIG cool-down parameter
Set `--cool-down-period` to 240 seconds (or higher) in the autoscaler settings.
This prevents metric thrashing and unnecessary instance over-provisioning during the 4-minute boot sequence.
3
Address guest OS memory metric telemetry requirements
Install and configure the unified Google Cloud Ops Agent on the base image or startup script.
Hypervisor-level metrics cannot inspect guest OS memory usage; the Google Cloud Ops Agent is the current standard agent required for system memory and disk metrics.

Key Concept

Compute Engine MIG Autoscaling Cool-down Period and Telemetry Management
Rate this question

Topics

Managing Compute Engine Resources

More questions from this topic