Question

Difficulty: HardRelease Management and Deployment Strategies

An enterprise retail organization is updating its deployment automation for containerized web services running on Google Cloud Run backed by a Cloud SQL for PostgreSQL database. The release pipeline is managed via Cloud Build and uses Terraform for infrastructure provisioning. The principal architect must ensure zero-downtime releases, prevent service degradation during rollbacks, enforce secure infrastructure state persistence, and adhere to least-privilege security controls. Which TWO architectural practices should the engineering team implement? (Select TWO.)

  1. Decouple database modifications from application releases by applying backward-compatible schema changes using the expand-contract pattern before shifting production traffic to new Cloud Run revisions.Answer
  2. Persist Terraform infrastructure state files in a versioned Cloud Storage bucket with object locking while assigning fine-grained, predefined IAM roles to the Cloud Build service account.Answer
  3. C
    Execute destructive database schema migrations simultaneously with the deployment step that shifts 100% of user traffic to the new Cloud Run revision.
  4. D
    Store Terraform state files locally on the transient disk of the Cloud Build runner workspace and grant the Cloud Build service account the primitive Owner role.
  5. E
    Rely exclusively on dynamic Cloud Run instance autoscaling during canary deployments without pre-evaluating or requesting regional database connection quotas.

Answer

The engineering team must decouple database migrations from code deployments using the expand-contract pattern to maintain backward compatibility during traffic splitting, and store Terraform state in a centralized versioned Cloud Storage bucket with predefined IAM roles assigned to the CI/CD pipeline service account.
Safe, zero-downtime deployment pipelines on Google Cloud require decoupling database schema changes from application updates. The expand-contract pattern ensures that old and new revisions of a Cloud Run service can access the database simultaneously without breaking functionality during traffic splitting or rollbacks. Additionally, managing infrastructure automation with Terraform requires a secure, shared backend using a versioned Cloud Storage bucket with object locking to avoid state corruption, along with least-privilege predefined IAM roles for the deployment service account.

Step-by-Step Solution

1
Analyze database migration strategy for zero-downtime release management.
Identify that progressive traffic shifting across Cloud Run revisions requires database schema backward compatibility so both active revisions function concurrently.
Direct breaking schema migrations break active instances of the previous application version during rollout or rollback.
2
Evaluate Infrastructure as Code (IaC) state backend and security practices.
Select a remote versioned Cloud Storage bucket with object locking for Terraform state and restrict CI/CD identity permissions to predefined IAM roles.
Ephemeral state storage causes concurrency conflicts and state corruption, while primitive IAM roles expose the Google Cloud environment to unnecessary security risks.
3
Assess distractor configurations against Google Cloud operational best practices.
Reject choices recommending simultaneous breaking database migrations, local state storage with primitive IAM roles, or unverified quota limits.
These anti-patterns introduce downtime risk, state corruption, and operational quota exhaustion.

Key Concept

Zero-downtime deployment strategies require backward-compatible database schema evolution (expand-contract) and secure, centralized IaC state persistence using fine-grained IAM controls.
Rate this question