Google ACE Practice Question: Monitor a Cloud Run service for errors and…

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 metric on Cloud Run error logs, then create an alerting policy on that metric with a PagerDuty notification channel.

  Why this is correct

  This is the correct pattern: first, create a log-based metric in Cloud Logging that counts Cloud Run errors, for example by filtering on status codes >= 500 or severity ERROR. Then, define a Cloud Monitoring alerting policy that watches that metric and triggers when the error count crosses a threshold. Finally, attach a PagerDuty notification channel to the policy so an incident is created automatically. This approach uses fully managed services and requires no custom application code.

• ✗

  Configure Cloud Run to send error emails directly to the PagerDuty email integration.

  Why it's wrong here

  Cloud Run has no native email alerting capability; it only writes structured logs to Cloud Logging. You cannot configure Cloud Run itself to send error emails to a PagerDuty email integration without introducing custom code or external logic. Even then, using an email integration is less reliable and lacks the structured incident context that a direct Cloud Monitoring–PagerDuty notification channel provides, making this a poor and nonstandard workaround.

• ✗

  Use Cloud Pub/Sub to stream Cloud Run logs to a custom application that pages PagerDuty.

  Why it's wrong here

  Streaming Cloud Run logs to Pub/Sub and building a custom subscriber to page PagerDuty is an unnecessarily complex solution. Cloud Monitoring already provides a native PagerDuty notification channel, so you can alert directly without writing custom code or maintaining a message-processing pipeline. Adding Pub/Sub introduces extra latency, cost, and a new failure point, violating the best practice of relying on managed alerting services.

• ✗

  Enable Cloud Run's built-in alerting feature in the service configuration.

  Why it's wrong here

  Cloud Run does not expose a built-in alerting feature in its service YAML, console, or gcloud configuration. Alerting is a core capability of Cloud Monitoring, which is a separate service that you configure via alerting policies and notification channels. There is no 'alerts' field or enabled flag in a Cloud Run service definition, so this option is technically impossible.

Go deeper

Related to this question