Terraform & Infrastructure as Code

One managed infrastructure object. A resource block names a type and a local name, and together those form its address, which is how Terraform tracks it in state. The address is the identity, so renaming a resource block makes Terraform plan to destroy and recreate it.

A plugin that knows how to talk to one API. The AWS provider translates Terraform's create, read, update and delete operations into AWS API calls. Providers are versioned separately from Terraform and are downloaded during init.

A read-only lookup of something Terraform does not manage. It gives you attributes of an existing object without taking ownership of it, so destroying your configuration never destroys what a data source read.

A named input to a module or root configuration, with an optional type, default and validation rule. Variables are how the same code serves dev and prod without being copied.

A value a module publishes to its caller, or that the root configuration prints after apply. Outputs are the module's public interface: anything not exposed as an output is not reachable from outside.

A named expression computed inside a configuration. Unlike a variable it takes no external input, so it is purely a way to name something you use more than once and keep the logic in one place.

An argument is something you set on a resource. An attribute is something you read from it, including computed values that only exist after creation. Many names are both, which is why the distinction only becomes obvious when you try to read something before it exists.

Any value computation in HCL, from a literal to a reference to a conditional to a function call. Terraform's language is expression-oriented rather than procedural, so there are no statements, loops or assignments in the usual sense.

Managing infrastructure by describing it in files that are version-controlled, reviewed and applied by a tool, rather than by clicking in a console or running ad-hoc commands. The value is not automation on its own, it is that the current intended shape of your infrastructure is a readable artifact with a history.

You describe the desired end state and the tool works out the steps. Terraform is declarative. The opposite, imperative, means you write the steps and the end state is whatever they produce.

Running the same operation repeatedly produces the same result as running it once. In Terraform this is why apply on an unchanged configuration reports no changes rather than creating duplicates. It is a property of the whole model, not a feature you enable.

Replacing a resource rather than modifying it in place. Instead of patching a running server, you build a new image and launch a new instance from it. Terraform supports this naturally, since many attribute changes force a replacement anyway.

A directory of Terraform files used as a reusable unit, taking variables in and returning outputs. Every configuration is already a module, the root module. A child module is one you call with a module block.

The directory you run Terraform in. It is the entry point, it owns the backend configuration and the provider configuration, and it is the only module that reads .tfvars files or environment variables.

A catalogue of publishable modules and providers, either the public Terraform Registry or a private one. Source a module by registry address and pin its version, the same way you would a library dependency.

Creating multiple instances of a resource, addressed by numeric index. The problem is that the index is positional, so removing an item renumbers everything after it and Terraform plans to destroy and recreate resources you never touched.

Creating multiple instances addressed by a map key or set value rather than by position. Removing one entry affects only that entry. This is the reason to prefer for_each over count for anything that is a collection of distinct things.

Generating repeated nested blocks inside a resource from a collection. Needed because a nested block is not an argument, so you cannot simply assign a list to it.

An argument Terraform itself understands on any resource, rather than one defined by the provider. The set is count, for_each, provider, depends_on, lifecycle and providers.

An explicit dependency for a relationship that exists in reality but does not appear in any expression. It is a last resort, because Terraform already infers dependencies from references, and reaching for it usually means a missing reference.

Per-resource overrides of Terraform's default behaviour. create_before_destroy for zero-downtime replacement, prevent_destroy as a guard, and ignore_changes for attributes something else legitimately manages.

Reality no longer matches what state records. Almost always caused by a change made outside Terraform: a console edit, another tool, or a service modifying its own resource. Terraform detects it during refresh and plans to bring reality back in line with the configuration.

A JSON document mapping each resource address in your configuration to the real object it manages, plus every attribute Terraform last observed. It is what lets Terraform know that aws_instance.web means i-0abc123, and losing it means Terraform can no longer connect your code to anything.

Storage for state outside the working directory, usually an S3 bucket, plus locking. It is what makes Terraform usable by more than one person, and it also keeps state off laptops and out of git.

A mutual exclusion held for the duration of an operation that writes state, so two people cannot apply at once. Without it, concurrent applies each write their own view of state and one of them silently loses resources.

Reading the current attributes of every managed resource from the provider and updating state to match, without changing anything real. Terraform does this at the start of a plan by default, which is how drift is detected.

A real object that no state file references. It keeps existing, keeps costing money, and no Terraform run will ever touch it. Usually the result of a lost or overwritten state file, or a state rm without a follow-up.

Bringing an existing real resource under management by writing it into state. It changes only state, never reality. You still need a matching resource block in your configuration, or the next plan will propose destroying what you just imported.

Removing a resource from state without destroying it. Terraform forgets the resource exists; the real object survives untouched. The counterpart to import, and the correct tool when handing a resource over to another configuration.

A configuration block declaring that a resource used to have a different address, so a rename or a move into a module is treated as a rename rather than a destroy and create. It replaced the manual terraform state mv for most refactors.

A value marked so Terraform redacts it from plan and apply output. Note carefully that this only affects display: the value is still stored in state in plaintext, so state itself must be treated as a secret.

Preparing a working directory. Downloads providers and modules, configures the backend, and writes the dependency lock file. It touches neither state contents nor real infrastructure, and it must be rerun whenever providers or module sources change.

Refreshing state, then computing the difference between configuration and state, and printing what it would do. It is read-only with respect to your infrastructure, which makes it the right thing to run in a pull request.

Executing a plan. It takes the state lock, calls provider APIs in dependency order, and writes the resulting state. If it fails partway, some resources exist and state records them, so rerunning continues rather than starting over.

Planning and applying the removal of everything in state. It is apply with every resource marked for destruction, in reverse dependency order.

Checking syntax and internal consistency without contacting any provider API or reading state. Fast enough to run on every commit, and it catches type errors, unknown attributes and undeclared variables.

Rewriting configuration files to canonical style. Purely cosmetic, and worth enforcing in CI with -check so formatting never appears in a diff alongside a real change.

The prefix on each line of a plan tells you the action. + create, - destroy, ~ update in place, -/+ destroy then create, +/- create then destroy (with create_before_destroy), and <= a read from a data source.

A block running a script during create or destroy. Officially a last resort, because it breaks the declarative model: a failed provisioner marks the resource tainted, and Terraform has no way to know what the script did.

Multiple named states within one backend and one configuration. Useful for short-lived parallel copies of the same thing, and a poor fit for dev versus prod, because the environments then share provider configuration and cannot diverge.

.terraform.lock.hcl, recording the exact provider versions and their checksums. It belongs in version control, so every machine and every CI run resolves the same providers.

The operators controlling which versions are acceptable. ~> 5.1 allows 5.1.x but not 5.2. >= 5.0, < 6.0 allows any 5.x. An unpinned dependency means an unrelated init can change your infrastructure.