Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  availability (uptime)

  Why it's wrong here

  Availability (uptime) is typically defined as the percentage of time an endpoint is reachable, often measured via health checks or TCP probes. This metric is insufficient for an API SLO because a service can be technically 'up' and accepting connections while returning errors, timeouts, or corrupt data for a large fraction of requests. Uptime also treats all downtime equally and ignores partial failures, making it a coarse, infrastructure-level metric that does not reflect the user-perceived success rate.

• ✗

  latency at 99th percentile

  Why it's wrong here

  Latency at the 99th percentile measures the response time of the slowest 1% of requests and is a performance metric, not a reliability metric. An API could have excellent latency while returning 50% errors, or it could be slow but still succeed, so latency does not capture whether requests succeeded or failed. Using latency as an SLI conflates performance with success and would obscure the true error rate, which is the critical input for an error budget.

• ✗

  requests/success

  Why it's wrong here

  The term 'requests/success' is ambiguous and, if interpreted as a raw count of successful requests per second, it is not a normalized or meaningful SLI. Raw counts are confounded by traffic volume: a doubling in traffic could produce more successful requests even while the error rate also increases. The correct SLI must be a ratio—good events divided by total events—to represent a proportion between 0 and 1 that is independent of request volume, enabling fair comparison over time and across service tiers.

• ✓

  SLI = good events / total events

  Why this is correct

  An SLI defined as good events divided by total events is the canonical, user-centric approach for an API service, as it directly measures the proportion of requests that meet predefined success criteria. For example, a request may be considered 'good' if it returns an HTTP 2xx status and has a latency below a threshold, while 'total events' counts every request received. This ratio yields a percentage that aligns with the actual user experience and forms the basis for setting an SLO and calculating an error budget, following standard SRE practices.

Go deeper

Related to this question