Google ACE Practice Question: Monitor the CPU utilization across all instances…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create an alerting policy using the Logs Explorer to parse instance logs.

  Why it's wrong here

  Logs Explorer is designed for searching and analyzing structured log data, not for querying numeric time-series metrics. Compute Engine CPU utilization is collected and stored as a metric in Cloud Monitoring, not emitted as a log entry by default. To alert on logs, you would need to create a log-based metric, which in this case would require custom instrumentation of applications to write CPU usage to logs — an inefficient and indirect approach. Even then, the alerting policy would be based on log volume or custom fields rather than the native, authoritative CPU metric.

• ✗

  Use Cloud Scheduler to call the monitoring API periodically.

  Why it's wrong here

  Cloud Scheduler triggers HTTP calls on a schedule, but it cannot natively evaluate metric thresholds or trigger alerting actions based on real-time CPU utilisation; it merely invokes the monitoring API at fixed intervals, which introduces latency between spikes and detection. This approach is tempting because Cloud Scheduler is designed for periodic, cron-like tasks such as triggering backups or health checks, and would be correct if the requirement were to collect metric snapshots on a schedule rather than to receive immediate, threshold-based alerts.

• ✗

  Set up a cron job to run gcloud compute instances list and check CPU.

  Why it's wrong here

  Running a cron job that calls `gcloud compute instances list` cannot produce CPU utilization because that command returns instance metadata such as name, zone, and status, never metric readings. To retrieve CPU usage you would need a separate call such as `gcloud monitoring time-series list`, and then you would have to write custom logic to parse the output and compare thresholds. A cron-based approach also only checks at fixed intervals, so a CPU spike could go unnoticed for minutes; moreover, it lacks built-in notification channels, retries, and incident tracking that a formal alerting policy provides. This is a manual, non-scalable solution and is not real-time.

• ✓

  Create an alerting policy in Cloud Monitoring for the metric 'compute.googleapis.com/instance/cpu/utilization'.

  Why this is correct

  Cloud Monitoring automatically collects `compute.googleapis.com/instance/cpu/utilization` from every Compute Engine VM without requiring an agent, storing it as a time-series metric. You can create an alerting policy with a threshold condition, setting an aggregation (e.g., mean value across instances) and a duration (e.g., 5 minutes) to reduce noise, and attach notification channels like email or Pub/Sub. This is the native, managed, and real-time mechanism for CPU monitoring, and it integrates directly with the rest of Cloud Monitoring, including dashboards and incident escalation.

Go deeper

Related to this question