GCP Professional Cloud DevOps Engineer Practice Question 8: Cloud Deploy Canary Promotion
Google Cloud Professional Cloud DevOps Engineer · Test 1 · question 8 of 10
A team currently promotes releases by re-running a Cloud Build trigger against the production branch and applying manifests with kubectl. They want production traffic shifted to a new version in stages rather than all at once, advancement between stages gated on observed metrics, an explicit human approval before anything reaches production, an auditable record of which exact artifact ran where, and a one-step way back to the previous version.
Which implementation should they adopt?
Show answer and explanation
Answer:
Cloud Deploy models exactly the requirements listed. A delivery pipeline defines an ordered sequence of targets, and a release, built once and rendered per target, is *promoted* through them, so the same artifact demonstrably moves from staging to production rather than being rebuilt. Targets can require approval, giving the human gate. A canary strategy on the production target splits traffic across percentage phases (for example canary-25, canary-50, then stable), and verification or deploy-analysis jobs between phases can hold or advance the rollout based on metrics from Google Cloud Observability. Every rollout is recorded, and rolling back is a first-class operation that redeploys the prior successful release.
Option A rebuilds the artifact per environment. Two builds from the same commit are not guaranteed to be the same image, which breaks the "this exact artifact was tested" guarantee, and branch protection provides a code-review gate rather than a deployment approval. It also offers no traffic splitting and no rollback primitive.
Option C achieves a version switch but not progressive exposure: DNS cutover is all-or-nothing for each resolver, it is slowed and made unpredictable by client-side and resolver caching, and the smoke test is manual rather than a metric-driven gate.
Option D controls how Pods are *replaced*, not how traffic is *apportioned*. A rolling update gives no percentage-based traffic split between versions, no automated metric analysis between increments, and no approval or promotion record; it is the mechanism a deployment strategy uses, not the strategy itself.
Reference: Canary deployments in Cloud Deploy