Your enterprise runs a critical web application on regional Compute Engine Managed Instance Groups (MIGs) across staging and production environments. You are tasked with implementing an automated patching and lifecycle promotion pipeline that strictly adheres to immutable infrastructure principles and minimizes the blast radius of potential regressions. The deployment strategy must satisfy the following requirements: Patches must be validated in staging before promotion to production. The production rollout must first be verified against real user traffic using a canary release targeting 10% of the instance fleet. If Cloud Monitoring alert thresholds (such as an elevated HTTP 5xx error rate) are breached during the canary phase, the system must automatically roll back to the previous stable state. Which strategy should you implement?

Bake a new VM image containing the applied patches, generate an updated instance template, and deploy it to the staging MIG. Upon successful staging tests, initiate a canary update on the production MIG specifying the current template and the new template with a 10% target size, and trigger an automated rollback script via Cloud Monitoring alerts if error thresholds are breached.: ### What the Solution Is This solution implements an **immutable infrastructure pattern** combined with **canary deployments** in Compute Engine Managed Instance Groups (MIGs) and automated remediation triggered by **Cloud Monitoring alerts**. ### How It Meets All Requirements - **Immutable infrastructure principles**: Rather than modifying running virtual machines in place, a new golden VM image is baked with all patches and dependencies pre-installed. A new **instance template** is created to reference this immutable image artifact. - **Sequential multi-environment promotion**: The newly generated instance template is applied and validated in the staging environment before any promotion steps begin in production. - **Canary deployment validation**: Using the `rolling-action start-update` command with `--version=template=CURRENT_INSTANCE_TEMPLATE` and `--canary-version=template=NEW_TEMPLATE,target-size=10%`, the production MIG shifts only 10% of its capacity to the new template while keeping 90% on the baseline version. - **Automated rollback via Cloud Monitoring**: If application SLIs/SLOs degrade (such as an increased error rate) during the canary soak time, a Cloud Monitoring alerting policy triggers automated rollback automation (such as a Cloud Run or Cloud Functions webhook) that reinstates the original instance template at 100% capacity. ### Key Advantages and Capabilities - **Blast radius containment**: Canary testing limits exposure to 10% of user traffic, avoiding widespread outages caused by faulty patches. - **Determinism and repeatability**: Pre-baked images ensure that every newly launched instance across environments is identical and free of runtime drift. - **Automated safety gates**: Monitoring alert integrations allow programmatic rollback without requiring manual operator intervention. ### Why This Is Optimal This approach aligns with Google Cloud site reliability engineering and DevOps best practices by separating artifact creation from environment promotion, employing progressive rollouts, and using metric thresholds for automated rollback decisions.

Immutable Mig Patching Canary Rollback Pipeline | Professional Cloud DevOps Engineer

Immutable Mig Patching Canary Rollback Pipeline

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 enterprise runs a critical web application on regional Compute Engine Managed Instance Groups (MIGs) across staging and production environments. You are tasked with implementing an automated patching and lifecycle promotion pipeline that strictly adheres to immutable infrastructure principles and minimizes the blast radius of potential regressions.

The deployment strategy must satisfy the following requirements:

Patches must be validated in staging before promotion to production.
The production rollout must first be verified against real user traffic using a canary release targeting 10% of the instance fleet.
If Cloud Monitoring alert thresholds (such as an elevated HTTP 5xx error rate) are breached during the canary phase, the system must automatically roll back to the previous stable state.

Which strategy should you implement?

Configure VM Manager Patch Management to execute an in-place OS patch job across staging VMs, verify compliance in the Patch dashboard, and execute a simultaneous 100% patch rollout across all production VMs with a post-patch script that restores disk snapshots on error.

Deploy the new instance template across both staging and production simultaneously, configure an internal HTTP(S) Load Balancer to route 10% of traffic to a separate canary MIG, and rely on Config Sync to reconcile the instance templates if drift occurs.

Bake a new VM image containing the applied patches, generate an updated instance template, and deploy it to the staging MIG. Upon successful staging tests, initiate a canary update on the production MIG specifying the current template and the new template with a 10% target size, and trigger an automated rollback script via Cloud Monitoring alerts if error thresholds are breached.

Create an instance template that executes dynamic package updates inside a startup script, apply it to the staging MIG, and update the production MIG directly to 100% while relying on Compute Engine auto-healing health checks to revert the template upon failure.

Professional Cloud DevOps Engineer

Immutable Mig Patching Canary Rollback Pipeline

Related questions