HCL & Resources

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).

Terraform infers dependency edges from attribute references — writing aws_vpc.main.id inside another resource creates the edge automatically. depends_on is only for hidden ordering that exists at the provider but is never expressed as a reference in the configuration.

A for expression transforms one collection into another. Square brackets produce a list-like tuple: [for s in var.names : upper(s)]. Curly braces with key => value produce a map-like object: {for s in var.names : s => upper(s)}. An optional if clause filters elements out.

By default Terraform destroys a resource before creating its replacement. Setting create_before_destroy = true inverts that order — the new object is created first, then the old one is destroyed — so it only works when both objects can briefly exist at once.

ignore_changes lists attributes whose real-world value Terraform should stop reacting to, so the plan no longer proposes reverting them. The cost is silence: drift on those attributes is never reported again, and the configured value is used only when the object is first created.

The apply errors and Terraform marks the resource tainted in state: the real object still exists, but Terraform treats it as unusable. The next plan schedules it for destroy and recreate, so the whole provisioner sequence runs again on a fresh object.

Provisioners are opaque to Terraform: their effects are not in state, not visible in the plan, and not idempotent, and they need network reachability plus credentials from wherever Terraform runs. Prefer a baked image, cloud-init/user_data, or a config-management handoff.

It makes the resource conditional: one instance when the flag is true, zero when false. Because the block is still expanded by count, every reference needs an index — aws_s3_bucket.logs[0].id — or a splat wrapped in one() to yield null when the resource is absent.

prevent_destroy makes Terraform reject any plan that would destroy that resource, with an error instead of a deletion. It is a guardrail in the configuration only: delete the resource block itself and the guard disappears with it.

local-exec runs a command on the machine running Terraform itself. remote-exec runs commands on the resource that was just created, over SSH or WinRM, so it additionally needs a connection block with a reachable host and working credentials.

Terraform must expand a resource into addressed instances before it can render a diff, so for_each keys have to be known during plan. Fix it by keying on static input — variables, locals, or another resource's own keys — and letting the unknown values sit in each.value.

The filter is a literal string, so Terraform sees no dependency on the VPC and reads the data source during plan, before the VPC exists. The re-run succeeds only because the partial first apply left the objects behind. Reference the created resources directly instead of looking them up.

Terraform destroys in reverse dependency order, walking the same graph with its edges inverted: nothing is deleted until everything that depends on it is gone. Subnets go before the VPC, because the subnet referenced the VPC's id.

The iterator argument renames the temporary variable inside a dynamic block, which otherwise takes the block's label. For a list, key is the element index and value the element; for a set, key is identical to value and should not be used.

A dynamic block can only generate repeatable nested blocks defined by the resource, data source, provider or provisioner schema. It cannot produce plain arguments such as tags, nor meta-argument blocks like lifecycle, which Terraform must process before evaluating expressions.

It evaluates to a list of the id attribute of every element in aws_instance.web, in order. A splat only traverses attributes of a list-like value, so once you need filtering, a computed key, or output shaped as a map, you must write a for expression instead.

Rewrite the block to use for_each, then add a moved block for every instance mapping the old index address to the new key address. Terraform re-addresses the existing objects in state and the plan should report zero adds, changes and destroys.

Because the data source is re-read on every plan, most_recent = true resolves to whatever image the vendor published last, so an unrelated apply can silently replace running instances. Pin the image id as a reviewed input instead of resolving it at plan time.

Two objects reference each other, so Terraform's dependency graph is no longer acyclic and no valid order exists. Break the loop by moving one direction of the relationship into a separate resource that both groups depend on, rather than referencing each other inline.

An explicit edge is whole-object and untyped: Terraform cannot see which value matters, so it must plan conservatively, marking more attributes as "(known after apply)". It also serialises work that could have run concurrently and hides the real reason for the ordering.

Write blocks literally when the set is small and known; reach for a dynamic block mainly to hide repetition behind a reusable module's interface. When each item needs its own diff, lifecycle or targeted replacement, prefer separate resources instead.

templatefile(path, vars) reads a file from disk at plan or apply time and renders it as a string template. Only the names in the vars map are in scope inside the template - it cannot see Terraform variables, locals or resources - and referencing a name you did not pass is an error.

try() evaluates its arguments in order and returns the first that does not raise a dynamic type or traversal error - a missing attribute, a missing index, a failed conversion. It is not a general exception handler. Use lookup() for a missing map key with a default and coalesce() for a value that is present but null or empty.

Both assert something must be true and fail the run with your own error message if it is not. A precondition is checked before Terraform creates or updates the resource; a postcondition is checked afterwards and can inspect the resource's own attributes through self.

Terraform processes the lifecycle block before it evaluates expressions, so prevent_destroy and create_before_destroy accept only literal true or false — a variable reference is a configuration error. Environment-specific protection has to come from a provider argument, separate configurations, or pipeline policy.

remote-exec connects from wherever Terraform runs, so the CI runner must have a network route to the host, an open port, and valid credentials. The laptop had all three; the runner usually does not. The proper fix is to stop provisioning over the network.