FirstTry

Objective 3.1

PCDE

Balancing change, velocity, and reliability of the service

Objective 3.1 sits in Applying site reliability engineering practices, which carries 18% of the Cloud DevOps Engineer exam. The questions below are original, written from the official objective title above, and each explanation cites the Google Cloud page it rests on.

Objective title verbatim from the official objectives. Google Cloud exam page ↗

A worked example

Shown solved, with the whole explanation open: this is what every question here carries.

3-1Applying site reliability engineering practices

A team proposes moving a service from 99.99 to 99.999 percent availability. Which argument weighs against doing it?

Users on less reliable devices cannot tell the differenceCorrect · your answerCorrect: the surrounding path sets the ceiling.
Time-based availability cannot express five ninesFive nines is perfectly expressible, and the objection is about perception rather than notation.
Request success rate stops working above four ninesSuccess rate scales to any target and is used precisely at high availability levels.
Quarterly targets cannot be tracked at that resolutionTracking cadence is a separate matter, and targets are already reviewed weekly or daily.

Correct.

Concept

Reliability is only worth what the person at the far end can perceive. Once the weakest link in the path between a service and its user dominates, further hardening buys nothing anyone experiences.

Why A

The experience is dominated by components outside the service, such as the network and the handset. Someone whose phone is available 99 percent of the time cannot distinguish the two targets at all.

Source

users typically don’t notice the difference between high reliability and extreme reliability in a service, because the user experience is dominated by less reliable components like the cellular network or the device they are working with. Put simply, a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999% service reliability!

Google SRE Book: Embracing Risk, checked August 2026
#sre#availability#reliability-targets

Now you: objective 3.1 questions

No account needed. The explanation opens when you answer.

Sample question 1 of 3

3-1Applying site reliability engineering practices

An engineer budgets each extra nine of reliability as costing the same as the previous one. Why is that wrong?

Sample question 2 of 3

3-1Applying site reliability engineering practices

A team is beating its 99.99 percent availability target by a wide margin every quarter. How does SRE practice read that?

Sample question 3 of 3

3-1Applying site reliability engineering practices

An engineer asks why Google measures availability as a request success rate rather than as uptime. What is the reason?

Full Cloud DevOps Engineer question bank coming

We’re writing the complete bank from the official objectives right now. Leave your email and we’ll tell you when it ships, nothing else, ever.

Read the sources

These are the official pages the questions above cite. Reading them is studying the objective from the primary source, which is what the explanations point you toward anyway.

More objectives in Applying site reliability engineering practices