Examkin

Question

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

An engineering team is deploying an updated version of a stateless microservice to Cloud Run. The update requires modifying a Cloud SQL PostgreSQL table schema by adding a new required column and removing an obsolete column. The team plans to perform a canary deployment using Cloud Run revision traffic splitting over 24 hours. How should the cloud architect structure the deployment strategy to maintain zero downtime and ensure immediate rollback capability throughout the release?

  1. Apply the schema migration using an expand-and-contract pattern by first adding the new column as optional, deploying the new Cloud Run revision to handle both old and new schema structures, and deferring the removal of the obsolete column until after traffic is 100% shifted and validated.Answer
  2. B
    Execute the database schema migration script directly on the production database immediately prior to starting the 1% traffic split to the new Cloud Run revision, enabling both revisions to interact with the new database schema.
  3. C
    Migrate the application from Cloud Run to Google Kubernetes Engine (GKE) using Istio and StatefulSets, placing database schemas onto local node persistent storage to isolate canary revision database operations from production.
  4. D
    Clone the Cloud SQL instance to a new regional database target with the updated schema, split Cloud Run revision traffic to the new database, and submit regional CPU quota increase requests once canary traffic hits 50%.

Answer

Structure the database migration using an expand-and-contract strategy: add the new column as optional first, deploy the dual-compatible application revision via Cloud Run traffic splitting, and remove the deprecated column only after full rollout verification.
Executing database schema updates via an expand-and-contract approach ensures backward compatibility throughout the traffic shifting process. During a canary deployment, both old and new application revisions query the database simultaneously; keeping schema changes non-breaking allows both revisions to operate without downtime and guarantees safe rollback capability if anomalies occur.

Step-by-Step Solution

1
Analyze the database schema dependencies between active and new revisions during canary traffic splitting.
Identified that both application revisions will run concurrently and write to the same database instance during the rollout window.
Traffic splitting routes user requests to both revisions simultaneously, requiring database schema backward compatibility.
2
Design an expand-and-contract migration strategy for Cloud SQL.
Database changes are executed in multi-phase backward-compatible steps rather than a single breaking DDL script.
Allows the legacy revision to function correctly while the canary revision validates the new application logic.
3
Execute the final cleanup contract phase after successful canary validation.
Obsolete database columns are removed only when no active traffic relies on the old schema.
Ensures zero-downtime operations and enables frictionless rollback during the canary observation window.

Key Concept

Expand-and-contract database schema migration pattern during canary deployments
Estimated Time:2m 0s
Rate this question

Topics

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