Overview
Site reliability engineering began at Google, and this section tests whether you apply it the way Google teaches it. You define service level indicators such as availability and latency, set service level objectives against them, and keep both separate from contractual SLAs. Error budgets, including SLOs defined for Cloud Service Mesh services, decide when to keep shipping and when to slow down, and every added nine of reliability has a cost.
The section also covers the full service lifecycle from planning through deployment, maintenance and retirement. Capacity planning uses quotas, limits, reservations and Dynamic Workload Scheduler, while autoscaling covers managed instance groups, Cloud Run and GKE. Finally, incident mitigation asks how to protect users quickly: drain or redirect traffic, add capacity or roll back.
How it's tested
Section 3 questions usually present a service owner, a set of user complaints or metrics, and a decision about targets, capacity or incident response. The right answer follows Google SRE principles: measure what users experience, set realistic targets, spend the budget deliberately and restore service before investigating.
-
Pick the right SLI
You choose an indicator that reflects user experience, such as the ratio of successful requests at the load balancer, over internal signals like CPU.
-
Act on the error budget
Given budget consumption, you decide whether to continue releases, freeze features, or invest in reliability work.
-
Mitigate first
During an outage you choose the fastest action that reduces user harm, such as rollback or traffic drain, before root cause analysis.
A checkout service has a 99.9% monthly availability SLO and has already used 90% of its error budget halfway through the month. The product team wants to ship a large feature. SRE practice says the remaining budget cannot absorb much more risk, so the team should pause risky launches and prioritize reliability fixes until the budget recovers, as agreed in the error budget policy.
Objectives 3
Official objectives from the Google Cloud outline, in outline order.
3.1 Balancing change, velocity, and reliability of the serviceSLIs, SLOs, SLAs, error budgets and the opportunity cost of reliability.
- What it means
- This covers defining SLIs such as availability and latency, setting SLOs and understanding SLAs, managing error budgets including SLO definitions for Cloud Service Mesh, and weighing the opportunity cost of risk and reliability targets, often expressed as the number of nines.
- What to understand
- An SLI is a measured ratio of good events to valid events. An SLO is the internal target for that SLI over a window, and an SLA is an external commitment with consequences, normally looser than the SLO. The error budget is one minus the SLO, so 99.9% allows 0.1% failures. Each extra nine cuts allowed downtime by about ten times and costs far more to achieve. Cloud Monitoring can define SLOs on services, including Cloud Service Mesh services, and alert on burn rate.
- How it shows up
- Expect calculations of allowed downtime, choices of a user-facing SLI and decisions driven by budget consumption.
- Common confusion
- The SLA is not the internal target; set the SLO stricter so you notice problems before breaching the contract.
3.2 Managing service lifecyclePlanning to retirement, capacity planning and autoscaling.
- What it means
- This covers managing a service through planning, deployment, maintenance and retirement; planning capacity with quotas, limits, reservations and Dynamic Workload Scheduler; and configuring autoscaling for managed instance groups, Cloud Run and GKE.
- What to understand
- Production readiness reviews check monitoring, runbooks and capacity before launch, and retirement needs a plan to migrate users and remove resources. Quotas cap usage per project and region, so increases should be requested before a launch. Reservations guarantee zonal Compute Engine capacity, and Dynamic Workload Scheduler helps obtain scarce accelerators. Managed instance groups scale on CPU, load balancing or custom metrics; Cloud Run scales on concurrency; GKE uses the Horizontal Pod Autoscaler and cluster autoscaler.
- How it shows up
- A launch or traffic spike is described, and you choose quotas, reservations or the autoscaling setting that prevents failure.
- Common confusion
- Autoscaling cannot add capacity beyond quota or regional availability; reservations and quota requests come first.
3.3 Mitigating incident impact on usersDraining or redirecting traffic, adding capacity and rolling back.
- What it means
- This covers reducing harm to users during an incident by draining or redirecting traffic away from unhealthy resources, adding capacity, and applying rollback strategies.
- What to understand
- The first goal in an incident is to stop or limit user impact; root cause comes later in a blameless postmortem. If a new release is the likely cause, roll back. If one zone or region is unhealthy, drain it or shift load balancer traffic elsewhere. If load exceeds capacity, scale out or raise limits. Clear incident roles such as incident commander and communications lead keep the response organized.
- How it shows up
- Expect an outage scenario where several answers would help eventually, and you must pick the fastest safe mitigation.
- Common confusion
- Debugging in production may find the cause, but rolling back restores service sooner.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
SLI
A ratio of good events to valid events that users would notice.
- Remember
- Measure close to the user, such as at the load balancer.
- Tested as
- SLI selection questions.
- Trap
- Using CPU or memory as an SLI.
-
SLO
Target value for an SLI over a time window.
- Remember
- Stricter than the SLA.
- Tested as
- Target setting.
- Trap
- Setting it at 100%.
-
SLA
Contractual promise with penalties if missed.
- Remember
- Owned by the business, looser than the SLO.
- Tested as
- Distinguishing targets from contracts.
- Trap
- Treating the SLA as the alerting target.
-
Error budget
Allowed unreliability equal to one minus the SLO.
- Remember
- 99.9% over 30 days is about 43 minutes.
- Tested as
- Release and freeze decisions.
- Trap
- Thinking unused budget is wasted effort.
-
Error budget policy
Agreed actions when the budget is exhausted.
- Remember
- Usually a freeze on risky launches.
- Tested as
- Governance scenarios.
- Trap
- Ignoring the policy to meet a deadline.
-
Burn rate
How fast the error budget is being consumed relative to the window.
- Remember
- Fast burn pages, slow burn tickets.
- Tested as
- SLO alerting.
- Trap
- Alerting on every single error.
-
Cost of nines
Each added nine reduces allowed downtime about tenfold.
- Remember
- Higher reliability costs more and slows releases.
- Tested as
- Opportunity cost questions.
- Trap
- Assuming more nines is always better.
-
Quotas
Per-project and per-region limits on resources.
- Remember
- Request increases ahead of launches.
- Tested as
- Capacity planning.
- Trap
- Relying on autoscaling past quota.
-
Reservations
Zonal Compute Engine capacity held for your project.
- Remember
- You pay while reserved even if idle.
- Tested as
- Securing capacity for planned events.
- Trap
- Confusing them with committed use discounts.
-
Autoscaling
Automatic scaling for MIGs, Cloud Run and GKE.
- Remember
- Pick the signal: CPU, requests, concurrency or custom metric.
- Tested as
- Lifecycle and traffic spikes.
- Trap
- Scaling on a metric that lags demand.
-
Mitigation before root cause
Restore service first, investigate later.
- Remember
- Rollback and traffic shifting are fast mitigations.
- Tested as
- Incident response.
- Trap
- Debugging live while users fail.
-
Blameless postmortem
Review focused on systems and processes, not individuals.
- Remember
- Produce action items with owners.
- Tested as
- Post-incident questions.
- Trap
- Assigning personal blame.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
SLI, SLO and SLA
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SLI | The measurement, such as the percentage of successful requests. | A number describing current behavior. | Picking a signal users cannot feel. |
| SLO | The internal target for the SLI, such as 99.9% over 28 days. | Drives the error budget and alerts. | Making it equal to the SLA leaves no warning margin. |
| SLA | An external agreement with financial or service credits. | Has business consequences when missed. | Engineering teams do not alert directly on SLA terms. |
Capacity tools
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Quota increase | Raises the per-project or per-region limit. | Permission to use more, not reserved hardware. | Requested too late before a launch. |
| Reservation | Holds specific zonal VM capacity. | Guarantees availability; billed while held. | Confused with a discount commitment. |
| Dynamic Workload Scheduler | Schedules access to scarce accelerators such as GPUs. | Helps obtain hard-to-get capacity for batch or training jobs. | Treated as general web autoscaling. |
| Autoscaling | Adds and removes instances or Pods automatically. | Reacts to demand within available capacity. | Expected to work beyond quota. |
Incident mitigation options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Rollback | Return to the last known good release. | Fastest when a change caused the problem. | Skipped in favor of a forward fix. |
| Drain or redirect traffic | Move users away from a failing zone, region or backend. | Isolates a localized failure. | Used when every location is equally affected. |
| Add capacity | Scale out or raise limits. | Fits overload rather than defects. | Used for a bug that fails every request. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Chasing more nines
- What candidates pick
- Raise the SLO from 99.9% to 99.99% after one incident.
- Why it looks right
- Higher targets sound more responsible.
- Why it's wrong
- A tighter SLO costs much more and slows releases; the target should match what users need.
Clue to watch for Users are satisfied and the business has not asked for more.
-
Alert on every error
- What candidates pick
- Page on-call whenever the error rate rises above zero.
- Why it looks right
- It catches every problem quickly.
- Why it's wrong
- Paging on single errors causes alert fatigue; burn-rate alerts page only when the budget is at real risk.
Clue to watch for Mentions of noisy alerts or on-call fatigue.
-
Fix forward in an outage
- What candidates pick
- Debug the new release and push a hotfix.
- Why it looks right
- It fixes the real cause.
- Why it's wrong
- Rollback restores users faster; investigation can follow once impact has stopped.
Clue to watch for A deployment shortly before the errors began.
-
SLA as alert threshold
- What candidates pick
- Alert when availability drops below the SLA.
- Why it looks right
- The SLA is the number that matters to customers.
- Why it's wrong
- By then the contract is already breached; alert on SLO burn so there is time to act.
Clue to watch for Both an SLO and an SLA are given.
-
Ignoring the budget policy
- What candidates pick
- Approve the launch because the deadline is fixed.
- Why it looks right
- Business pressure feels decisive.
- Why it's wrong
- An exhausted error budget means the agreed policy should pause risky changes until reliability improves.
Clue to watch for Budget spent early in the window.
-
Autoscale past limits
- What candidates pick
- Increase the autoscaler maximum for a planned event.
- Why it looks right
- Autoscaling handles demand.
- Why it's wrong
- Without enough quota or zonal capacity, new instances fail to start; request quota and reserve capacity first.
Clue to watch for A known, large, dated traffic event.
Answer framework
Work through these steps when a question involves reliability targets, capacity or an active incident.
- Ask what users experience and choose an SLI measured close to them, such as successful requests or latency at the load balancer.
- Set or check the SLO and compute the error budget, remembering that the SLA should be looser than the SLO.
- Read budget consumption to decide between continuing releases, slowing down or freezing risky launches under the error budget policy.
- For planned growth, confirm quotas, reservations and accelerator capacity, then tune autoscaling signals for MIGs, Cloud Run or GKE.
- During an incident, pick the quickest mitigation that limits harm, such as rollback, traffic drain or added capacity, and investigate afterwards.
Practice question
Want more like this? The GCP PCDOE practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Read the core chapters of Google's free SRE books on SLOs, error budgets, alerting on SLOs and managing incidents. They shape how questions are written, and the vocabulary in answer options comes straight from them. Practice the arithmetic until it is quick: allowed downtime for 99%, 99.9% and 99.95% over 30 days, and what a fast burn rate means for time to exhaustion.
Then make the ideas concrete in Cloud Monitoring. Define a service, create an availability SLO and a latency SLO, and add burn-rate alerts. Configure autoscaling on a managed instance group, a Cloud Run service and a GKE deployment, and note which signal each uses. Review quotas and reservations for a pretend launch. For incident questions, rehearse a simple rule: stop the bleeding first, then find the cause. Practice questions in this section reward calm, principle-driven choices, so review each wrong answer and name the SRE principle it ignored before moving on.
FAQ
How much of the GCP PCDOE exam is Applying site reliability engineering practices?
Google weights Section 3, Applying site reliability engineering practices, at about 18%. That is roughly 9 to 11 questions on a 50-60 question exam, as an editorial estimate.
Do I need to calculate error budgets on the exam?
Expect simple arithmetic, such as converting an SLO into allowed minutes of downtime for a month, or judging how much budget remains. Memorize the common values.
Should I read the Google SRE books?
Yes. The exam follows the principles in Site Reliability Engineering and The Site Reliability Workbook, especially chapters on SLOs, alerting, incident response and postmortems.
What is Dynamic Workload Scheduler and why is it listed?
It is a Google Cloud capability for obtaining scarce accelerator capacity such as GPUs for batch and training jobs. The guide lists it under capacity planning alongside quotas and reservations.
Where do SLOs live in Google Cloud?
Cloud Monitoring lets you define services, attach SLOs to them and create burn-rate alerting policies. It supports services such as GKE, Cloud Run, App Engine, Cloud Service Mesh and custom services.
Is a postmortem part of mitigation?
No. Mitigation restores service; the blameless postmortem happens afterwards to find contributing causes and create action items.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
Try scenario questions on SLOs, error budgets, capacity and incident mitigation to see whether you reason the way Google's SRE practice expects.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the GCP PCDOE AI tutor Get any concept explained your way