What you propose is computationally rather expensive, and on an API level really hard to implement uniformly. And thus the state was born. Trying to do it with

What you propose is computationally rather expensive, and on an API level really hard to implement uniformly. And thus the state was born. Trying to do it without state has been tried plenty of times, and it's bad. (Chef, SaltStack, Ansible, CFengine, Puppet to name a few) It only works somewhat okay if you're simply writing to a single managed unit, i.e. a file. You know what all the contents of the file have to be, so you can replace it wholesale. This does not work for a graph of resources that interact with each other. Separately, this also doesn't work with a shared responsibility model and doesn't work with deleted code. Terraform has a state because that is required to solve the problem in a reasonable manner. It doesn't have state just because it was thought to be a fun exercise ;-) If the problem being solved is not _your_ problem, it is highly likely that using terraform at all is also not going to help you. > If I lose the state, or it gets corrupt, I'm in for a world of hurt with terraform. And that's why you secure and version your state. I.e. using S3 and versioning and a restrictive policy.