Google ACE Practice Question: A team's application emits a custom business…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable the Custom Metrics feature flag in the GCP Console under Cloud Monitoring settings

  Why it's wrong here

  Cloud Monitoring does not expose a 'Custom Metrics' feature flag in the GCP Console. Custom metric support is always enabled at the API layer; the application simply needs to publish valid time series via projects.timeSeries.create using a metric type in the custom.googleapis.com/ namespace. Once valid data is ingested, the metric is automatically registered and becomes visible in Metrics Explorer, with no console toggle or settings change required.

• ✓

  Instrument the application to write the metric to the Cloud Monitoring API using a client library or OpenTelemetry

  Why this is correct

  Instrument the application with a client library such as google-cloud-monitoring or an OpenTelemetry exporter for Google Cloud, define a MetricDescriptor for your metric type under custom.googleapis.com/, and then call projects.timeSeries.create to push observations. After valid time series data is written, Cloud Monitoring automatically makes the metric available for charting in Metrics Explorer and for use in alerting policies. This is the standard, direct path for application-level custom metrics like orders per minute.

• ✗

  Create a log-based metric that extracts the orders value from application logs

  Why it's wrong here

  A log-based metric is a distinct mechanism that derives a metric from log entries by applying a logging filter and optionally extracting a numeric value, so it depends on the application already emitting suitable logs. It creates a metric under logging.googleapis.com/user/ rather than custom.googleapis.com/, and it incurs log-ingestion pipeline latency. This approach is legitimate but not required; if the application can emit metric data directly to the Monitoring API, log-based extraction becomes unnecessary and indirect.

• ✗

  Custom metrics require BigQuery — store values in BigQuery and link it to Cloud Monitoring

  Why it's wrong here

  Custom metrics do not require BigQuery. Cloud Monitoring maintains its own time series ingestion and storage backend, so you can write custom metric data directly to the Monitoring API without involving BigQuery. BigQuery is only an optional destination for long-term retention or SQL analytics via exports, and there is no operation that 'links' BigQuery to Cloud Monitoring to make it a real-time source of metrics. Adding BigQuery would only increase latency and operational complexity.

Go deeper

Related to this question