A financial services organization is establishing an automated deployment framework using Terraform to manage core Google Cloud infrastructure across multiple enterprise projects. To ensure environment stability, state integrity, and adherence to security best practices, the security team requires that the pipeline prevents concurrent modifications, maintains state history, and operates under least privilege. Which combination of actions should the architecture team implement?
- Configure a Cloud Storage remote backend with object versioning and state locking enabled, and assign the pipeline service account fine-grained predefined roles along with the Service Account User role on required resource service accounts.Answer
- BStore the Terraform state files in a standard local directory synchronized to Cloud Storage without versioning, and execute pipeline jobs using the project Owner primitive IAM role.
- CConfigure a Cloud Storage remote backend with object versioning, and grant the Service Account Admin role to the pipeline service account so it can attach service accounts to Compute Engine instances.
- DStore Terraform state files in unversioned local storage during deployment pipelines to increase execution speed, relying on git repositories for state history.
Answer
Configure a Cloud Storage remote backend with object versioning and state locking enabled, and assign the pipeline service account fine-grained predefined roles along with the Service Account User role on required resource service accounts.
The correct architecture uses Google Cloud Storage as a remote Terraform backend with versioning and object locking to protect infrastructure state consistency across continuous deployment runs. Concurrently, security best practices dictate using minimal predefined IAM roles and assigning roles/iam.serviceAccountUser when resources need to be provisioned with attached service accounts.
Step-by-Step Solution
Key Concept
Terraform Cloud Storage Remote Backend State Locking and IAM Least Privilege