[sl1ck731]

The author describes Terraform and CloudFormation as "imperative". This doesn't seem correct to me, although you can force a sort of imperative flow by manually defining your dependencies in a specific order. I have only a little experience with Ansible but I would say that is the only major imperative-ish IaC (at least the way I used it) aside from bash scripts or working with SDK's directly.

[halbritt]

Terraform in and of itself is declarative, but it behaves in an imperative sort of way with the various backends that it supports.

These shortcomings all manifest themselves in how state is managed. Terraform state is declaratively described, and it may or may not match the state of the backend. Once this state drift exists, it becomes difficult to correct.

This is my primary criticism of Terraform and one of the reasons I prefer Kubernetes. I know it's an apple to orange comparison, but in Kubernetes there is both declarative configuration and active reconciliation. You have both current state and desired state and a set of controllers seeking to make them match. I'd love to see this implemented with Terraform.

[mwarkentin]

Terraform attempts to refresh its state from the source of truth (eg aws apis) before planning. It’s not always possible, but often it should work just fine even if you’ve modified a resource outside of terraform.

[borplk]

Terraform mostly can make the current state match the desired state but the challenge is the real world side effects such as the state that exists in the database that is about to get destroyed or down-time of services that depend on the resources being managed and so on. So you can't blindly allow it to do what it wants.

[cbsmith]

Yeah, that's the wrong distinction between Terraform/CloudFormation and Kubernetes. Terraform/CloudFormation try to be declarative. The distinction is more that Terraform/CloudFormation are about provisioning infrastructure.