Why Terraform Workflows Break Down Across Multiple Teams

Terraform workflows break down when multiple teams independently build their own pipelines, leading to a lack of agreement on common practices. Each team creates a repository with a slightly different GitHub Actions workflow, multiple state backends, and runs terraform apply from their laptops during incidents. Some teams perform a plan step but omit policy checks; one team stores AWS access keys in repository secrets that haven't been rotated since the creator left the organization.

To address these issues, Terraform centralization is required. This means unifying state and credentials, execution, policy, and visibility under shared ownership. Many teams start by centralizing execution since it's the most visible pain point, but governance remains loose due to the absence of centralized state and credentials management.

To centralize Terraform state and credentials, teams should first separate state per team and per environment, then remove static credentials. A shared remote state backend with OIDC federation can be implemented to ensure secure access. Managed platforms like HCP Terraform or Spacelift can simplify this process by issuing short-lived credentials per run. The native S3 locking feature in Terraform 1.10 and 1.11 eliminates the need for a DynamoDB table for state locking.

Centralizing Terraform execution can be achieved through three options: reusable CI workflows, Atlantis (an open-source pull request-driven Terraform runner), or managed platforms like HCP Terraform or Spacelift. A reusable CI workflow involves publishing a central workflow_call workflow and referencing it in each team's repository.

Atlantis provides server-side governance, eliminating the need to share credentials across repositories. Managed platforms automatically run policy checks and provide drift detection with automatic reconciliation.