An enterprise financial application hosted on Compute Engine Regional Managed Instance Groups (MIGs) serves global production traffic behind a Global External Application Load Balancer. The platform engineering team uses an automated CI/CD pipeline to perform blue-green deployments for zero-downtime application updates. The application relies on a Cloud Spanner database whose schema was updated prior to the release using additive, backward-compatible migrations. During the execution of the pipeline, the deployment halts in the provisioning phase while creating the green MIG in the `us-central1` region—before any production traffic is shifted—because instance creation exceeds allowed limits. Which root cause explains why the green environment provisioning failed, and what is the architecturally sound remediation strategy to successfully execute the deployment?
- The deployment failed because provisioning a full-capacity green environment alongside the active blue environment requires 200% regional compute resources, exceeding project quota limits. The team must request a regional Compute Engine CPU quota increase in advance of blue-green releases.Answer
- BThe deployment failed because the pre-deployment database schema updates created lock contention on Cloud Spanner tables. The team must roll back the additive schema changes and re-apply non-backward-compatible migrations after shifting traffic to the green MIG.
- CThe deployment failed because Compute Engine MIGs cannot handle parallel deployment strategies. The team must migrate the workload from Compute Engine MIGs to GKE Autopilot clusters to eliminate compute capacity provisioning constraints.
- DThe deployment failed because the load balancer health checks were configured to probe a deep database endpoint. The team must modify the health check to query backend database tables directly during instance startup to confirm data readiness.