Question

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

Your organization is implementing an automated canary release strategy using Google Cloud Deploy and GKE Gateway API for a mission-critical transaction microservice connected to a Cloud SQL relational database. The deployment pipeline must shift traffic incrementally from the active revision to the canary revision while continuously evaluating Cloud Monitoring metrics against a target Service Level Indicator (SLI). The upcoming software release includes a relational database schema update that adds a mandatory field required by the new software version. Which release management approach ensures continuous service availability and automated rollback capabilities during this rollout?

  1. Implement a multi-phase database migration strategy with backward-compatible schema changes applied prior to triggering the canary rollout, while using Cloud Deploy with Cloud Monitoring verification metrics for automated traffic rollback.Answer
  2. B
    Execute non-backward-compatible database schema updates immediately before starting the canary traffic split so that both active and canary application revisions immediately use the new structure.
  3. C
    Re-architect the pipeline to destroy and re-provision the GKE clusters on every application deployment release to guarantee strict environment isolation before executing the schema update.
  4. D
    Provision a parallel Cloud SQL database instance for each deployment release without checking regional resource limits, redirecting canary application instances to the new database endpoint.

Answer

Implement a multi-phase database migration strategy with backward-compatible schema changes applied prior to triggering the canary rollout, while using Cloud Deploy with Cloud Monitoring verification metrics for automated traffic rollback.
In progressive delivery strategies like canary deployments, both the active release and the canary revision must coexist and process transactions simultaneously. Applying backward-compatible schema changes (such as expanding schema with optional/default columns) prior to shifting traffic guarantees database compatibility across both application revisions. Integrating Cloud Deploy with Cloud Monitoring automated rollback criteria satisfies the requirements for zero downtime and metric-driven automated recovery.

Step-by-Step Solution

1
Analyze concurrent version requirements during progressive traffic shifting.
Identified that during a canary release, both the existing application revision and the new canary application revision serve user traffic simultaneously against the shared Cloud SQL database.
Any breaking schema change applied while old application code is active will corrupt data or cause SQL runtime failures for active users.
2
Formulate a phased schema migration approach.
Apply additive, backward-compatible schema modifications (e.g., adding nullable columns or default values) before launching the application deployment pipeline.
Ensures that older application versions ignore the new database columns while newer versions can write to them.
3
Configure progressive delivery automation with safety gates.
Utilize Cloud Deploy integrated with Cloud Monitoring metrics to automatically roll back traffic if the canary revision breaches defined SLI thresholds.
Provides automated failure detection and zero-downtime rollback capabilities without manual operator intervention.

Key Concept

Backward-Compatible Database Migrations in Canary Deployments
Rate this question