Examkin

Question

Difficulty: Very hardRelease Management and Deployment Strategies

A financial platform hosts stateless microservices on Cloud Run connected to a Cloud SQL for PostgreSQL instance. The application team plans to release a major update that requires a breaking database schema change, specifically renaming a critical column and changing its data type. The team must execute a zero-downtime canary deployment using Cloud Run traffic splitting, while maintaining the ability to instantly roll back traffic to the previous application revision without causing runtime errors or data corruption for users on either revision. Which release management strategy should you implement?

  1. Implement an expand-contract database migration pattern by adding the new column alongside the existing column, deploying the new Cloud Run revision using gradual traffic splitting, and removing the legacy column only after the new revision is fully deployed and verified.Answer
  2. B
    Apply the DDL migration script to rename the column directly in Cloud SQL immediately before initiating the Cloud Run canary traffic split to ensure the database schema matches the incoming revision.
  3. C
    Configure the Cloud Run service startup probe to run a database DDL validation query that checks for the newly renamed column, ensuring traffic is routed only after the database migration finishes.
  4. D
    Grant the CI/CD pipeline service account the Project Editor role (`roles/editor`) so it can perform schema DDL operations and execute Cloud Run traffic splitting within a single pipeline execution step.

Answer

Implement an expand-contract database migration pattern by adding the new column alongside the existing column, deploying the new Cloud Run revision using gradual traffic splitting, and removing the legacy column only after the new revision is fully deployed and verified.
The correct strategy uses an expand-contract (also known as parallel run) database migration pattern. In canary deployments or blue-green releases, multiple application revisions run concurrently against the same database backend. To prevent runtime errors and ensure instant rollback capability, database schema changes must be non-breaking and backward-compatible. Adding the new column while writing to both columns ensures that the old application version continues working seamlessly alongside the canary version.

Step-by-Step Solution

1
Analyze deployment constraints
Identified the need for zero-downtime canary deployment with simultaneous operation of old and new application revisions against a shared database.
Canary deployments shift traffic incrementally, meaning both application versions must query the database at the same time.
2
Evaluate database schema compatibility strategy
Adopt the expand-contract (parallel run) pattern.
Breaking schema changes must be decoupled into multi-phase additive changes so legacy application instances do not fail when querying missing columns.
3
Design canary release lifecycle
Phase 1: Expand database with new column/dual-write capability. Phase 2: Deploy new Cloud Run revision and split traffic. Phase 3: Contract database by removing legacy column after full rollout.
Ensures full rollback capability at any stage during traffic migration without service downtime or query errors.

Key Concept

Decoupling Database Schema Migrations from Application Deployments (Expand-Contract Pattern)
Estimated Time:3m 0s
Rate this question

Topics

Release Management and Deployment Strategies

More questions from this topic