Google ACE Practice Question: A team wants proactive alerting if their public…

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 log-based alert on 5xx error log entries

  Why it's wrong here

  A log-based alert on 5xx error entries depends on the application writing such entries to Cloud Logging when a request fails. If the service is entirely down, requests are not processed, so no new 5xx log entries are generated; the alert's condition (e.g., count over a rolling window) stays below its threshold and never triggers. Error logs may also be suppressed, sampled, or not emitted for infrastructure-level failures, meaning this approach cannot proactively verify the endpoint is reachable and healthy from outside the network.

• ✓

  An uptime check with an HTTP status code condition

  Why this is correct

  An uptime check is a Cloud Monitoring feature that actively sends synthetic HTTP(S) requests to the endpoint from multiple global vantage points on a fixed interval. By configuring a condition that requires an HTTP status code within the 2xx/3xx range, the check immediately flags any non-2xx/3xx response or timeout as an availability violation. Because the probe generates its own traffic regardless of organic user load, it can detect full outages during zero-traffic periods, precisely matching the need to catch service blackouts.

• ✗

  A Cloud Armor rule blocking 5xx responses

  Why it's wrong here

  Cloud Armor is a Web Application Firewall (WAF) and DDoS protection service that inspects incoming requests against pre-configured security policies such as IP lists, geo-location, or OWASP rules. It cannot inspect or act on HTTP response codes emitted by the backend, because it sits at the edge and only decides whether a request should reach the application. Blocking a 5xx response is conceptually impossible: the 5xx is generated by the origin after Cloud Armor has already allowed the request, so this option cannot monitor or alert on application availability.

• ✗

  A metric alert on instance CPU exceeding 90%

  Why it's wrong here

  A CPU utilization metric alert watches a system-level resource signal, not the application's ability to serve requests successfully. A service can return HTTP 500 errors due to code defects, database connection failures, or invalid input while the instance CPU usage remains low, and conversely, high CPU might only indicate legitimate heavy load without causing errors. Furthermore, during a complete endpoint outage with no incoming traffic, CPU may normalize to near zero, so the alert would never fire—making it blind to the exact availability failure signal this question targets.

Go deeper

Related to this question