A streaming media platform uses Terraform within automated Cloud Build pipelines to provision short-lived staging environments. During high-frequency deployment periods, multiple pipeline runs targeting the same Google Cloud Storage remote backend fail because concurrent execution attempts cause state file conflicts and partial environment provisioning. Which configuration should the DevOps team implement to ensure state locking and state recovery for reliable environment provisioning?
- Configure the Terraform backend using the standard Google Cloud Storage (gcs) backend type and enable Object Versioning on the Cloud Storage bucket.Answer
- BStore state files locally within the Cloud Build build container workspace and run a post-build script using gsutil rsync to push state files to storage.
- CAssign the IAM Owner primitive role to the Cloud Build service account to allow it to override concurrent state locks dynamically.
- DEstablish a VPC Network Peering connection between Cloud Build execution networks to route state traffic transitively without using Cloud Storage API locks.
Answer
Configure the Terraform backend using the standard Google Cloud Storage (gcs) backend type and enable Object Versioning on the Cloud Storage bucket.
The standard Google Cloud Storage (gcs) backend for Terraform natively supports state locking by utilizing GCS object generation and metageneration preconditions. When combined with GCS Object Versioning, state files are protected against concurrent modifications and accidental corruption during automated CI/CD environment deployments.
Step-by-Step Solution
Key Concept
Terraform State Locking and Remote State Management on Google Cloud Storage