Ensuring solution and operations excellence · Topic 2 of 3
Release Management and Supporting Deployed Solutions
Managing releases with progressive delivery, rollback and maintenance controls, and supporting live solutions through incidents and support.
- 4 min
- Progressive delivery with automated verification and fast rollback.
- Error budget policies tie release pace to reliability.
- Use maintenance windows and exclusions around business-critical periods.
What it is
Release management decides how and when changes reach production so that they are safe, reversible and coordinated with the business. Supporting deployed solutions means keeping them healthy afterwards: responding to incidents, maintaining platforms, working with Google Cloud support and learning from what goes wrong.
How it works
Release management practices
| Practice | Google Cloud mechanism |
|---|---|
| Progressive delivery | Cloud Deploy canary and phased rollouts; Cloud Run traffic splits; MIG canary updates |
| Automated verification | Cloud Deploy verification steps, SLO checks before promotion |
| Approvals where required | Cloud Deploy approval on production targets |
| Fast rollback | Roll back a Cloud Deploy release; shift Cloud Run traffic to the previous revision; GKE rollout undo |
| Release calendars and freezes | Error budget policies; maintenance exclusions during busy periods |
| Audit trail | Cloud Deploy history and audit logs |
Error budget policies link release pace to reliability: while budget remains, teams ship; when it is spent, feature releases pause and reliability work takes priority. This avoids a change advisory board while still protecting users.
When leadership wants to tie release speed to reliability without adding an approval board, the answer is an SLO with an error budget policy.
Managing platform maintenance
| Platform | Controls |
|---|---|
| GKE | Release channels, maintenance windows and exclusions, surge or blue-green node upgrades |
| Cloud SQL | Maintenance windows, deny maintenance periods, maintenance notifications |
| Compute Engine | Live migration for host maintenance on most VMs, MIG rolling updates for image changes |
Plan maintenance around the business calendar: a healthcare enrollment period or a retail sale is not the time for upgrades.
Supporting deployed solutions
Incident response:
- Detect through SLO alerts and paging.
- Assign roles: incident commander, communications, operations.
- Mitigate first (roll back, fail over, scale), diagnose second.
- Communicate status to stakeholders.
- Hold a blameless postmortem with owned, tracked action items.
Runbooks and automation: document routine fixes, then automate the common ones (for example a failed batch rerun started automatically from a Pub/Sub message through Eventarc and Workflows, recorded for audit).
Security incidents follow the same discipline with evidence preservation: disable compromised credentials, isolate affected resources, snapshot disks for investigators, then remediate.
Working with Google Cloud support
| Option | Use |
|---|---|
| Customer Care plans (several levels) | Faster response targets and technical help for production issues |
| Service Health and status dashboards | See Google Cloud incidents affecting your projects |
| Personalized Service Health notifications | Alerts about incidents relevant to your resources |
| Access Approval and Access Transparency | Control and record support staff access to content |
A worked scenario
Each night failed batches are rerun by hand from a wiki page, which twice caused duplicate loads. A failure message already goes to a Pub/Sub topic. An Eventarc trigger on that topic starts a Workflows execution that reruns only the batch named in the message, within minutes and with each execution recorded. Paging a human or rerunning the last 24 hours on a schedule does not meet the requirements.
How the exam asks about this
- "Upgrade the node pool now, keep old nodes for a soak period to roll back." Blue-green node pool upgrade.
- "Release pace must follow reliability without an approval board." Error budget policy.
- "Service account calls APIs from an unfamiliar address; stop access and keep evidence." Disable the account, isolate the VM, snapshot disks.
What to remember for the exam
- Progressive delivery with automated verification and fast rollback.
- Error budget policies tie release pace to reliability.
- Use maintenance windows and exclusions around business-critical periods.
- Incidents: mitigate first, communicate, postmortem with tracked actions.
- Automate routine runbook steps with event-driven workflows.
Deleting compromised resources destroys the evidence investigators need. Isolate and snapshot first.
Common mistakes
Fixing forward during an outage when a rollback would restore service faster.
Change advisory boards as the default answer for release risk.
Upgrades during peak business periods.
Check yourself
What does an error budget policy do when the budget is spent?
It pauses feature releases until reliability recovers.
How do you return a Cloud Run service to the previous version quickly?
Shift traffic back to the previous revision.
What should come first in responding to a compromised service account?
Disable the account and isolate the resource while preserving evidence such as disk snapshots.
Topic 2 of 3 in Ensuring solution and operations excellence
Test yourself on Ensuring solution and operations excellence
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.