Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

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 a log-based alert in Cloud Logging that triggers on network errors

  Why it's wrong here

  Log-based alerts evaluate log entries that are already present in Cloud Logging, so they can only catch problems that produce log data. An external HTTP endpoint that is unreachable or returning errors does not create logs in your GCP project unless your application or infrastructure explicitly writes them, which makes this approach indirect and unreliable. Additionally, log-based alerting cannot measure latency, SSL certificate expiry, or verify the HTTP status from multiple global vantage points the way a dedicated uptime check can.

• ✓

  Create an uptime check in Cloud Monitoring, then create an alerting policy with condition 'metric threshold' for 'check_failed' and set notification channel to email

  Why this is correct

  Uptime checks in Cloud Monitoring are the managed, intended way to verify that an external HTTP endpoint is reachable and returning expected responses from multiple locations across the globe. The check_failed metric increments each time a probe fails, and a metric-threshold alerting policy lets you define a condition—for instance, when the number of failed checks is consistently above zero over a specified period—and route it to an email notification channel. This directly implements the requirement without custom code.

• ✗

  Use Cloud Functions to periodically call the endpoint and send an email on failure

  Why it's wrong here

  A Cloud Function that periodically calls the endpoint would require you to build a scheduler with Cloud Scheduler, write HTTP client logic, handle timeouts and retries, and manage email delivery, all while debugging cold starts and function timeouts. This approach is brittle and lacks the built-in multi-region probes, latency histograms, and uptime history that Cloud Monitoring provides. It is certainly possible, but it is not the recommended GCP-native monitoring solution.

• ✗

  Configure a TCP health check on the load balancer

  Why it's wrong here

  A TCP health check on a load balancer is designed to assess the health of backend VM instances in a target pool, not to monitor arbitrary external endpoints. Because it only validates that a TCP handshake succeeds, it cannot detect HTTP 500 responses, slow responses, or content-level errors, so it is a poor indicator of application uptime. Furthermore, it would not send an email notification unless you wire up additional infrastructure, and misusing it against an external endpoint would break load balancer configuration.

Go deeper

Related to this question