Google ACE Practice Question: A platform team wants to define a formal service…

A platform team wants to define a formal service level objective (SLO) for their API: 99.9% of requests must succeed (HTTP 2xx) over a 30-day rolling window. Which Cloud Monitoring feature tracks this?

⚠ Common exam trap

Google Cloud often tests the distinction between an SLO (a formal target with error budgets and burn rates) and a simple threshold alert or uptime check, so candidates mistakenly choose an alerting policy or uptime check because they think any 99.9% threshold tracking qualifies as an SLO.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Define a Cloud Monitoring SLO with a 99.9% availability target over a 30-day rolling window

Cloud Monitoring's SLO feature is specifically designed to track compliance with a formal service level objective, such as 99.9% of requests succeeding over a 30-day rolling window. It automatically calculates the success rate from the selected metric (e.g., request count or latency) and reports the SLO's performance over the defined period, including error budgets and burn rates.

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 an alerting policy with a 99.9% threshold on the request success metric
Why it's wrong here
An alerting policy evaluates a metric at a point in time and fires when the value crosses a threshold, but it does not aggregate or compare data across a 30-day rolling compliance window the way an SLO does. It cannot compute error budget consumption or burn rate, and a single threshold alert gives no information about whether overall availability met a 99.9% target over the month.
✓
Define a Cloud Monitoring SLO with a 99.9% availability target over a 30-day rolling window
Why this is correct
Cloud Monitoring SLOs are purpose-built for this scenario: you define a service-level objective with a 99.9% availability target, and Cloud Monitoring automatically calculates the error budget over a 30-day rolling window, tracks burn rate, and can alert when the budget is being consumed too quickly. This matches the requirement for measuring sustained availability against a target, and it is the only option that provides proactive error-budget-based alerting.
✗
Build a BigQuery dashboard showing 30-day average success rates from exported logs
Why it's wrong here
A BigQuery dashboard built from exported logs is a manual, after-the-fact reporting tool; it gives you a historical view of average success rates but lacks automated alerting, error budget calculation, and burn-rate monitoring. Unless you build custom pipeline code to query and compare against the target, it will not tell you when you are about to violate the 99.9% availability objective, unlike a Cloud Monitoring SLO.
✗
Set an uptime check target of 99.9% in Cloud Monitoring
Why it's wrong here
Uptime checks only probe endpoint reachability from external locations; they never see the actual HTTP status codes or error rates that real users experience, so a 99.9% uptime result can coexist with a much higher request failure rate for legitimate traffic. Setting an uptime check target therefore measures infrastructure availability from outside, not the success rate of service requests, and is not a substitute for an SLO on request success.

Go deeper

Google ACE Practice Question: A platform team wants to define a formal service…

Why each option matters

Option-by-option breakdown

Related to this question