Google ACE Practice Question: An operations team wants to count how many times…

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 Cloud Monitoring custom metric and write values via the application's exception handler

  Why it's wrong here

  Writing to a Cloud Monitoring custom metric from the application's exception handler forces you to modify code, instrument every error path, and manage metric types manually. This approach also misses errors raised outside try/catch or from unhandled exceptions, and it injects monitoring side effects into application logic. By contrast, a log-based metric derives the count from existing structured log entries with a filter, requiring no code changes and capturing all occurrences that reach Cloud Logging.

• ✓

  Create a log-based metric in Cloud Logging with a filter matching 'PaymentFailure', then alert on it in Cloud Monitoring

  Why this is correct

  A log-based metric in Cloud Logging lets you define a filter, such as 'jsonPayload.message="PaymentFailure"', and Cloud Logging automatically counts matching entries as a time-series metric with minimal latency. This metric appears directly in Cloud Monitoring, where you can set an alerting policy to trigger when the count crosses a threshold. Because it uses the log stream the application already writes, it requires no code changes and monitors all services that emit matching logs, making it the correct solution for real-time error rate alerting.

• ✗

  Export logs to BigQuery and run a scheduled query counting PaymentFailure entries

  Why it's wrong here

  Exporting logs to BigQuery introduces pipeline latency and operational overhead; a scheduled query is not real-time, and you must manage BigQuery exports and scheduled queries separately. Log-based metrics are computed by the logging service as entries are ingested, so they provide near-real-time counts without the complexity of BigQuery or extra query costs. Moreover, alerting on BigQuery results requires an additional integration step, making this approach less direct and slower than using a log-based metric.

• ✗

  Enable Cloud Trace and look for PaymentFailure in trace annotations

  Why it's wrong here

  Cloud Trace is a distributed tracing service that captures latency data and request spans across services; it is not a log-aggregation or alerting tool. Searching trace annotations for PaymentFailure would require instrumenting each service to add annotations and would not provide a count-based signal for alerting. Trace's purpose is performance analysis, not detecting the frequency of business logic errors, so it cannot satisfy a real-time error alerting requirement.

Go deeper

Related to this question