Examkin

Question

Difficulty: HardRelease Management and Deployment Strategies

A Principal Cloud Architect is designing an automated, zero-downtime progressive deployment process for a critical order-processing microservice hosted on Google Kubernetes Engine (GKE) backed by Cloud Spanner. The release involves a breaking application change that relies on an updated database schema. To prevent service disruption and data loss, the rollout must follow the expand-contract pattern combined with a progressive canary traffic migration managed via Cloud Deploy and Anthos Service Mesh. In which sequential order should the DevOps team execute these release steps?

  1. 1Apply non-breaking schema modifications (expand phase) to Cloud Spanner by adding new tables or nullable columns.
  2. 2Deploy the new microservice version workloads to GKE without routing any production ingress traffic to them.
  3. 3Configure Anthos Service Mesh traffic shifting to route a small percentage (e.g., 5%) of live requests to the canary deployment while monitoring latency and error rate SLIs.
  4. 4Promote the canary revision to serve 100% of live traffic and terminate the legacy application workloads upon verifying SLO compliance.
  5. 5Execute database schema cleanup (contract phase) in Cloud Spanner to remove deprecated columns and constraints.

Answer

The correct sequence starts with applying backward-compatible database schema changes (expand phase), followed by deploying the canary workloads to GKE, routing a small percentage of live traffic for SLI validation, shifting 100% of production traffic to the new revision and decommissioning legacy pods, and finally removing legacy database columns (contract phase).
The expand-contract pattern dictates that database changes must be introduced non-destructively prior to code releases (expand phase). Application workloads are then deployed and progressively tested using traffic splitting (canary deployment) controlled by service mesh or load balancers. Once 100% of traffic is promoted to the new code and old pods are removed, destructive database cleanups (contract phase) can safely execute.

Step-by-Step Solution

1
Execute the expand phase of the database migration in Cloud Spanner.
New columns or tables exist alongside legacy structures without breaking currently running application versions.
Decoupling database deployment from application code deployment ensures zero downtime and prevents schema mismatch errors during canary testing.
2
Provision the new version of the GKE application workload without shifting traffic.
Canary pods are running, healthy, and ready to accept traffic.
Workloads must pass health and readiness checks before receiving live user traffic.
3
Initiate progressive traffic splitting via Anthos Service Mesh to route 5% of user traffic to the canary workload.
Real user requests hit the canary revision while automated monitoring evaluates SLIs against SLO targets.
Canary analysis isolates risk to a small fraction of users and enables rapid automated rollback if error budgets are threatened.
4
Promote the new application version to 100% traffic and decommission legacy workloads.
All incoming production traffic lands on the new application revision.
Full migration guarantees that no active workloads rely on the old application version.
5
Execute the contract phase database migration in Cloud Spanner.
Deprecated database fields and old columns are removed safely.
Removing schema components before all active instances are updated causes runtime queries to fail.

Key Concept

Expand-Contract Database Migrations and Progressive Delivery Alignment
Rate this question

Topics

Release Management and Deployment Strategies

More questions from this topic