Why on earth is your state in git? The tool has built-in functionality to handle just these kinds of workflows. This reads a lot like hitting your thumb with the hammer and blaming hammers.
If that then create a separate locked down Git repo just for this. Protecting your state file was a big deal when I first reading about Terraform. It was really drilled in.
And that's why many people don't like the idea of a state file. Sure there are benefits, but there are also drawbacks. You now need another system to manage your state. You don't with ansible.
Ansible is a different system, with a subtly different use case. It generally manages a preexisting list of targets. In that sense, there is some initial "state" in Ansible, this being your inventory.
Terraform (or CloudFormation, or Pulumi, or Crossplane, for that matter) shine when you need to create resources. Think of the state as the inventory of what you've created (or imported).
If you think of the resource you are managing with ansible being your AWS account (or your VMWare system, or whatever), then I guess it makes more sense. That state (the account you manage) doesn't really change. (I don't use ansible but that is my understanding)
Having 3 different sources of truth (what is, in AWS, what should be, in the .tf, and something else -- in the statefile) can mean nasty 3 way merges, which i
But I don't manage thousands of different resources, I manage 50. It feels to me that the overhead needed to manage thousand struggles to scale down without bringing all the required baggage. It feels like kubernetes vs docker-compose.
That said, the concept of using an S3 bucked for storing state I saw elsewhere in these comments is an interesting idea so I may revisit terraform.
