Your team is preparing a deployment strategy for a mission-critical checkout microservice hosted on Cloud Run. To adhere to Site Reliability Engineering (SRE) principles and minimize customer impact, your deployment plan must satisfy the following criteria: Deploy updates progressively using canary traffic splitting without exposing all users to new code at once. Monitor real-time telemetry and error budget burn rates during each stage of the rollout. Automatically halt the release and revert 100% of traffic to the previous healthy revision if Service Level Objective (SLO) error budget burn rates exceed acceptable thresholds. Which deployment and release strategy should you implement?

Use Google Cloud Deploy to deliver the new container as a Cloud Run revision using a phased canary rollout strategy with deployment verification, and abandon the release to revert traffic back to the stable revision if SLO burn rate alerts fire.: ### What Google Cloud Deploy Phased Rollouts Provide **Google Cloud Deploy** provides managed, opinionated continuous delivery pipelines that natively integrate with **Cloud Run** and **Google Kubernetes Engine (GKE)**. It supports progressive deployment patterns such as **canary rollouts**, allowing organizations to define automated, multi-phase traffic-shifting progressions across target environments while incorporating automated verification tests. ### How It Meets the Scenario Requirements * **Progressive Traffic Splitting**: Google Cloud Deploy manages Cloud Run revisions and gradually adjusts traffic allocations (such as 1%, 10%, 25%, 50%, to 100%) across distinct phases without requiring manual traffic reconfiguration. * **SLO and Error Budget Governance**: By configuring verification phases alongside **Cloud Monitoring** alert policies that evaluate **error budget burn rates**, teams can measure the reliability impact on real user traffic at each canary percentage. * **Automated Abandon and Rollback**: If an error budget burn rate alert triggers during a canary phase, Google Cloud Deploy allows operators or automated systems to **abandon the release** or promote a rollback target, instantly shifting 100% of live traffic back to the previous stable Cloud Run revision. ### Key Advantages and Capabilities * **Target Management**: Natively supports serverless **Cloud Run targets** alongside containerized GKE clusters with centralized visibility. * **Integrated Verification**: Executes custom validation scripts and post-deployment verification hooks prior to advancing to the next traffic tier. * **Auditability and Control**: Maintains a complete release and rollout audit trail, including configuration comparisons across releases. * **Disaster Mitigation**: Allows teams to suspend pipelines or abandon flawed releases instantly to contain blast radiuses. ### Why This Is Optimal Canary deployments governed by SLO error budget consumption represent the gold standard of SRE release engineering. Leveraging Google Cloud Deploy removes the operational risk of custom, brittle shell scripts while ensuring automated rollbacks execute seamlessly if an updated revision consumes disproportionate error budget.

Cloud Run Progressive Canary Rollout Slo | Professional Cloud DevOps Engineer

Cloud Run Progressive Canary Rollout Slo

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your team is preparing a deployment strategy for a mission-critical checkout microservice hosted on Cloud Run. To adhere to Site Reliability Engineering (SRE) principles and minimize customer impact, your deployment plan must satisfy the following criteria:

Deploy updates progressively using canary traffic splitting without exposing all users to new code at once.
Monitor real-time telemetry and error budget burn rates during each stage of the rollout.
Automatically halt the release and revert 100% of traffic to the previous healthy revision if Service Level Objective (SLO) error budget burn rates exceed acceptable thresholds.

Which deployment and release strategy should you implement?

Update the existing Cloud Run revision in-place by overwriting its container image and using Cloud Build scripts to rebuild the prior source code if Cloud Logging generates error notifications.

Execute an immediate blue-green swap by creating an isolated Cloud Run service for testing, running synthetic benchmarks, and switching 100% of live DNS traffic to the new service while terminating the old service.

Use Google Cloud Deploy to deliver the new container as a Cloud Run revision using a phased canary rollout strategy with deployment verification, and abandon the release to revert traffic back to the stable revision if SLO burn rate alerts fire.

Deploy the application across all GKE fleet clusters simultaneously using Config Sync and Fleet Packages with a rolling rollout strategy set to maxConcurrent: 1.

Professional Cloud DevOps Engineer

Cloud Run Progressive Canary Rollout Slo

Related questions