GCP Professional Cloud Architect Practice Question

Your organization wants to standardize on Terraform for all Google Cloud projects across dev, test, and prod folders. The platform team must design the remote backend so that:

Terraform state is kept outside developer laptops and encrypted with a customer-managed Cloud KMS key.
Every change to the state file can be audited and previous versions can be restored.
Parallel terraform apply jobs triggered by different Cloud Build pipelines are automatically serialized to prevent corruption.
Each pipeline's service account receives only the least-privilege IAM role required to manage the state backend. Which solution best satisfies all of these requirements while minimizing ongoing operational overhead?

Create a dedicated infrastructure project containing a Cloud Storage bucket with object versioning enabled and protected by a customer-managed Cloud KMS key. Configure the Terraform gcs backend to store separate state files for each environment in that bucket, and grant every Cloud Build service account the Storage Object Admin role on the bucket.
Use Terraform Cloud as the remote backend with a single workspace per environment and rely on its default encryption; grant all engineers the Project Editor role for convenience when troubleshooting failed plans.
Store terraform.tfstate in a private Cloud Source Repository encrypted with a CMEK; allow Cloud Build service accounts Repository Writer access so they can push and pull the state file.
Mount a Cloud Filestore instance via NFS into each Cloud Build worker and write a shared terraform.tfstate file there; enable CMEK on the Filestore volume and grant Compute Admin to the pipeline service accounts.

Report Issue

Answer Description

A Cloud Storage bucket configured with object versioning retains an immutable history of every state-file update, simplifying audits and rollbacks. The Terraform gcs backend automatically writes a .tflock object to the bucket to obtain an exclusive lock, which safely serializes concurrent plans and applies initiated by separate Cloud Build pipelines. Applying a customer-managed Cloud KMS key to the bucket meets the encryption requirement. Granting each Cloud Build service account the Storage Object Admin role (rather than broader roles such as Storage Admin or Project Editor) limits access to only the actions required to read and write objects, satisfying least-privilege. The other choices either lack built-in locking (Cloud Source Repositories), rely on local or NFS storage that provides no automatic serialization or versioning, or violate security principles by omitting CMEK and granting overly broad IAM roles.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.