Moving from local backend to remote backend, which backend would not work?

Moving from local backend to remote backend, which backend would not work?

• A. Amazon S3
• B. Artifactory
• C. Git
• D. Terraform Cloud

Answer: (C)

The key idea is that remote backends must provide safe, coordinated access to the Terraform state so multiple users or processes can work without corrupting it. Git isn’t designed for that role: there’s no built-in, reliable locking or atomic update mechanism for state across concurrent operations. Pushing a new state file to a Git repository can lead to conflicts, corrupt state, or race conditions, and sensitive data in the state could end up in the repository history. In contrast, backends like Amazon S3 (often with DynamoDB for locking), Artifactory, and Terraform Cloud are built to store state remotely with proper locking, versioning, and concurrency control, making them suitable for moving from a local backend. Therefore, Git would not work as a remote backend for Terraform state.

The key idea is that remote backends must provide safe, coordinated access to the Terraform state so multiple users or processes can work without corrupting it. Git isn’t designed for that role: there’s no built-in, reliable locking or atomic update mechanism for state across concurrent operations. Pushing a new state file to a Git repository can lead to conflicts, corrupt state, or race conditions, and sensitive data in the state could end up in the repository history. In contrast, backends like Amazon S3 (often with DynamoDB for locking), Artifactory, and Terraform Cloud are built to store state remotely with proper locking, versioning, and concurrency control, making them suitable for moving from a local backend. Therefore, Git would not work as a remote backend for Terraform state.