Professional Cloud DevOps Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Your DevOps team is implementing a Service Level Objective (SLO) error-rate alerting policy in Google Cloud Monitoring for a microservice deployed across 200 Compute Engine virtual machine (VM) instances. The initial configuration computed a ratio across two independent custom metrics: custom.googleapis.com/rpc/total_count and custom.googleapis.com/rpc/error_count.
During low-traffic intervals, on-call engineers receive frequent false-positive alerts caused by anomalous ratio spikes (such as 1/0 or 2/1) evaluated on individual instances. You need to redesign the custom metrics, alignment, and alerting policy condition to eliminate these ratio calculation anomalies, reduce alert fatigue, and minimize monitoring costs.
What should you do?
Computing ratios using a single metric type with dimensional labels (such as response_code or status="OK"|"ERROR") ensures that every event is recorded atomically within the exact same time series stream. Combining this with an extended alignment window and cross-series reduction regularizes time-series data into stable aggregates before evaluating ratio thresholds.
status label ensures consistent alignment interval boundaries for both successful and failed events.Google Cloud Monitoring strongly recommends using a single metric with label filters for ratio conditions because cross-metric calculations across different metric descriptors inherently introduce sampling drift. Aggregating across time series avoids individual node noise while ensuring true service-level degradation is rapidly detected.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.