Terraform can only manage the resources that are explicitly defined in HCL files, in the exact way that they are defined (including based on a given module hierarchy). So if anything is either not mapped in an HCL file, or something changes in the files in an unexpected way, Terraform may refuse to do anything at all. And often this is based on computed values, meaning you don't know it's going to break until you apply, and then you have half-broken infrastructure in production.
The simplest is if you start renaming modules or moving resources in and out of different modules. Terraform will get confused and try to destroy everything rather than modify in place, even though it's the same resource, or it will sometimes just fail altogether, like it's trying to resolve some module that used to exist but no longer exists. Basically it doesn't comprehend that its logical resources are really real-world things, and leans so heavily on its logical mapping (based on things like module inheritance, which is a Terraform logic thing, not a real-world AWS resource thing) that it often just becomes unusable, and you have to perform heroics of moving about pieces of code and importing various things to work around it, if it works at all.
The bigger problem is when you have a resource which might be associated with another resource, like the various ways to represent IAM policies and roles in terraform resources. You can create the resource one way and deploy it, and then maybe someone modifies the existing real-world resource in a way that now depends on some other resource... but that resource isn't in a Terraform file. Terraform doesn't know what to do, so it will either clobber the modified state, or just die because it doesn't know how to resolve the conflict.
I would need to go back and curate a list of all the times that Terraform has just failed to do anything because something changed that it didn't expect, but basically it refuses to "fix" things that are unexpected. That, and the lack of automatic importing of existing resources is just absurd.... If Terraformer can make it work, Terraform could have too.
The simplest is if you start renaming modules or moving resources in and out of different modules. Terraform will get confused and try to destroy everything rather than modify in place, even though it's the same resource, or it will sometimes just fail altogether, like it's trying to resolve some module that used to exist but no longer exists. Basically it doesn't comprehend that its logical resources are really real-world things, and leans so heavily on its logical mapping (based on things like module inheritance, which is a Terraform logic thing, not a real-world AWS resource thing) that it often just becomes unusable, and you have to perform heroics of moving about pieces of code and importing various things to work around it, if it works at all.
The bigger problem is when you have a resource which might be associated with another resource, like the various ways to represent IAM policies and roles in terraform resources. You can create the resource one way and deploy it, and then maybe someone modifies the existing real-world resource in a way that now depends on some other resource... but that resource isn't in a Terraform file. Terraform doesn't know what to do, so it will either clobber the modified state, or just die because it doesn't know how to resolve the conflict.
I would need to go back and curate a list of all the times that Terraform has just failed to do anything because something changed that it didn't expect, but basically it refuses to "fix" things that are unexpected. That, and the lack of automatic importing of existing resources is just absurd.... If Terraformer can make it work, Terraform could have too.