Try each one before opening the answer. Every option is explained, with the Google Cloud documentation page that proves it.
Question 1 · choose 1
A team deploys a new revision of a customer-facing Cloud Run service. It wants 5% of requests to reach the new revision first, to watch error rates for an hour before moving the rest, and to be able to send all traffic back to the previous revision within seconds. How should the team release it?
ADeploy the revision as the default, and redeploy the old image if errors start to rise
BCreate a second Cloud Run service and weight DNS records to send it 5% of users
CDeploy it with no traffic, then split traffic between the revisions by percentage
DRaise minimum instances on the new revision before it takes production traffic
Show the answer and why
ADeploy the revision as the default, and redeploy the old image if errors start to rise
Incorrect
Every user gets the new revision at once, and a redeploy is a slower rollback than shifting traffic.
BCreate a second Cloud Run service and weight DNS records to send it 5% of users
Incorrect
DNS weighting is coarse and cached by clients, so rollback waits on record TTLs.
CDeploy it with no traffic, then split traffic between the revisions by percentage
Correct
Cloud Run can deploy a revision without serving traffic, send it a chosen percentage, and move traffic back to an earlier revision at once.
DRaise minimum instances on the new revision before it takes production traffic
Incorrect
Instance settings change a revision's capacity, not which revision receives requests, so they do not create a gradual rollout.
Release management on Cloud Run uses revisions and traffic splitting: canary a small share, watch, then migrate or roll back by changing percentages.
A team releases a GKE service through Cloud Deploy. It wants each release to go to 10% and then 50% of traffic before full rollout, with automated tests run after each phase to confirm the new version works. How should the team configure the pipeline?
AA standard strategy that replaces every Pod at once, followed by a manual smoke test
BTwo delivery pipelines, one for 10% of clusters and one for the rest of them
CA Kubernetes rolling update with maxSurge set to 10 percent of the replicas
DA canary strategy with 10 and 50 percent phases and deployment verification on
Show the answer and why
AA standard strategy that replaces every Pod at once, followed by a manual smoke test
Incorrect
A standard rollout sends all traffic to the new version at once, and manual tests are slow.
BTwo delivery pipelines, one for 10% of clusters and one for the rest of them
Incorrect
Splitting by cluster is not a traffic percentage and duplicates the pipeline.
CA Kubernetes rolling update with maxSurge set to 10 percent of the replicas
Incorrect
Rolling updates replace Pods gradually but do not hold traffic at phases or run verification.
DA canary strategy with 10 and 50 percent phases and deployment verification on
Correct
Cloud Deploy's canary strategy splits traffic in phases, and deployment verification runs your test images after each deployment.
Progressive release management combines traffic phases with automated checks, which Cloud Deploy provides as canary deployments with verification.
A web tier runs in a regional managed instance group of 40 VMs. The team wants a new VM image to serve on about 4 VMs for a day while it compares error rates, before deciding whether to roll it out to the rest. How should the team release the image?
ACreate a new MIG from the new template and delete the old one afterward
BUpdate the template and recreate the 40 VMs one zone at a time
CSet the autoscaler's minimum to 44 so the new VMs are added on top
DAdd a second instance template to the group with a target size of 10%
Show the answer and why
ACreate a new MIG from the new template and delete the old one afterward
Incorrect
Replacing the group switches everything at once rather than testing on a subset.
BUpdate the template and recreate the 40 VMs one zone at a time
Incorrect
A zone-by-zone recreation is a full rollout, not a canary held for a day.
CSet the autoscaler's minimum to 44 so the new VMs are added on top
Incorrect
Autoscaler settings control group size, not which template new VMs use.
DAdd a second instance template to the group with a target size of 10%
Correct
A MIG can run a canary of a second instance template on a subset of its VMs before the template is applied to all of them.
Release management for VM fleets uses the MIG's own canary support: run two templates side by side, compare, then complete or roll back.
The latest release on the production GKE target of a Cloud Deploy pipeline is causing errors. The previous release was healthy. What is the fastest supported way to restore production?
ARebuild the previous version from source and create a new release
BRoll back the production target to the last successful release
CEdit the Deployment with kubectl to point at the previous image tag
DDelete the delivery pipeline and recreate it from the configuration
Show the answer and why
ARebuild the previous version from source and create a new release
Incorrect
Rebuilding takes longer and may not reproduce the exact artifacts that were healthy.
BRoll back the production target to the last successful release
Correct
A Cloud Deploy rollback creates a new rollout based on a previous release, by default the last one that succeeded on that target.
CEdit the Deployment with kubectl to point at the previous image tag
Incorrect
Changing the cluster outside Cloud Deploy causes drift from the pipeline's record.
DDelete the delivery pipeline and recreate it from the configuration
Incorrect
Recreating the pipeline does not redeploy the healthy release.
Every release process needs a rehearsed rollback. With Cloud Deploy, rolling back a target to an earlier release is a built-in operation.
A team must upgrade the node pools of a production GKE Standard cluster. Last time, an upgrade broke a workload in a way that showed up only after an hour, and going back meant another full upgrade. This time the team wants to validate the workloads on the new nodes for a soak period while the old nodes stay ready for a quick rollback. Which upgrade approach should the team use?
ASurge upgrades with a higher maxSurge setting on the node pools
BA maintenance exclusion that postpones the upgrade for a month
CThe blue-green upgrade strategy with a soak time on the node pools
DA move of the cluster to the Rapid release channel ahead of time
Show the answer and why
ASurge upgrades with a higher maxSurge setting on the node pools
Incorrect
Surge upgrades replace nodes in a rolling window; a larger surge goes faster but keeps no old environment to return to.
BA maintenance exclusion that postpones the upgrade for a month
Incorrect
An exclusion delays the upgrade; it does nothing to validate the new nodes or make a rollback quick.
CThe blue-green upgrade strategy with a soak time on the node pools
Correct
Blue-green upgrades create the new nodes first and keep the old ones for rolling back until the soak time has passed.
DA move of the cluster to the Rapid release channel ahead of time
Incorrect
A release channel decides how soon new versions arrive, not how an upgrade can be validated and rolled back.
Release management covers platform changes too. GKE's blue-green node pool upgrade keeps the original nodes while workloads soak on the new ones, so the team can roll back an in-progress upgrade if problems appear.