Your data engineering team manages cloud data infrastructure—including BigQuery datasets, Cloud Storage buckets, and Dataflow pipelines—across dev and prod environments on Google Cloud. You need to implement a continuous integration and continuous deployment (CI/CD) GitOps workflow using Terraform and Cloud Build that meets the following requirements: Provide a central, collaborative, and version-controlled mechanism for Terraform state management that prevents concurrency conflicts and state corruption. Automatically validate configurations and generate plan previews on proposed code changes before merging into environment branches. Enforce a strict multi-environment promotion sequence where changes are automatically applied only upon merging into the target environment branch. How should you structure your Terraform configuration, state storage, and Cloud Build triggers?

Configure a Cloud Storage backend with separate object prefixes for each environment and enable Object Versioning. Set up Cloud Build triggers to run `terraform init` and `terraform plan` on feature branch pull requests as required status checks, and run `terraform apply` only on merges to the `dev` and `prod` branches targeting their respective environment directories.: ### What the Recommended Architecture Is This solution implements a declarative **GitOps** pipeline using **Cloud Build** and **Terraform** configured with a **Cloud Storage (GCS) remote backend** across isolated environment branches and directories. ### How It Meets the Requirements - **Collaborative and Version-Controlled State**: Using the Cloud Storage backend (`backend "gcs"`) automatically provides state locking to prevent concurrent modification race conditions. Defining distinct prefixes (e.g., `prefix = "env/dev"` and `prefix = "env/prod"`) separates environment state files, while enabling **Object Versioning** on the bucket maintains an audit history and provides recovery points against accidental state corruption. - **Pre-Merge Validation and Planning**: Triggering Cloud Build on pull requests and feature branch commits executes `terraform init` and `terraform plan` against environment subfolders. Configuring these builds as required status checks under branch protection rules ensures that syntax errors or unintended infrastructure mutations are caught before code is merged. - **Controlled Multi-Environment Promotion**: Automated execution of `terraform apply` is strictly restricted to pushes/merges onto the designated `dev` and `prod` branches. Infrastructure is first tested in `dev`, and promoting the tested code via a pull request from `dev` to `prod` triggers the production `terraform apply` against the production environment directory. ### Key Advantages and Capabilities - **State Isolation**: Eliminates blast radius across stages by isolating state per environment directory and prefix. - **Automated Governance**: Protects the main deployment branches by mandating successful CI pipeline status checks before merging. - **Reproducibility and Auditability**: Maintains an immutable commit history in source control mapped directly to GCS-versioned deployment state revisions. ### Why This Is Optimal This pattern establishes an automated, repeatable, and secure workflow. It prevents unauthorized live changes, ensures code peer reviews include plan outputs, and cleanly separates environment state without managing complex external orchestrators.

Terraform Cicd Multienvironment Promotion Gitops | professional-cloud-data-engineer

Terraform Cicd Multienvironment Promotion Gitops

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your data engineering team manages cloud data infrastructure—including BigQuery datasets, Cloud Storage buckets, and Dataflow pipelines—across dev and prod environments on Google Cloud. You need to implement a continuous integration and continuous deployment (CI/CD) GitOps workflow using Terraform and Cloud Build that meets the following requirements:

Provide a central, collaborative, and version-controlled mechanism for Terraform state management that prevents concurrency conflicts and state corruption.
Automatically validate configurations and generate plan previews on proposed code changes before merging into environment branches.
Enforce a strict multi-environment promotion sequence where changes are automatically applied only upon merging into the target environment branch.

How should you structure your Terraform configuration, state storage, and Cloud Build triggers?

Store terraform.tfstate files directly within Git feature and environment branches. Configure Cloud Build triggers to execute terraform apply -auto-approve immediately whenever any commit is pushed to a feature branch, and delete the state file after deployment.

Configure a single global Cloud Storage backend prefix without Object Versioning to maintain unified state across all tiers. Configure Cloud Build to run terraform apply simultaneously against both dev and prod directories whenever a pull request is created.

Configure a Cloud Storage backend with separate object prefixes for each environment and enable Object Versioning. Set up Cloud Build triggers to run terraform init and terraform plan on feature branch pull requests as required status checks, and run terraform apply only on merges to the dev and prod branches targeting their respective environment directories.

Configure Terraform to run via Cloud Deploy delivery pipelines using Skaffold render stages. Store state in Compute Engine persistent disks, and use Cloud Functions to trigger terraform apply whenever a developer pushes commits to their local workstation branch.

Professional Cloud Data Engineer

Terraform Cicd Multienvironment Promotion Gitops

Related questions