An autonomous fleet management company provisions its Google Cloud infrastructure using Terraform within a automated CI/CD deployment pipeline. The engineering team needs to enforce secure, environment-isolated state management across development, staging, and production while preventing concurrent state execution conflicts and state corruption. Which architecture best adheres to Google Cloud recommendations for Terraform remote backend state governance?
- Store each environment's state in a separate dedicated Cloud Storage bucket with Object Versioning enabled, utilizing native state locking and fine-grained IAM controls.Cevap
- BStore state files locally on the CI/CD runner's persistent disk to avoid remote Cloud Storage network latency during pipeline execution.
- CGrant the primitive Editor role to the CI/CD service account to ensure unconstrained permission to create and manage state resources across all environments.
- DAllow administrators to perform manual updates via the Cloud Console when pipeline locks stall, then force-refresh local state files.
Cevap
Store each environment's state in a separate dedicated Cloud Storage bucket with Object Versioning enabled, utilizing native state locking and fine-grained IAM controls.
According to Google Cloud best practices for Infrastructure as Code, Terraform state for different environments should be isolated into separate Cloud Storage buckets. Object Versioning ensures state history can be restored if corrupted, while GCS natively supports state locking to prevent race conditions during concurrent CI/CD pipeline runs.
Adım Adım Çözüm
Anahtar Kavram
Terraform Remote Backend State Governance in Google Cloud