Examkin

Question

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

A logistics enterprise operates a real-time shipment tracking service running on Compute Engine Regional Managed Instance Groups (MIGs) fronted by an External HTTP(S) Load Balancer. The application persists state in a Cloud SQL for PostgreSQL database. The development team is preparing to deploy a major release that contains breaking database schema alterations. The deployment policy requires zero downtime and a rapid, zero-downtime rollback capability if errors occur after traffic migration. Which deployment and database migration strategy should the cloud architect recommend?

  1. Implement an expand-contract database schema pattern to support both legacy and new application versions concurrently, provision the new application code in a Green MIG, validate the deployment, and update the load balancer backend service to switch traffic from Blue to Green.Answer
  2. B
    Apply the breaking database schema migrations directly to the production Cloud SQL instance, provision the Green MIG to test against the modified database, and then shift load balancer traffic from the Blue MIG to the Green MIG.
  3. C
    Migrate the entire application workload from Compute Engine MIGs to a multi-zonal Google Kubernetes Engine (GKE) Enterprise cluster to natively automate database schema compatibility and traffic shifting.
  4. D
    Provision the Green MIG in a separate target region without requesting regional CPU quota increases beforehand, relying on Cloud Load Balancing to automatically adjust regional resource limits during traffic cutover.

Answer

The cloud architect should implement an expand-contract database schema migration pattern so the database concurrently supports both old and new application versions. The team can then deploy the release to a Green MIG, validate it, and route load balancer traffic to the Green MIG with minimal risk.
Executing a successful Blue-Green deployment for applications backed by relational databases requires an expand-contract (additive) schema evolution. By making database changes additive first, both the active Blue MIG and the newly created Green MIG can run concurrently against Cloud SQL. Once the Green MIG is validated, the External HTTP(S) Load Balancer seamlessly updates its backend service target to complete the release with zero downtime.

Step-by-Step Solution

1
Decouple database schema changes using the expand-contract pattern.
Database additions (columns/tables) are backward-compatible with the active Blue application version.
Prevents breaking active user requests running on the legacy Blue deployment while preparing for the Green deployment.
2
Provision and validate the Green MIG.
The new version runs isolated alongside Blue and communicates cleanly with the expanded schema.
Allows verification of application health prior to exposing production traffic.
3
Update Load Balancer backend traffic routing from Blue MIG to Green MIG.
Traffic shifts cleanly to Green; if issues arise, traffic can immediately shift back to Blue without database corruption.
Achieves zero downtime and immediate rollback capability for Blue-Green deployments.

Key Concept

Blue-Green Deployment with Backward-Compatible (Expand-Contract) Database Schema
Estimated Time:2m 0s
Rate this question

Topics

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