Terraform

A data block reads information about infrastructure Terraform does not manage and exposes it to the configuration. Terraform never creates, updates or destroys what a data block reads; a resource block declares an object Terraform owns for its whole lifecycle.

A dynamic block produces repeated nested blocks from a collection: for_each supplies one element per block and the content block holds the block body. For a security group you iterate a list of rule objects to emit one ingress block each.

Since Terraform 0.12, expressions are first-class, so you write var.name directly. The ${ } syntax is only for embedding an expression inside a larger string, such as "app-${var.env}". Quoting a whole expression adds nothing and Terraform warns that it is deprecated.

count addresses instances by numeric position, so deleting a middle list element shifts every later index and Terraform destroys and recreates those resources. for_each addresses instances by map key or set value, which stays stable, so unrelated instances are untouched.

Terraform reads a data source during plan whenever all of its arguments are already known. If any argument depends on a value that does not exist yet, the read is deferred to apply, its attributes become unknown, and every value derived from them renders as (known after apply).

Declare a second aws provider block with an alias argument and its own region, then set the meta-argument provider = aws.<alias> on each resource that belongs in that region. Resources with no provider argument use the unaliased default block.

Keys written into HCL get committed, cloned and copied, and cannot be rotated per run. Omit access_key and secret_key; the AWS provider then resolves credentials itself from environment variables, the shared AWS config files, or an attached instance or CI role.

required_providers declares every provider plugin a Terraform module depends on. The source argument is the registry address that tells Terraform exactly which plugin to download; version constrains which releases are acceptable. Without an explicit source, Terraform assumes the hashicorp namespace.

The calling module passes it with the module block's providers map, for example providers = { aws = aws.us, aws.replica = aws.eu }. The child declares the extra slot with configuration_aliases inside its required_providers entry, then selects it per resource.

The dependency lock file records, per provider, the exact version Terraform selected, the constraints it was selected under, and checksums of the provider packages. It belongs in Git: it is what makes every laptop and CI runner install byte-identical plugins.

Terraform locks state so only one write-capable run touches it at a time. Two concurrent applies read the same starting snapshot and then overwrite each other's write, so real resources end up with no record in state and later runs recreate or destroy them.

A remote backend keeps Terraform state in shared, durable storage such as an S3 bucket instead of one laptop's disk. Every engineer and CI job then reads and writes the same state, so runs cannot silently diverge, duplicate resources, or destroy each other's work.

Never commit terraform.tfstate, terraform.tfstate.backup, the .terraform directory, saved plan files, crash logs, or tfvars files holding secrets. A saved plan embeds the prior state plus planned attribute values, so it carries the same plain-text credentials state does.

Importing binds an already-existing object to a resource address in Terraform state. It creates no infrastructure and writes no configuration for you. The terraform import command needs the resource block written first; a Terraform 1.5+ import block runs inside plan and apply.

Terraform sees every declared resource as new and plans to create a second copy of everything, while the existing objects become orphans it can no longer read, change or destroy. Recovery means restoring a snapshot or re-adopting each object into state.

Terraform's type argument constrains what a caller may pass, rejecting mismatches during plan before anything is created. Type constraints come in three families: primitives (string, number, bool), collections (list, set, map), and structural types (object, tuple).

A Terraform locals block names a computed value for reuse inside one module. Unlike an input variable it cannot be set from outside — no tfvars, CLI flag or environment override — and unlike an output it exposes nothing to the module's caller.

An output block publishes a value out of the module that declares it. Root module outputs are printed after apply and readable with terraform output; a child module's outputs are read by its caller as module.<name>.<output_name>.

A validation block makes Terraform reject an unacceptable input value at plan time. It takes condition, a boolean expression over the variable, and error_message, the text printed when the condition is false — so nothing gets created.

A list is ordered and allows duplicates, a set is unordered and de-duplicated, a map is keyed by strings. Given ["b", "a", "a"], a set(string) variable yields two elements — "a" and "b" — with the caller's ordering and the duplicate discarded.

Flat composition keeps the dependency wiring and the resource addresses visible in one place. Deep nesting threads every input and output through pass-through variables at each level, hides what is actually created, and makes review, targeting and refactoring much harder.

Terraform's version argument works only for registry module sources. A Git-sourced module is pinned inside the source string itself, with a ?ref= query parameter naming an immutable tag or commit SHA. A branch name in ?ref= is not a pin.

Resources inside a child module are not addressable from outside it: module.<name> resolves only declared outputs, so module.network.aws_subnet.private is an error. The fix is to add an output to the module — its outputs are its public API, and adding one is a backward-compatible change.

The root module is the directory Terraform is run in; a child module is a directory called from a module block. Only the root takes backend configuration, tfvars and CLI variable values, and the provider configuration for the run.

Terraform accepts local paths beginning with ./ or ../, module registry addresses of the form namespace/name/provider, Git and Mercurial repositories, plain HTTP or S3/GCS archives. Terraform inspects the string's shape and prefix to pick the fetcher.

A plan on the pull request turns the proposed change into a reviewable diff before anything is touched. Apply runs from main so only merged, reviewed code ever changes real infrastructure, giving one source of truth and one audit trail.

terraform plan computes and prints the changes needed to make real infrastructure match the configuration, without changing anything. terraform apply makes those changes, pausing for an interactive confirmation first; -auto-approve skips that confirmation prompt.

terraform fmt -check reports formatting problems without rewriting anything and exits non-zero if any file would change, which is what makes it usable as a build gate. By default it looks only at the current directory, so nested modules need -recursive.

A Terraform CLI workspace is a separate state file for the same configuration in the same backend. Selecting one changes only which state Terraform reads and writes; the code, backend and credentials stay identical.

So the changes that get applied are exactly the changes that were reviewed. A bare terraform apply computes a brand-new plan at apply time; applying a saved plan file replays the recorded decisions instead, with no re-planning and no approval prompt.