GCP Professional Cloud Architect Practice Question

Your company is launching a new checkout microservice to a multi-tenant GKE Autopilot cluster that already runs dozens of workloads. Container images are built with Cloud Build and pushed to Artifact Registry. Compliance policy requires every change to be declared and peer-reviewed in the main Git repository. Product owners insist that in production only 10 % of user traffic should reach the new version for 30 minutes, after which the rollout must either complete automatically or revert if the request-error rate rises above 2 %. Which deployment approach best satisfies the requirements while minimising ongoing operational overhead?

Create Cloud Deployment Manager templates that patch the Kubernetes Deployment, schedule a Cloud Scheduler job to run a script every 5 minutes that parses log-based metrics and calls gcloud container clusters rollback when the 2 % error threshold is crossed.
Use Cloud Functions to call the Cloud Run Admin API, create a new revision of the microservice, split traffic 90/10 for 30 minutes, and publish a Pub/Sub message to trigger full promotion or manual rollback based on BigQuery analysis of logs.
Define a Cloud Deploy delivery pipeline that uses a canary strategy for the target GKE cluster with 10 % and 100 % phases, a 30-minute dwell time, and an automatic rollback condition tied to a Cloud Monitoring alert on request-error rate. Store the pipeline YAML alongside the application code in the Git repository.
Invoke kubectl apply from Cloud Build to update the Deployment image, rely on Kubernetes HorizontalPodAutoscaler to limit initial load, and perform rollback manually with kubectl set image if monitoring dashboards show errors.

Report Issue

Answer Description

Cloud Deploy provides first-class support for declarative deployment pipelines stored as YAML that can be kept under version control and reviewed like application code. Its canary release strategy for GKE lets you specify phased traffic percentages (for example, 10 % followed by 100 %), dwell times between phases, and Cloud Monitoring-based rollout policies. If the configured metric (such as request-error rate) breaches the 2 % threshold during the 30-minute dwell period, Cloud Deploy automatically aborts the rollout and rolls the release back to the previous stable Kubernetes workload. Because all of this behaviour is native to the managed service, no custom scripts, cron jobs, or manual kubectl commands are required. The other options rely on manual scripting or deprecated tooling and therefore do not meet the automation, policy, or rollback requirements.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.