A team wants proactive alerting if their public HTTPS endpoint returns a non-2xx HTTP status code or becomes unreachable — before users report it. Which Cloud Monitoring capability provides this?
Uptime checks actively probe the endpoint from multiple locations, alert on non-2xx status codes, and detect outages even during zero-traffic periods.
Why this answer
An uptime check with an HTTP status code condition is the correct choice because Cloud Monitoring’s uptime checks are specifically designed to proactively verify that a public HTTPS endpoint is reachable and returns a successful HTTP status (e.g., 2xx). When the check detects a non-2xx status or a timeout/unreachable condition, it can trigger an alert before users are impacted. This is the only option that directly monitors endpoint availability and HTTP response codes from an external perspective.
Exam trap
Google Cloud often tests the distinction between proactive monitoring (uptime checks) and reactive logging (log-based alerts), trapping candidates who assume that log entries for 5xx errors are sufficient for early detection, when in fact they require the error to already occur and be logged.
How to eliminate wrong answers
Option A is wrong because a log-based alert on 5xx error log entries is reactive—it only fires after a 5xx response has been logged, and it cannot detect unreachable endpoints (e.g., DNS failures or connection timeouts) that never generate a log entry. Option C is wrong because Cloud Armor is a web application firewall that blocks or filters traffic based on rules, not a monitoring tool; it does not generate proactive alerts about endpoint status. Option D is wrong because a metric alert on instance CPU exceeding 90% monitors compute resource utilization, not the HTTP endpoint’s availability or response status, so it would not detect a non-2xx or unreachable condition.