Terraform fundamentals
Terraform Core is deliberately empty: providers do the talking, state does the remembering
Ask what the terraform binary itself knows about AWS, Azure, or any other platform, and the answer is nothing: Terraform Core contains no infrastructure-specific logic and ships with no resource types of its own. Providers, plugins that terraform init installs, supply every resource type and act as the bridge that translates your configuration into a platform's API (application programming interface) calls, while state is the database that maps each resource instance in your configuration to the real object it manages. The classic trap is assuming Terraform "just knows" either side: without the matching provider it cannot reach a platform at all, and without a state entry it does not know a real object exists.
The domain unfolds in four steps, from declaring plugins to trusting state
Install and version Terraform providers comes first: a configuration names each plugin it needs in required_providers, constrains acceptable releases with operators such as ~>, and lets terraform init install them and record the exact selections in the dependency lock file, .terraform.lock.hcl. How Terraform uses providers then explains what those plugins are: separately versioned components that add resource types and data sources, and translate them into a platform's create, read, update, and delete calls. Writing configuration with multiple providers covers the provider block, the default (unaliased) configuration, alias for extra configurations such as a second region, and passing aliased configurations down to child modules. How Terraform uses and manages state closes the loop: what terraform.tfstate records, why it doubles as a performance cache, and why its plaintext contents make it sensitive and worth locking.
When two answers both work, pick the explicit, reproducible one
Nothing in this domain happens on its own: providers install only when terraform init runs, an aliased configuration is used only where a bare provider = aws.west reference selects it, and state changes only when Terraform itself rewrites the file. So when two options both seem to work, prefer the one that writes the choice down and lets Terraform act on it: a version constraint plus a committed .terraform.lock.hcl over an unpinned download, an explicit providers map on a module block over hoping an alias is inherited, and the terraform state commands over hand-editing terraform.tfstate. Distractors here usually smuggle in an implicit step, such as a quoted "aws.west" string where a bare reference is required, or a sensitive flag that supposedly scrubs secrets out of state.
The four steps of Terraform fundamentals (and where each is covered)
| Step | Question it answers | Key mechanisms | Drill into |
|---|---|---|---|
| 1. Declare and install | Which plugins, at which versions? | `required_providers`, `version` constraints, `terraform init`, `.terraform.lock.hcl` | Install and version Terraform providers |
| 2. Know what a provider does | How does Terraform reach a platform's API? | Provider plugins, resource types, data sources, API translation | How Terraform uses providers |
| 3. Configure one or many | How do I run one provider several ways? | `provider` block, default configuration, `alias`, `providers` on modules | Writing configuration with multiple providers |
| 4. Let state remember | How does Terraform know what it built? | `terraform.tfstate`, dependency metadata, caching, locking | How Terraform uses and manages state |