What's changed: Created Professional Cloud DevOps Engineer Chapter 3 (Domain 3 "SRE": SLI/SLO/SLA, error budgets, nines vs cost/opportunity cost; service lifecycle, capacity planning = quotas/limits/reservations/Dynamic Workload Scheduler, autoscaling = MIG/Cloud Run/GKE, incident mitigation = drain/redirect/add capacity/rollback).
3.2Service lifecycle, capacity planning, and incident mitigation
Understand service lifecycle management (plan/deploy/maintain/retire), capacity planning (quotas, limits, reservations, Dynamic Workload Scheduler), autoscaling (managed instance groups, Cloud Run, GKE), and mitigating incident impact on users (draining/redirecting traffic, adding capacity, rollback).
Reliability is upheld in operations: manage services from planning to retirement, match capacity to demand, and quickly shrink user impact during incidents.
3.2.1Lifecycle, capacity planning, and autoscaling
Manage services through the plan→deploy→maintain→retire lifecycle. For capacity, know your quotas/limits; for guaranteed capacity use reservations, and use Dynamic Workload Scheduler to schedule scarce resources like GPUs/TPUs. Handle demand with autoscaling: VM fleets via managed instance groups (MIG), serverless via Cloud Run, containers via GKE (HPA/cluster autoscaler). Map "guaranteed capacity = reservations" and "auto-scale VMs = MIG."
3.2.2Mitigating incident impact on users
During incidents, prioritize mitigating user impact first (root-causing happens in parallel/after). Concretely: drain/redirect traffic away from unhealthy targets (load balancer/Cloud Service Mesh), add capacity if saturated, and roll back if a bad change caused it. After mitigation, do permanent fixes and a blameless postmortem. Map "stop the bleeding first (mitigate impact)" and "bad change → rollback."
Common: requirement → means. E.g., "guarantee capacity" = reservations; "schedule GPU/TPU capacity" = Dynamic Workload Scheduler; "auto-scale a VM fleet" = MIG; "serverless autoscale" = Cloud Run; "move traffic off unhealthy targets" = drain/redirect; "bad change caused it" = rollback.
Watch the mix-ups: (1) In incidents, mitigate user impact before root-causing. (2) Quotas/limits (default caps) vs reservations (pre-secured capacity) differ. (3) Pick autoscaling by target: MIG (VMs)/Cloud Run (serverless)/GKE (containers).
3.2.3Section summary
- Manage services plan→deploy→maintain→retire; capacity via quotas/limits/reservations/Dynamic Workload Scheduler
- Autoscaling = MIG (VMs)/Cloud Run (serverless)/GKE (containers)
- In incidents, mitigate first (drain/redirect, add capacity, rollback); then permanent fixes and a blameless postmortem
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To automatically scale a group of VMs with demand, which is best?
Q2. To guarantee capacity of a specific machine type for future demand, which is best?
Q3. An incident occurs in production. As an SRE, what should you do first?
Q4. Errors spiked right after deploying a bad change. What is the best mitigation?
Q5. To schedule capacity acquisition for scarce accelerators like GPUs/TPUs, which is best?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.