Your enterprise is establishing a continuous integration and continuous deployment (CI/CD) GitOps pipeline using Cloud Build and Terraform to manage infrastructure across dev, stage, and prod Google Cloud projects. Your security and compliance teams require the following: Remote state files must be protected against accidental deletion, concurrent writes, and cross-environment access. All proposed infrastructure changes must be automatically evaluated against compliance guardrails before being applied. Deployments must enforce environment promotion with strict least-privilege execution, preventing non-production pipelines from accessing production resources. Which pipeline design should you implement to meet these requirements?

Configure isolated Cloud Storage backend buckets per environment with Object Versioning and Uniform Bucket-Level Access enabled. Create Cloud Build triggers for pull requests that run `terraform plan` and validate the plan against policies using Open Policy Agent (OPA) or Conftest. Configure branch-specific triggers for promotion that impersonate environment-dedicated Service Accounts.: ### What this architecture is This architecture establishes an enterprise-grade **GitOps CI/CD pipeline** for Infrastructure as Code (IaC) on Google Cloud. It utilizes **Cloud Build**, **Terraform remote backends on Cloud Storage**, automated **Policy-as-Code (PaC)** validation, and **IAM Service Account Impersonation** to enforce least privilege across isolated environments. ### How it meets the requirements - **Secure Remote State Management**: Storing state files in distinct, isolated Cloud Storage buckets per environment prevents lateral privilege escalation between `dev` and `prod`. Enabling **Object Versioning** protects state files against corruption or accidental deletion, while the native Google Cloud Storage backend automatically handles state locking via Cloud Storage generation numbers. - **Automated Policy-as-Code Enforcement**: Triggering automated validation on Pull Requests (PRs) converts the `terraform plan` output to JSON and validates it against predefined compliance policies using tools like **Open Policy Agent (OPA)** or **Conftest**. This prevents policy-violating resources (such as overly permissive IAM bindings or public firewall rules) from ever reaching production. - **Controlled Environment Promotion and Least Privilege**: Structuring Git branches (or directories) with isolated Cloud Build triggers allows step-wise promotion across `dev`, `stage`, and `prod`. Cloud Build pipelines run using dedicated, environment-scoped Service Accounts via IAM impersonation, ensuring non-production build steps have zero access to production resources. ### Key advantages - **Blast Radius Containment**: Separate storage buckets and IAM identities prevent cross-environment contamination. - **Shift-Left Security**: Detects and halts non-compliant infrastructure changes during the pull request phase before any state modification occurs. - **Auditability and Drift Detection**: Every change is tracked through version control, and state file versioning maintains a historical ledger of infrastructure modifications. - **Native Concurrency Protection**: Cloud Storage backends provide built-in state locking to prevent race conditions during concurrent runs. ### Why this is optimal This approach aligns with Google Cloud architecture best practices for Terraform at scale. It completely segregates privileges, automates pre-merge governance, and eliminates long-lived static service account keys in CI/CD pipelines.

Iac Gitops Terraform Pipeline Design | Professional Cloud DevOps Engineer

Iac Gitops Terraform Pipeline Design

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 enterprise is establishing a continuous integration and continuous deployment (CI/CD) GitOps pipeline using Cloud Build and Terraform to manage infrastructure across dev, stage, and prod Google Cloud projects.

Your security and compliance teams require the following:

Remote state files must be protected against accidental deletion, concurrent writes, and cross-environment access.
All proposed infrastructure changes must be automatically evaluated against compliance guardrails before being applied.
Deployments must enforce environment promotion with strict least-privilege execution, preventing non-production pipelines from accessing production resources.

Which pipeline design should you implement to meet these requirements?

Configure isolated Cloud Storage backend buckets per environment with Object Versioning and Uniform Bucket-Level Access enabled. Create Cloud Build triggers for pull requests that run terraform plan and validate the plan against policies using Open Policy Agent (OPA) or Conftest. Configure branch-specific triggers for promotion that impersonate environment-dedicated Service Accounts.

Deploy a Compute Engine instance pool running a scheduled hourly cron job that pulls the main branch, disables state locking with -lock=false, and applies changes simultaneously to dev, stage, and prod projects using the default Compute Engine service account.

Store all Terraform state files in a single, centralized Cloud Storage bucket with Fine-Grained Object ACLs. Grant the default Cloud Build Service Agent roles/owner across the Google Cloud organization, and execute terraform apply --auto-approve immediately upon pull request creation.

Commit the encrypted Terraform .tfstate files directly to the Git repository branches using git-crypt. Configure Cloud Build to execute terraform apply locally on each developer's workstation using developer OAuth credentials before code check-in.

Professional Cloud DevOps Engineer

Iac Gitops Terraform Pipeline Design

Related questions