A distributed engineering team is collaborating on Google Cloud infrastructure provisioning using Terraform. The team is experiencing issues where concurrent execution of terraform apply causes state corruption and race conditions. In addition, the team needs to protect sensitive state data and ensure that previous versions of the state file can be restored if corrupted. Which backend configuration should you implement to satisfy these requirements?

Configure the Terraform gcs backend pointing to a dedicated Cloud Storage bucket with Object Versioning enabled and IAM access restrictions: ### What the GCS Remote Backend is The **Google Cloud Storage (GCS) backend** for Terraform is a native remote backend mechanism designed to store Terraform state files (`.tfstate`) securely in a centralized Cloud Storage bucket. Storing state centrally allows distributed teams to share a single, authoritative representation of their managed infrastructure. ### How it meets the requirements - **State Locking and Consistency**: The `gcs` backend natively provides **state locking** using Cloud Storage object preconditions and generations. Whenever an engineer or CI/CD pipeline runs `terraform plan` or `terraform apply`, Terraform acquires an exclusive lock on the remote state file. This prevents concurrent executions from running simultaneously and corrupting the state. - **State Recovery via Object Versioning**: Enabling **Object Versioning** on the Cloud Storage bucket preserves every previous iteration of the state file whenever updates are written. If a bad apply or accidental corruption occurs, administrators can easily roll back to a known healthy state generation. - **Security and Access Control**: Access to the state bucket can be strictly controlled using Google Cloud **Identity and Access Management (IAM)** roles (such as `roles/storage.objectAdmin` or `roles/storage.objectViewer`) and secured with customer-managed or Google-managed encryption keys. ### Key advantages - **Native Locking**: Does not require any external database or lock table configuration. - **High Availability**: Backed by Google Cloud's highly resilient storage infrastructure. - **Auditability and Compliance**: Integrates seamlessly with Cloud Audit Logs to track who accessed or modified state files. - **Automation Compatibility**: Integrates directly with CI/CD platforms such as Cloud Build and GitHub Actions. ### Why this is optimal The `gcs` backend natively satisfies all enterprise requirements for state consistency, concurrency locking, disaster recovery, and fine-grained security without adding architectural complexity or third-party overhead.