In the August 2026 revision of the Cloud Digital Leader exam guide, Domain 6, "Scaling with Google Cloud Operations," dropped to about 10%, but it gained many new detailed items. It asks how to measure a system's performance and reliability through latency, traffic, saturation, and errors; how to design for resilience with redundancy, replication, scalable infrastructure, and backups; Google Cloud Observability from Cloud Monitoring to Cloud Profiler; and, on the cost side, quota policies, budget threshold rules, Cloud Billing reports, Dynamic Workload Scheduler, and the role of people, process, and technology.
This post starts with the basic operations terms, then covers the four golden signals, SLI, SLO, and SLA with error budgets, designing for resilience, the observability tools, and the controls and FinOps practices that keep costs in check. The basic definitions of SLI, SLO, and SLA, DevOps, and budgets and committed use discounts are covered first in Cost Management and Operational Excellence.
---
Basic Operations Terms: Operational Excellence, Reliability, High Availability
The exam guide asks you to recognize the fundamental cloud operations terms. The three sound similar but focus on different things.
| Term | Meaning | Example | |------|------|------| | Operational excellence | The ability to run systems efficiently and keep improving them | Deployment automation, monitoring, improvements after incidents | | Reliability | How consistently a system behaves as expected | Users get the correct result every time they make a request | | High availability | The ability to keep serving even when failures occur, usually expressed as a percentage of uptime | The service continues in other zones when one zone goes down |
Each extra 9 in an availability figure cuts the allowed downtime to a tenth.
| Availability | Allowed downtime per month (approx.) | |------|------| | 99% | 7 hours 18 minutes | | 99.9% | 43 minutes 50 seconds | | 99.99% | 4 minutes 23 seconds | | 99.999% | 26 seconds |
Exam tip: The higher the availability target, the higher the cost and complexity. Not every service needs 99.999%; setting a target that fits the business is part of operational excellence.
---
The Four Golden Signals: What to Measure
You cannot put hundreds of gauges on a car's dashboard. Drivers look at the essentials: speed, fuel, and engine temperature. Google's SRE practice says that if you can only measure four metrics of a user-facing service, focus on latency, traffic, errors, and saturation. The exam guide also lists these four as the way to measure a system's performance and reliability.
!The four golden signals, latency, traffic, errors, and saturation, measured as SLIs and compared against SLOs
| Signal | What it looks at | Example | |------|------|------| | Latency | The time it takes to serve a request | 95% of payment requests answered within 300 milliseconds | | Traffic | How much demand is coming into the system | Requests per second, concurrent users | | Errors | The rate of failed requests | Rate of server error (5xx) responses, incorrect results | | Saturation | How full the system is | CPU, memory, disk, and queue utilization |
Saturation is special because it warns you before trouble starts. The other three get worse only after users are already affected, but when saturation approaches its limit you can add capacity before an outage happens.
Exam tip: "The response speed users experience" is latency, "the volume of requests the service receives" is traffic, and "whether resources are close to their limits" is saturation.
---
SLI, SLO, SLA, and Error Budgets
SLI, SLO, and SLA are the tools that turn the golden signals into numbers you can manage. The order is measure, set a target, and make a promise to customers.
| Term | Role | Example | |------|------|------| | SLI (service level indicator) | The value actually measured | 99.95% of requests succeeded this month | | SLO (service level objective) | The internal target the team sets | At least 99.9% of requests succeed over a month | | SLA (service level agreement) | The contractual promise to customers, with compensation if broken | Below 99.5%, part of the fee is returned as credits |
The SLO is set stricter than the SLA. That leaves a buffer so you can still keep the promise to customers even if you miss the internal target slightly.
Error Budget: How Much Failure Is Allowed
The error budget is 100% minus the SLO. If the SLO is 99.9%, the error budget is 0.1%, which means about 43 minutes of downtime a month, or 1,000 failures out of a million requests, are allowed.
If budget remains: go ahead with risky changes such as new feature releases and experiments If the budget runs out: stop new releases and focus on improving stability
This lets a development team that wants to "ship fast" and an operations team that says "stability first" agree based on data instead of gut feeling. SRE pairs this with blameless postmortems, which focus on causes and fixes instead of blaming people for incidents, and with the principle of automating away repetitive manual work.
Exam tip: If "the error budget is exhausted," the right answer is to stop releasing new features and focus on improving reliability. If asked "what is the error budget when the SLO is 99.9%?", the answer is 0.1%.
---
Designing Resilient Infrastructure and Processes
An airplane has two or more engines so it can keep flying if one stops. The exam guide lists redundancy, replication, scalable infrastructure, and backups as the ways to design for resilience.
| Technique | Meaning | Google Cloud examples | |------|------|------| | Redundancy | Several components play the same role so the system keeps working if one stops | Managed instance groups with VMs spread across zones, load balancing | | Replication | Keeping copies of data continuously in sync in other locations | Cloud SQL high availability configuration (a standby instance in another zone), Spanner multi-region, multi-region Cloud Storage | | Scalable infrastructure | Automatically adding and removing resources with the load | Autoscaling, Cloud Run, Cloud Load Balancing | | Backups | Keeping a separate point-in-time copy to recover after mistakes or ransomware | Cloud SQL automated backups, disk snapshots, Backup and DR Service |
Replication and backups are different. Because replication keeps copies in sync in real time, if someone deletes data by mistake, the deletion is replicated too. A backup is a copy from a past point in time, so it lets you roll back from that kind of mistake.
When you plan for disaster recovery, you set two targets first.
| Target | Question | Example | |------|------|------| | RTO (recovery time objective) | How soon after a failure must the service be back? | Recover within 4 hours | | RPO (recovery point objective) | How much data can you afford to lose at most? | Recover data up to the last 15 minutes |
Exam tip: "Roll back data deleted by mistake to yesterday's state" is a backup. "The database keeps running even if a zone stops" is replication with a standby in another zone (a high availability configuration).
---
Google Cloud Observability: Five Tools for Seeing Inside Your Systems
The exam guide asks how to modernize operations with Google Cloud Observability (formerly Stackdriver and the operations suite) and names five tools.
| Tool | What it does | Question it answers | |------|------|------| | Cloud Monitoring | Collects metrics, dashboards, alerts, and uptime checks | Is the system healthy right now? | | Cloud Logging | Collects, stores, searches, and analyzes logs | What happened? | | Cloud Trace | Tracks the latency of each segment as a single request passes through multiple services | Where did it slow down? | | Cloud Profiler | Continuously analyzes, with low overhead, which code uses the most CPU and memory in running applications | Which code uses the most resources? | | Error Reporting | Collects application errors, groups them by type, and alerts on new ones | Which errors are new? |
Cloud Debugger, which you may see in older material, was shut down on May 31, 2023, so it is not on the list anymore.
Exam tip: "Find which segment of the microservices slows down the response" is Cloud Trace, and "find which functions use the most CPU in order to cut costs" is Cloud Profiler.
---
The Other Side of Operations: Controls That Keep Costs in Check
Scaling operations means controlling costs, not just reliability. The exam guide lists quota policies, budget threshold rules, Cloud Billing reports, Dynamic Workload Scheduler, and Spot VMs as ways to control cloud consumption.
| Control | What it does | Does it actually stop usage? | |------|------|------| | Budgets and threshold rules | Alert when actual or forecasted costs pass a set percentage; can trigger automated actions through Pub/Sub | Alerts-only budgets do not (some services support spend cap budgets on a project) | | Quotas | Limit how much of a resource or how many API calls a project can use | Yes; requests beyond the limit fail | | Cloud Billing reports | Visualize cost trends by project, service, and label | No (they provide visibility) | | Spot VMs | Deeply discounted spare capacity that can be reclaimed at any time | Not applicable (cost savings) | | Dynamic Workload Scheduler | Starts GPUs and TPUs when capacity frees up, or reserves them for set dates | Not applicable (cost savings) |
People, Process, and Technology: Who Manages Cloud Costs?
On-premises, the finance team approved a hardware purchase once and that was it; in the cloud, engineers create costs with a single click. That is why Google describes financial governance along three axes: people, process, and technology.
People: cost is a shared responsibility of finance, engineering, and the business, not the finance team alone, with a central team (a FinOps team) coordinating it Process: sett