Terraform Fundamentals

A provider is a plugin that Terraform downloads and uses to translate your configuration into actual API calls against a specific platform. The 'aws' provider knows how to talk to AWS's API; the 'google' provider knows Google Cloud's API; the 'kubernetes' provider knows the Kubernetes API, and so on. Each provider is versioned independently and published to the Terraform Registry, and a configuration declares which providers it needs, and which version constraints to accept, in a 'required_providers' block. This separation matters because it's what lets Terraform's core engine — the part that computes dependency graphs, plans changes, and manages state — stay entirely generic, while all platform-specific knowledge lives in swappable plugins.

A resource is a single managed object: one S3 bucket, one virtual machine, one DNS record, one IAM role. Every resource block has the form 'resource "<provider_type>" "<local_name>" { ... }', where the provider_type (like 'aws_instance' or 'aws_s3_bucket') tells Terraform which provider is responsible for it and which API operations apply, and the local_name is just a name you choose for referring to this resource elsewhere within your own configuration — it never appears in the actual cloud platform. Inside the block's body, each provider type defines its own set of arguments: an 'aws_instance' resource has arguments like 'ami' and 'instance_type'; an 'aws_s3_bucket' has arguments like 'bucket' and 'versioning'. These arguments map directly to fields the provider sends to the underlying API, and the provider's documentation (auto-generated from its schema and published on the Terraform Registry) is the authoritative reference for exactly what's available for any given resource type.

Resources reference each other by their local names, and this is how Terraform discovers dependencies without you declaring them explicitly. Writing 'subnet_id = aws_subnet.main.id' inside an 'aws_instance' resource both wires the actual subnet ID into that instance's configuration and tells Terraform's dependency graph that the instance depends on the subnet — Terraform will always create the subnet first and the instance second, and will destroy them in the reverse order, entirely inferred from these references rather than from any ordering you had to specify manually.

A single Terraform configuration can combine any number of providers, which is routine in real infrastructure — a configuration might use the 'aws' provider to create compute resources, the 'cloudflare' provider to manage DNS records pointing at them, and the 'random' provider to generate a unique suffix for a globally-unique bucket name, all in the same set of files, with Terraform coordinating the dependency graph across all of them uniformly.

'terraform init' is the first command run in any new or freshly cloned configuration. It reads the 'required_providers' block, downloads the matching provider plugins (caching them locally so subsequent runs don't re-download), and initializes the backend that will store state (covered in depth separately — by default this is just a local file, but production setups almost always configure a remote backend here instead). 'init' needs to be re-run any time providers change, a module source changes, or the backend configuration changes; running it again when nothing's changed is harmless and fast, since it reuses what's already cached.

'terraform plan' is the command that makes Terraform genuinely useful rather than just risky. It compares your configuration files against the current state file (Terraform's record of what it believes already exists) and, for anything that differs, queries the real provider API to refresh that belief if needed, then computes exactly what would need to change to make reality match your configuration — without actually changing anything yet. The output lists every resource to be created (prefixed '+'), changed in place (prefixed '~'), or destroyed (prefixed '-'), along with the specific attributes changing on each. This is the single most important habit in Terraform usage: read the plan output carefully before applying, especially watching for unexpected destroys, since a plan that says it will destroy and recreate a database because of an immutable attribute change is a very different risk than one that's only adding a new, unrelated resource.

'terraform apply' re-runs the same comparison plan does, shows you the same plan output, and then — after you type 'yes' at the confirmation prompt (or if you pass a previously saved plan file, applies that exact plan without re-prompting) — actually calls the provider APIs to create, update, or destroy resources to match. Applying updates the state file to reflect the new reality as each change succeeds, which is what lets the next 'plan' correctly compare against an accurate baseline. In automated pipelines, 'terraform apply -auto-approve' skips the interactive confirmation, but this should only ever run against a plan that a human or a policy check already reviewed — never as a way to skip review entirely.

'terraform destroy' computes and applies the opposite operation: it plans the removal of every resource currently tracked in state, prompts for confirmation, and then deletes them all for real. It's standard practice for tearing down temporary environments (a feature-branch preview environment, a throwaway testing sandbox) cleanly, but it is irreversible against the actual infrastructure — there's no "undo" once a database has actually been deleted via the provider's API, even though the Terraform operation itself is simple and simply follows the plan it printed first.