GCP Professional Cloud DevOps Engineer Practice Question 5: Log Based Distribution Metric

A distribution log-based metric is designed for exactly this case: extracting a numeric value out of log entries the application already writes, and recording its statistical distribution across histogram buckets. The value extractor names the field (jsonPayload.latencyMs), and can apply a regular expression capture group when the field mixes the number with text such as a unit suffix, provided the extracted value converts to a double. Because the result is a true distribution and not a scalar, Cloud Monitoring can chart percentiles and heatmaps from it and it can back a request-latency SLO, all without touching the application.

Option A does not work. Log-based metric labels are strings intended for low-cardinality dimensions such as status class or region. Putting a raw latency value in a label creates one time series per distinct millisecond value, which blows past cardinality limits, and a counter carries no distribution from which a percentile could be computed.

Option B produces the number but not the capability. Exporting to BigQuery adds ingestion and storage cost and a scheduling delay, and the result lives outside Cloud Monitoring, so it cannot be used as an SLI for a Cloud Monitoring SLO or drive an alerting policy, both of which the stem requires.

Option D is the right answer for a service you own, but the stem explicitly forbids modifying the application or adding instrumentation. Native OpenTelemetry instrumentation would be preferable if it were permitted; here the logs are the only available signal.

Reference: Distribution log-based metrics