Deployment and release management

Fenwick Health uses Cloud Deploy to release a GKE application through dev, staging, and prod targets. Auditors require that every production rollout is approved by a member of the release-managers group, that developers cannot deploy directly to the prod cluster, and that releases reach prod only after succeeding in staging. The team also wants a fast way to return prod to the previous release.

Which configuration meets these requirements?

1. AGrant developers the Kubernetes Engine Developer role on the prod cluster so they can deploy fixes quickly, and enable approvals on stagingDirect cluster access lets developers bypass the pipeline, and approvals on staging do not control production.
2. BCreate a separate delivery pipeline for prod and let the release-managers group run kubectl apply after reviewing the staging resultsManual kubectl deploys bypass Cloud Deploy's release history, promotion order, and rollback.
3. CSet requireApproval on the prod target, grant the Cloud Deploy Approver role only to release-managers, keep prod after staging in the pipeline's serial progression, make the Cloud Deploy execution service account the only identity with deploy rights on the prod cluster, and use Cloud Deploy rollback to the previous releaseTarget approval enforces the human gate, the serial pipeline enforces staging before prod, limiting cluster deploy rights to the pipeline's service account blocks direct deploys, and rollback redeploys the last successful release.
4. DUse a Cloud Build trigger on the main branch that deploys directly to the prod cluster after tests passA direct build-to-prod path skips the staging promotion and the required human approval.

Eastmere Utilities runs a billing application on a Compute Engine managed instance group behind an external Application Load Balancer. A new version changes many components at once, and the business wants to switch all users to the new version in one step and be able to switch back immediately with full capacity if problems appear. Temporary extra cost during the release is acceptable.

Which deployment strategy should you recommend?

1. ABlue/green deployment: create a second managed instance group with the new version at full size and switch the load balancer backend to it, keeping the old group until the release is confirmedBlue/green runs two complete environments, so cutover and rollback are a single backend switch with full capacity on either side, at the cost of temporarily doubled resources.
2. BRolling update of the existing managed instance group with maxSurge of 1A rolling update replaces instances gradually, so both versions serve traffic for a period and rollback is another gradual update.
3. CRecreate deployment that stops all instances and starts new onesRecreate causes downtime during the switch and makes rollback slow.
4. DCanary release that sends 5 percent of traffic to the new versionA canary is gradual exposure, not a single-step switch for all users.

Quaybridge Logistics deploys a Cloud Run service named route-api. Releases occasionally contain regressions that appear only under real traffic. The team wants each production release to first receive 10 percent of traffic, then 50 percent, then 100 percent, with the ability to stop at any phase, and wants the release process managed by a Google Cloud service rather than custom scripts.

What should you do?

1. ADeploy each new revision with 100 percent of traffic and roll back with gcloud if errors appearThis exposes all users to every regression before rollback and does not provide phased exposure.
2. BUse a Cloud Deploy delivery pipeline with a canary deployment strategy for the production target, configured with 10 and 50 percent phases before the stable phaseCloud Deploy supports canary strategies for Cloud Run, shifting traffic in the configured percentages, and lets you advance, stop, or roll back each phase through the managed release process.
3. CCreate a second Cloud Run service and use DNS weighted routing to split trafficThis doubles services to maintain and relies on DNS caching, which makes traffic percentages imprecise and slow to change.
4. DUse a Cloud Build trigger that runs a script to update traffic percentages after fixed delaysThis is the custom scripting the team wants to avoid, and fixed delays ignore whether each phase is healthy.