Wow you really hate Terraform! It seems to me that your frustration with Terraform being "completely idiotic" is ultimately frustration with the underlying des

Wow you really hate Terraform! It seems to me that your frustration with Terraform being "completely idiotic" is ultimately frustration with the underlying design model. > If you write configuration to create a Security Group named "foobar", That configuration is a declaration: a security group named "foobar" should exist, with the declared properties. > and do a `terraform plan`, it will say it's about to create "foobar". That plan would be based on the most recent snapshot of the target "outside world" resources, which, if you haven't synced them recently (or at all) would probably be empty, resulting in `terraform plan` proposing to create foobar afresh. > When you go to apply, it will error out, saying "foobar already exists" Sure, which should hopefully make sense. You've declared a resource locally, and asked Terraform to "make it so" basically. But that resource is in conflict with an identical remote resource. You can `terraform refresh` or sync or whatever, to pull down the current relevant remote resource state locally, and then operate from there. Or you can manually blow away the remote foobar and retry. Or etc. But this kind of situation is not common. Terraform assumes and expects that the declarations (and state) it has access to locally is an authoritative source of truth for what the target remote system(s) should be. The config files define what should be running in AWS, not the other way around. It's fine if this isn't a fit for your use cases, but I don't think that means the entire tool is stupid or whatever. It just means it's not for you.