Question

Difficulty: MediumRelease Management and Deployment Strategies

An enterprise organization is planning a major version release for a mission-critical financial reporting service deployed on Compute Engine Managed Instance Groups (MIGs) behind an External HTTP(S) Load Balancer. The update involves modifying the underlying database structure. The technical team requires zero application downtime during deployment and the ability to instantly roll back if errors are detected in production without causing data corruption or application failures in the live environment. Which deployment approach should the Cloud Architect recommend to achieve these reliability requirements?

  1. Implement an expand-contract database schema migration pattern to maintain backward compatibility before triggering a blue-green deployment of the new application version.Answer
  2. B
    Deploy the updated application version and database schema breaking changes simultaneously in a blue-green release environment.
  3. C
    Grant the primitive Owner role to the deployment pipeline service account and perform a rolling update on the production Managed Instance Group while locking database tables.
  4. D
    Maintain the deployment pipeline state in local unversioned storage on the VM instance and execute an automated canary release directly against the database.

Answer

Implement an expand-contract database schema migration pattern to maintain backward compatibility before triggering a blue-green deployment of the new application version.
The correct option advocates for an expand-contract database pattern alongside a blue-green application release strategy. By ensuring that database schema changes are additive and backward-compatible, both the legacy and updated versions of the microservice can run concurrently. This eliminates downtime during traffic switching at the load balancer level and allows for instant, safe rollbacks if anomalies are observed.

Step-by-Step Solution

1
Analyze deployment constraints and downtime/rollback requirements.
Identified that database schema changes must support both old and new application code concurrently to prevent data corruption during cutover or rollback.
Blue-green deployments require both environments to operate independently or gracefully share data repositories during transition.
2
Apply the expand-contract (parallel change) pattern to the database schema.
Database changes are made additively without dropping legacy columns or breaking existing contracts.
Allows the active application version to function without error while the new version is deployed and tested.
3
Provision the new green environment and shift load balancer traffic.
Traffic cutover happens seamlessly with zero downtime, and immediate rollback remains viable.
If issues arise, load balancer target groups can immediately point back to the blue environment because the schema remains compatible.

Key Concept

Database Backward Compatibility in Blue-Green Deployments
Estimated Time:2m 0s
Rate this question