6.4 Cloud Observability, SLIs, SLOs, and the Four Golden Signals

Version Note

Sections 11.1 and 11.2 of this guide cover cost governance and operational excellence for both exam versions. This section adds the material the exam guide effective August 12, 2026 names explicitly and the current guide does not: the Google Cloud Observability product list, the four golden signals, and SLIs, SLOs, and SLAs as a stated topic. It also flags what the updated guide drops.

Removed from Domain 6 on the updated exam: sustainability in its entirety (Section 11.3), and Google Cloud Customer Care with the life of a support case. If your exam is on or after August 12, skip both.

Google Cloud Observability

The product family previously known as the Google Cloud operations suite - and before that as Stackdriver - is now Google Cloud Observability. The updated guide asks you to recognise its members and what each is for.

The pairing most often confused is Trace versus Profiler. Trace works between services and tells you which hop is slow; Profiler works inside one service and tells you which function is slow. A request taking two seconds where the payments call accounts for 1.8 of them is a Trace finding; discovering that the payments service spends that time in a JSON serialisation routine is a Profiler finding.

Observability versus monitoring is worth stating cleanly, because the updated guide uses both words. Monitoring answers questions you knew to ask in advance, because you configured a dashboard or an alert for them. Observability is the property of a system whose internal state you can infer from its outputs well enough to answer questions you had not anticipated. Monitoring catches the failure you predicted; observability lets you diagnose the one you did not.

The Four Golden Signals

The updated guide asks how "a system's performance and reliability are measured" and names four signals. They come from Google's own site reliability engineering practice, and the claim behind them is strong: if you can measure only four things about a user-facing system, measure these.

Two properties make the set useful together. Latency must be split by success and failure - fast failures can otherwise flatter your latency numbers, because errors often return quickly. And saturation is the one that buys you time: latency and errors tell you that users are already suffering, whereas saturation tells you they are about to. A team that alerts only on errors is always responding to an incident that has already started.

SLIs, SLOs, and SLAs

The updated guide makes the reliability ladder an explicit topic. The three terms form a hierarchy from measurement to promise.

The SLA is always looser than the SLO, and the reason is the whole point of the structure: the gap is the safety margin. If you promise customers 99.5% and target 99.9% internally, you can miss your internal target and still honour the contract. A team that sets its SLO equal to its SLA has no room to be wrong.

The error budget follows directly from the SLO. A 99.9% availability objective over a 30-day month allows 0.1% of roughly 43,200 minutes, which is about 43 minutes of unavailability. That budget is a resource with a legitimate use: as long as it is unspent, the team is entitled to ship changes and accept risk. When it is exhausted, feature work pauses in favour of reliability work. This is what turns reliability from an argument into an agreed decision rule.

A common exam distinction: an SLO is a target, not a guarantee, and an SLA is a contract, not a measurement. If a scenario mentions financial credits or penalties, it is describing an SLA.

Designing Resilient Infrastructure

The updated guide names four building blocks for resilient infrastructure and processes.

• Redundancy — more than one instance of every critical component, so losing one does not lose the service. Redundancy only helps if the copies fail independently; two instances on the same host are not redundant in any useful sense.
• Replication — keeping copies of data in more than one place, whether across zones for high availability or across regions for disaster recovery. The tradeoff is between synchronous replication, which protects data at the cost of latency, and asynchronous, which is faster but can lose recent writes.
• Scalable infrastructure — autoscaling and load balancing so demand spikes are absorbed rather than becoming outages. Scalability is a reliability property, not only a cost one: an under-provisioned system fails under load exactly like a broken one.
• Backups — the last line of defence, and the one most often assumed rather than verified. A backup that has never been restored is a hypothesis. Backups also protect against classes of failure that replication does not: replication faithfully copies a deletion or a corruption to every replica, whereas a point-in-time backup lets you go back to before it happened.

Availability targets and what they cost. Each additional nine multiplies engineering effort and spend, which is why matching the target to the business value of the service is a leadership decision rather than an engineering default.

The exam's framing: not every service deserves five nines. An internal reporting tool that is unavailable for an hour costs nothing; a payments API that is unavailable for an hour may cost the quarter. The discipline is choosing deliberately and paying for what you chose.