1.3.2. The Roles of State and Providers
💡 First Principle: State answers "which real thing is this block?" and providers answer "how do I talk to the platform that owns it?" — two distinct jobs that together let one declarative file manage anything with an API.
State is the bridge between your abstract configuration and concrete reality. When Terraform creates an AWS instance, it records that instance's real ID in state and binds it to your aws_instance.web block. Next run, it uses that binding to know this block already maps to a real instance — so it updates rather than recreates. State also stores resource metadata and dependency information that Terraform uses to plan efficiently.
Providers are plugins that translate Terraform's generic operations (create, read, update, delete) into specific API calls for a platform. The AWS provider knows how to call AWS APIs; the Cloudflare provider knows Cloudflare's. Terraform core stays platform-neutral and delegates all the platform-specific work to providers, which are downloaded during terraform init.
⚠️ Exam Trap: A frequent trap treats state as "just a cache you can delete and rebuild." You generally cannot safely rebuild state from configuration alone, because state holds the mapping to real resource IDs and metadata Terraform has no other way to recover. Losing state can mean Terraform no longer knows it owns existing resources — and may try to recreate them. Treat state as precious.
Reflection Question: If two engineers run terraform apply against the same configuration but with different state files, why might they get completely different plans?
