Examkin

Question

Difficulty: HardAutomating Continuous Deployment Pipelines and Release Strategies

Your enterprise cloud architecture team is establishing an automated, secure progressive delivery pipeline using Cloud Build, Artifact Registry, Binary Authorization, and Google Cloud Deploy. In what chronological sequence should the pipeline execution steps occur to safely roll out a new microservice release from code build to full production traffic?

  1. 1Compile the service, build the container image via Cloud Build, sign the digest using a Cloud KMS attestation key for Binary Authorization, and push the artifact to Artifact Registry.
  2. 2Create a new release in Google Cloud Deploy referencing the signed container image digest and target delivery pipeline definition.
  3. 3Deploy the Cloud Deploy release to the canary deployment target phase and route a small fraction (e.g., 10%) of live production traffic to the new revision.
  4. 4Evaluate automated telemetry by analyzing Cloud Monitoring metrics and error budgets for the canary workload against established SLO thresholds.
  5. 5Promote the Google Cloud Deploy release to the primary production target phase to route 100% of live user traffic to the verified revision.

Answer

The correct release sequence is: (1) Build container image and generate Binary Authorization attestation in Cloud Build -> (2) Register Cloud Deploy release with signed image digest -> (3) Deploy to canary stage and route partial live traffic -> (4) Perform automated SLO canary analysis via Cloud Monitoring -> (5) Promote release in Cloud Deploy to shift 100% traffic to production.
The proper release sequence follows shift-left security and progressive delivery best practices. First, Cloud Build creates the container artifact and signs it with a Cloud KMS key to satisfy Binary Authorization policies. Next, a Cloud Deploy release is declared using the signed image digest. The release is then deployed to a canary phase where a small portion of live traffic is routed. Operational health metrics (latency, error rates) are monitored and verified against SLOs. Once verified, Cloud Deploy promotes the release to receive 100% of production traffic.

Step-by-Step Solution

1
Container artifact creation and security attestation
Signed container image stored in Artifact Registry with valid Binary Authorization attestation
Binary Authorization policies require images to be attested before deployment can be initiated.
2
Delivery pipeline release declaration
Cloud Deploy release object created referencing the exact immutable image digest
Cloud Deploy requires an explicit release declaration to bind target configurations with the container digest.
3
Canary deployment and initial traffic routing
Workload deployed to canary target phase with initial percentage of traffic directed to it
Progressive delivery minimizes blast radius by testing candidate revisions on real-world traffic subsets.
4
Canary health and telemetry verification
Metrics validated against latency, error rate, and availability SLOs
Automated metric evaluation confirms system stability before expanding deployment scale.
5
Full production promotion
100% of production traffic routed to the newly promoted revision
Promoting the release finalizes deployment after passing all automated health gates.

Key Concept

Automating progressive delivery release pipelines using Cloud Build, Binary Authorization, Google Cloud Deploy, and Cloud Monitoring canary verification.
Rate this question

Topics

Automating Continuous Deployment Pipelines and Release Strategies