Examkin

Question

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

A digital media streaming platform relies on a stateless recommendations microservice hosted on Google Cloud Run, backed by a Cloud SQL for PostgreSQL database. The engineering team needs to roll out a major feature release that includes a breaking database schema change (renaming several existing database columns). The deployment must achieve zero downtime and allow for an immediate rollback if errors occur during release cutover. How should the cloud architect design the deployment and database migration pipeline?

  1. A
    Migrate the stateless recommendations microservice from Cloud Run to a new Google Kubernetes Engine (GKE) Enterprise cluster with an Istio service mesh, and use GKE Ingress canary traffic management to resolve the database schema incompatibility during traffic shifting.
  2. Apply an expand-contract database migration strategy by first introducing backward-compatible schema changes, deploy the new Cloud Run revision alongside the existing revision, gradually split traffic to the new revision, and execute the contract phase to clean up obsolete columns only after the release is fully verified.Answer
  3. C
    Apply the non-backward-compatible database migration directly to the production Cloud SQL database first, deploy the new Cloud Run revision, and immediately update Cloud Run traffic routing to direct 100% of requests to the new revision.
  4. D
    Provision a duplicate Compute Engine Managed Instance Group (MIG) across multiple secondary regions without requesting regional compute quota increases in advance, run the database migration, and switch global Cloud Load Balancing IP targeting to the new MIG.

Answer

Execute an expand-contract database migration strategy to maintain backward compatibility, allowing old and new Cloud Run revisions to serve traffic concurrently during traffic splitting before finalizing the schema cleanup.
The correct strategy uses the expand-contract (parallel change) database design pattern alongside Cloud Run revision traffic management. By ensuring the database schema remains backward-compatible during the transition, both the existing revision and the newly deployed revision can operate concurrently without errors. Once traffic is fully shifted and confirmed healthy, the old schema components can be safely retired.

Step-by-Step Solution

1
Implement the Expand Phase for Database Schema
Database schema is updated to support both legacy and new application requirements simultaneously (e.g., adding new columns alongside old ones or creating views).
This guarantees that the currently active Cloud Run revision continues operating without SQL errors while preparing for the new revision.
2
Deploy New Cloud Run Revision and Traffic Split
Deploy the updated application revision to Cloud Run with 0% traffic initially, then gradually shift traffic (e.g., 10%, 50%, 100%) while monitoring key metrics and error budgets.
Cloud Run native revision traffic splitting allows real-time canary monitoring and instant rollback if issues arise.
3
Execute the Contract Phase for Database Schema
Once the new revision serves 100% of traffic stably, remove obsolete database columns and legacy schema elements.
Completing the contract phase cleans up database technical debt after verifying that rollback to the legacy application revision is no longer required.

Key Concept

Decoupled Blue-Green/Canary Deployments with Expand-Contract Database Schema Migration
Estimated Time:2m 0s
Rate this question

Topics

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