Google ACE Practice Question: A team wants to receive an email alert when the…

Answer analysis

Option-by-option breakdown

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

• ✗

  A dashboard with a CPU utilization chart

  Why it's wrong here

  A dashboard displaying a CPU utilization chart is a visualization tool, not a monitoring notification mechanism. It renders the time-series metric so a human can observe trends, but it cannot evaluate thresholds or trigger notifications on its own. To receive an automatic alert when CPU is high, you must pair the metric with an alerting policy that defines a condition and a notification channel.

• ✓

  An alerting policy with a CPU utilization threshold condition

  Why this is correct

  An alerting policy with a CPU utilization threshold condition is the correct choice because it continuously evaluates the compute.googleapis.com/instance/cpu/utilization metric against the threshold you set. Once the metric exceeds the threshold for the specified duration (e.g., 5 minutes), the policy triggers a notification through the configured channel (email, SMS, webhook, etc.). This provides the real-time proactive notification that dashboards, log-based metrics, and uptime checks cannot.

• ✗

  A log-based metric filter for high-CPU events

  Why it's wrong here

  A log-based metric filter is designed to extract numeric data from log entries, such as counting occurrences of ERROR or measuring latency from structured payloads. CPU utilization, however, is a resource metric emitted directly as a time series by the Compute Engine platform or the monitoring agent; it is not a field inside the VM's log records. Even if you created a custom logging pipeline to export CPU stats to logs, you would still need an alerting policy to evaluate and act on the resulting metric—making the log-based filter an unnecessary extra step with no direct notification capability.

• ✗

  An uptime check targeting the managed instance group

  Why it's wrong here

  An uptime check targeting the managed instance group sends synthetic HTTP, HTTPS, or TCP probes from locations outside Google Cloud to verify that the endpoint is reachable and returns an expected response. It answers 'is my service up?' but says nothing about how loaded the underlying VM's CPUs are—a group could be responding normally while CPU utilization is critically high. Uptime checks are designed for availability, not resource utilization metrics, so they cannot be used as a condition for CPU threshold alerting.

Go deeper

Related to this question