Study HashiCorp Terraform 004 Providers and State: key concepts, common traps, and exam decision cues.
Once you understand that providers plug platforms into Terraform, the next step is understanding that Terraform can use more than one provider in the same configuration and still needs state to track what it manages.
| Idea | Why it matters |
|---|---|
| multiple providers | one configuration can manage more than one platform or more than one provider instance |
| state | Terraform needs a record of the managed objects and their mapping to configuration |
These ideas are related but different. Multiple providers expand what Terraform can manage. State helps Terraform understand what it already manages.
| Scenario | Strongest reading |
|---|---|
| AWS and GitHub in one configuration | multiple providers |
| two AWS regions with different provider settings | multiple provider instances, often with aliases |
| Terraform comparing planned changes to what exists already | state is involved |
| Trap | Better rule |
|---|---|
| assuming multiple providers remove the need for state | provider breadth and state tracking solve different problems |
| assuming state is just optional reporting | Terraform depends on state for safe planning and management |
| confusing provider aliasing with workspaces | aliases change provider instances; workspaces separate state contexts |
This objective mixes three ideas that the exam wants you to keep separate. Providers tell Terraform how to talk to platforms. State tells Terraform what it already manages. Workspaces separate state instances, not provider instances. If the scenario sounds like same code, different environment, think workspace or backend strategy. If it sounds like same run, different services, think multiple providers or aliases.