PCDOE SRE/SLO Patterns: Error Budgets in Practice (2026)

Q: What is the difference between SLI, SLO, and SLA?

SLI is the measured value (e.g., 99.95% success rate), SLO is the internal target (e.g., maintain 99.9%), and SLA is the customer contract (e.g., refund if it falls below 99.5%). The standard rule is SLA < SLO < 100%.

Q: What is an Error Budget?

The upper limit of failure allowed by the SLO (e.g., a 99.9% SLO allows 0.1% = 43 minutes of downtime per month). The policy is that new feature releases are OK until the budget is exhausted, and then frozen once it is exceeded.

Q: What is a Burn Rate alert?

The consumption rate of the Error Budget. For example, consuming 2% of the monthly budget in 1 hour equals a 14.4x burn. The recommended pattern is two-tier alerts: Fast burn and Slow burn.

Q: How do you choose SLIs?

Metrics directly tied to user experience — Availability (success rate), Latency (e.g., P99), Throughput, and Correctness. Templates exist for request-driven, event-driven, and data pipeline services.

Q: What can you do with the Cloud Monitoring SLO feature?

It provides a managed flow from SLI definition → SLO calculation → Error Budget visualization → Burn Rate alerts. Custom Metric, Distribution, and Log-based SLIs are also supported.

Q: What are the tips for reducing Toil?

Quantify repetitive, automatable, operationally burdensome tasks (e.g., X hours per week), automate them with Cloud Build / Workflows / Cloud Functions, and keep Toil below 50% of the SRE team's time as a guideline.

Q: How should a Postmortem be written?

Structure it as Blameless (no blame on individuals), Timeline, Impact, Root Cause, What went well, What went poorly, and Action items. Google publishes a template at sre.google.

Q: What SRE tools appear frequently on the PCDOE exam?

Cloud Monitoring (SLO / Alerting), Cloud Logging (Log-based metrics), Managed Service for Prometheus, Cloud Trace, Cloud Profiler, Error Reporting, and Incident Response (PagerDuty integration).

We take a deep dive into the Site Reliability Engineering (SRE) domain at the heart of the PCDOE exam, tied to a Cloud Monitoring implementation. From the theory of SLI / SLO / Error Budget to Burn Rate alerts, Toil reduction, and Blameless Postmortems, everything is covered.

The SLI / SLO / SLA Hierarchy

Concept	Definition	Example
SLI (Service Level Indicator)	Measured metric	HTTP 200 rate, P99 latency
SLO (Service Level Objective)	Internal target	Maintain SLI at 99.9%
SLA (Service Level Agreement)	Customer contract	10% refund if below 99.5%

How to Choose SLIs

Service Type	Recommended SLI
Request-driven (Web/API)	Availability (success rate), Latency (P95/P99)
Pipeline (batch/streaming)	Correctness, Coverage, Freshness
Storage	Durability, Throughput
Event-driven	End-to-end latency, Loss rate

Error Budget Calculation Examples

SLO 99.9% / 30 days = Error Budget 0.1% = 30 × 24 × 60 × 0.001 = 43.2 minutes
SLO 99.95% / 30 days = 21.6 minutes
SLO 99.99% / 30 days = 4.3 minutes

Burn Rate Alerts (Multi-window Multi-burn-rate)

Tier	Burn Rate	Consumption	Use Case
Fast burn	14.4x	2% of monthly budget in 1 hour	Immediate PagerDuty (critical incident)
Slow burn	1x	Budget consumed over a long period	Next business day response (trend degradation)

In Cloud Monitoring SLO alerts, the best practice is to combine Lookback windows (1h / 6h / 24h / 3d) with Threshold (Burn rate) to configure two-tier Fast / Slow notifications.

Cloud Monitoring SLO Configuration Steps

Define a Service (Cloud Run / GKE / custom Service)
Choose an SLI: Availability / Latency / Custom Metric
Define Good event / Total event (e.g., exclude HTTP 5xx)
Set the SLO Target (e.g., 99.9%) and Compliance Period (Rolling 28 days)
Create Burn Rate alerts for Fast (14.4x, 1h) and Slow (1x, 24h)
Notification channels: PagerDuty / Slack / Email / Webhook

Toil Reduction Approach

Log recurring repetitive work in a "Toil log" (weekly aggregation)
Score automation candidates: frequency × time × importance
Automate with Cloud Functions / Workflows / Cloud Scheduler
Move to GitOps with Anthos Config Management
Keep the SRE team's Toil ratio below 50%

Blameless Postmortem Template

Summary: 1-2 lines
Impact: downtime, number of affected users, Error Budget consumed
Timeline: chronology from detection → mitigation → resolution
Root Cause: technical cause + systemic cause
What went well: monitoring, rollback, etc.
What went poorly: detection delays, misinformation, etc.
Where we got lucky: factors that happened to save us
Action items: tasks with owners and deadlines

Common Trick Questions

SLA < SLO: the iron rule is to set an internal target (SLO) stricter than the customer contract (SLA)
SLI = user experience: use request success rate/latency instead of CPU utilization
Error Budget Policy: when exhausted, freeze new feature releases = requires prior agreement with the business side
Cloud Monitoring SLO feature: Log-based Metrics can also be specified as Custom SLIs

What is the difference between SLI, SLO, and SLA?

SLI is the measured value (e.g., 99.95% success rate), SLO is the internal target (e.g., maintain 99.9%), and SLA is the customer contract (e.g., refund if it falls below 99.5%). The standard rule is SLA < SLO < 100%.

What is an Error Budget?

The upper limit of failure allowed by the SLO (e.g., a 99.9% SLO allows 0.1% = 43 minutes of downtime per month). The policy is that new feature releases are OK until the budget is exhausted, and then frozen once it is exceeded.

What is a Burn Rate alert?

The consumption rate of the Error Budget. For example, consuming 2% of the monthly budget in 1 hour equals a 14.4x burn. The recommended pattern is two-tier alerts: Fast burn and Slow burn.

How do you choose SLIs?

Metrics directly tied to user experience — Availability (success rate), Latency (e.g., P99), Throughput, and Correctness. Templates exist for request-driven, event-driven, and data pipeline services.

What can you do with the Cloud Monitoring SLO feature?

It provides a managed flow from SLI definition → SLO calculation → Error Budget visualization → Burn Rate alerts. Custom Metric, Distribution, and Log-based SLIs are also supported.

What are the tips for reducing Toil?

Quantify repetitive, automatable, operationally burdensome tasks (e.g., X hours per week), automate them with Cloud Build / Workflows / Cloud Functions, and keep Toil below 50% of the SRE team's time as a guideline.

How should a Postmortem be written?

Structure it as Blameless (no blame on individuals), Timeline, Impact, Root Cause, What went well, What went poorly, and Action items. Google publishes a template at sre.google.

What SRE tools appear frequently on the PCDOE exam?

Cloud Monitoring (SLO / Alerting), Cloud Logging (Log-based metrics), Managed Service for Prometheus, Cloud Trace, Cloud Profiler, Error Reporting, and Incident Response (PagerDuty integration).

Check what you learned with practice questions

Practice with certification-focused question sets

View GCP Exam Prep Page

Author

NicheeLab Editorial Team

NicheeLab editorial team focused on data engineering and cloud certification learning. Content is structured around practical study needs and official exam domains.

GCP PCDOE Exam Prep: Complete Guide to SRE / SLI / SLO / Error Budget Patterns