Cloud Digital Leader Scaling with Google Cloud operations Practice Question

An operations team wants to receive an automated alert when their web application's HTTP error rate exceeds 5% for more than 5 minutes. Which Google Cloud product is used to configure this type of metric-based alert?

⚠ Common exam trap

Google Cloud often tests the misconception that Cloud Logging can directly send alerts, but in reality, Cloud Logging only stores logs and log-based metrics; the alerting policy must always be configured in Cloud Monitoring.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Cloud Monitoring, by creating an alerting policy on the HTTP error rate metric with a 5-minute evaluation window and notification channel

Cloud Monitoring is the correct service because it is purpose-built for creating alerting policies based on metrics like HTTP error rates. You can define a condition that triggers when the error rate exceeds 5% for a specified evaluation window (e.g., 5 minutes) and route the alert through a notification channel (e.g., email, Slack). This directly matches the requirement for a metric-based alert with a time-based threshold.

Answer analysis

Option-by-option breakdown

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

✗
Cloud Logging, by configuring a log-based metric and email notification
Why it's wrong here
Cloud Logging collects log data and can create log-based metrics, but the alerting and threshold policy described is configured in Cloud Monitoring, not directly in Cloud Logging. Cloud Monitoring can consume Cloud Logging data but is the correct alerting layer.
✓
Cloud Monitoring, by creating an alerting policy on the HTTP error rate metric with a 5-minute evaluation window and notification channel
Why this is correct
Cloud Monitoring is the correct service. An alerting policy specifies: the metric to watch (HTTP error rate), the threshold (5%), the evaluation window (5 minutes), and the notification channel (email, PagerDuty, Slack, etc.). This is a core Cloud Monitoring capability.
✗
Cloud Trace, by setting a trace sampling threshold for error requests
Why it's wrong here
Cloud Trace is a distributed tracing service focused on analyzing request latency and performance behavior across services. A trace sampling threshold determines which requests are selected for trace collection, but it does not evaluate an aggregated HTTP error rate over a 5-minute window or trigger notifications. Even if it samples all error requests for debugging, it cannot compare the error rate to a 5% threshold and alert via a notification channel. Threshold-based alerting on a metric belongs to Cloud Monitoring, not Cloud Trace.
✗
Security Command Center, by configuring a finding for high error rates
Why it's wrong here
Security Command Center is designed for security posture management, vulnerability detection, and threat identification, not for operational metric monitoring. A high HTTP error rate is an application performance or availability issue, not inherently a security finding, and Security Command Center does not natively ingest or evaluate metric thresholds like a 5% error rate over 5 minutes. Configuring a 'finding' would require a separate external system to detect the condition and create the finding, and it lacks the alerting policy and notification channel mechanism provided by Cloud Monitoring. Thus, it does not satisfy the scenario's requirement for threshold-based alerting on an application metric.

Go deeper

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question