Examkin

Question

Difficulty: HardRelease Management and Deployment Strategies (Blue-Green, Canary, Rolling)

A fintech company hosts its real-time fraud detection microservice on Google Cloud Run, connected to a Managed Cloud SQL for PostgreSQL database. The development team is preparing a continuous deployment pipeline using Google Cloud Deploy to perform canary releases with gradual traffic splitting across Cloud Run revisions. The upcoming application release requires a breaking database schema modification: renaming a column used in transaction scoring. To maintain zero downtime and ensure the active revision continues processing transactions without errors during the canary phase, which deployment and database strategy should the Cloud Architect recommend?

  1. Apply an expand-contract database migration strategy by first adding the new column and maintaining backward compatibility via triggers or application dual-writing, completing the Cloud Run revision canary deployment, and dropping the legacy column only after 100% traffic is shifted.Answer
  2. B
    Execute a database DDL script to rename the column immediately prior to triggering the 10% canary traffic allocation in Cloud Deploy, relying on Cloud Run auto-rollback if error rates increase.
  3. C
    Migrate the microservice workload from Cloud Run to a Google Kubernetes Engine (GKE) Enterprise cluster with Istio Service Mesh to enforce database transaction isolation at the pod level before running canary deployments.
  4. D
    Deploy a duplicate instance of the Cloud Run revision to an alternative GCP region and instantly shift 100% of production traffic using Cloud Load Balancing without requesting quota updates beforehand.

Answer

The architect should enforce an expand-contract (parallel-change) database schema strategy so both active revisions function concurrently during canary traffic splitting.
The correct strategy uses the expand-contract pattern. In canary or blue-green release strategies involving shared stateful backends (such as Cloud SQL), schema changes must be backward-compatible. Adding the new column first allows the baseline revision to continue using the original column while the canary revision utilizes the new schema. Once traffic transition completes successfully, the obsolete column is safely removed.

Step-by-Step Solution

1
Analyze the impact of canary deployments on shared database schemas.
During traffic splitting (e.g., 90% version 1, 10% version 2), both application revisions execute queries simultaneously against the same Cloud SQL instance.
Directly applying destructive schema updates (like renaming a column) causes immediate query failures in version 1 instances.
2
Design the database migration phases (Expand phase).
Add the new database column without altering or dropping the existing column. Update database views, triggers, or application writing logic so writes populate both fields.
Allows existing revision instances to operate normally while preparing the database for the new revision.
3
Execute the Canary deployment in Google Cloud Deploy.
Gradually shift Cloud Run revision traffic from 0% to 100%. Monitor SLIs (latency, error rate).
Verifies that the new revision operates safely in production under real traffic conditions.
4
Finalize schema cleanup (Contract phase).
Remove the deprecated database column and cleanup temporary triggers after 100% of traffic is successfully running on the new revision.
Completes technical debt cleanup safely without impacting live application traffic.

Key Concept

Expand-Contract (Parallel Change) Schema Migration in Canary Deployments
Estimated Time:2m 0s
Rate this question

Topics

Release Management and Deployment Strategies (Blue-Green, Canary, Rolling)