An enterprise engineering team is configuring an automated infrastructure deployment pipeline using Terraform on Google Cloud. The team must establish a remote state backend that prevents concurrent pipeline executions from causing state corruption, protects historical state revisions against accidental deletion, and eliminates the need to store long-lived service account keys inside the CI/CD environment. Which TWO configuration steps should the team implement to fulfill these security and operational requirements?
- Configure the Terraform backend using a Google Cloud Storage bucket with Object Versioning enabled.Answer
- Configure the Terraform Google provider to use Service Account impersonation with short-lived credentials for execution.Answer
- CGrant the primitive Owner role on the state bucket to the pipeline service account to bypass granular IAM evaluation during state file writes.
- DDisable state locking in the Terraform backend configuration block to ensure parallel execution stages do not time out.
Answer
To securely manage Terraform state and authentication in Google Cloud, the team must use a Cloud Storage backend with Object Versioning enabled and utilize Service Account impersonation with short-lived credentials instead of static keys.
Configuring a Google Cloud Storage backend with Object Versioning enabled satisfies state protection requirements by offering native state locking and history preservation. Additionally, employing Service Account impersonation allows the CI/CD pipeline to request short-lived access tokens dynamically, completely removing the risk associated with static JSON key storage.
Step-by-Step Solution
Key Concept
Terraform Cloud Storage Backend Security and Impersonation Best Practices