What's changed: Created Professional Cloud Architect Chapter 6 (Domain 4 "Analyze and optimize": cost optimization and business alignment = billing/budget alerts (notify-only)/CUD/Spot/Active Assist/lifecycle/label allocation/KPI alignment; technical process optimization = SRE (SLI/SLO/error budget)/CI-CD (Cloud Build/Cloud Deploy)/deployment strategies (canary/blue-green/rollback)/incident response/postmortems).
6.2Optimizing technical processes (SRE, CI/CD, change management)
Understand site reliability engineering operations (SLIs/SLOs/error budgets), safe delivery via CI/CD with deployment strategies (canary, blue/green, rollback), incident response and postmortems, and optimizing cross-team collaboration and decision-making.
A great architecture delivers value only when run by great processes. Balance reliability and change velocity through SRE and CI/CD practices.
6.2.1SRE and reliability operations
Site reliability engineering (SRE) manages reliability with measurable targets: SLIs (metrics of user experience), their target SLOs, and the allowed deviation error budget. With budget remaining, ship changes aggressively; when nearly exhausted, throttle changes and prioritize stability. This quantifies the "velocity vs reliability" tradeoff. Map "user-facing target = SLO" and "allowed deviation = error budget."
6.2.2CI/CD and deployment strategies
Automate safe delivery with CI/CD (build/test in Cloud Build, release with Cloud Deploy). Risk-limiting deployment strategies include canary (release to a subset first), blue/green (switch between old/new environments), and rollback (revert quickly on issues). When incidents occur, limit impact via incident response, then prevent recurrence with a postmortem (blameless analysis). Map "gradual rollout = canary," "instant revert = rollback," and "prevent recurrence = postmortem."
Common: requirement → means. E.g., "quantify reliability while keeping velocity" = SLO/error budget; "validate with a subset first" = canary; "instant old/new switch" = blue/green; "revert on issues" = rollback; "automate build/test" = Cloud Build; "recurrence-preventing analysis" = blameless postmortem.
Watch the mix-ups: (1) Do not confuse SLI (metric)/SLO (target)/SLA (contract). (2) Canary and blue/green differ (gradual rollout vs instant switch). (3) Postmortems aim at improving systems, not blame.
Architects also work with related services: API management is Apigee (publish/auth/rate-limit/analytics); secure access to internal apps is Identity-Aware Proxy (identity-based access without a VPN); private reachability to managed services is Private Service Connect; assessing workloads for migration to Google Cloud is Migration Center. For AI, use the model catalog Model Garden, the multimodal Gemini, and Vertex AI Agent Builder; for operations, the authenticated Cloud Shell.
6.2.3Section summary
- SRE = SLIs/SLOs/error budgets quantify the reliability-vs-velocity tradeoff
- CI/CD (Cloud Build/Cloud Deploy) + deployment strategies (canary/blue-green/rollback)
- Limit impact via incident response; prevent recurrence with blameless postmortems
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To quantitatively manage reliability and balance it with change velocity, which concept?
Q2. To release a new version to a subset of users first and observe, which deployment strategy?
Q3. To quickly revert a problematic deployment to the previous state, which best fits?
Q4. Which CI service automates build and test?
Q5. What is the best way to conduct a postmortem to prevent recurrence?
Q6. Which correctly contrasts SLI, SLO, and SLA?
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.