Terraform Associate key terms

Managing and provisioning infrastructure through machine-readable definition files instead of manual console clicks or ad-hoc commands, so environments can be versioned, reviewed, shared, and rebuilt repeatably.

A style of configuration where you describe the desired end state of your infrastructure and let the tool determine the steps needed, rather than scripting each individual command to run.

The property that applying the same configuration repeatedly yields the same result: a second run with no outside changes proposes no creates, updates, or destroys.

HashiCorp's human-readable language used in .tf files, combining a native block-and-argument syntax with expressions, functions, and features such as for expressions and conditionals.

A plugin that teaches Terraform how to call a particular platform's API, supplying that platform's resource types, data sources, and the configuration needed to authenticate.

A rule written in the required_providers block, such as ~> 5.0, that limits which provider releases Terraform may install so upgrades stay predictable for everyone sharing the configuration.

The public catalog that hosts providers and reusable modules, which Terraform can download automatically when a configuration references a provider or module by its registry source address.

The .terraform.lock.hcl file records the exact provider versions and checksums chosen for a configuration, so every collaborator installs identical packages; it should be committed to version control.

The first command of the core workflow: it downloads required providers and modules, initializes the configured backend, and writes the dependency lock file, preparing the working directory.

The set of proposed actions Terraform computes by comparing configuration, stored state, and real infrastructure; it lists which objects would be created, updated in place, replaced, or destroyed.

A read-only workflow command that builds and displays an execution plan without changing any infrastructure, letting you review what an apply would do first.

The workflow command that carries out the planned changes against real infrastructure, by default displaying the plan and requesting confirmation before any object is modified.

A command that plans and then removes every object currently tracked in state, effectively applying a configuration that contains no managed resources.

A check that configuration files are syntactically valid and internally consistent, such as correct argument names and value types, without contacting any provider API.

The primary configuration construct that declares one or more infrastructure objects of a given type, containing arguments for settings plus optional meta-arguments that alter behavior.

A parameter declared with a variable block that lets callers supply values at run time, optionally constrained by a type, a default, a description, and validation rules.

A result exported with an output block; it can be displayed after apply and consumed by a parent module or by another configuration reading remote state.

A named expression defined in a locals block and computed once inside a module, used to avoid repeating logic; locals cannot be set from outside the module.

A configuration block that reads information from a provider, such as the ID of an existing image or network, without creating or managing that object.

A meta-argument that creates a fixed number of instances of a resource or module addressed by numeric index, handy for identical copies or simple conditional creation.

A meta-argument that creates one instance per element of a map or set, keying each instance by the collection member, which is more stable than index-based addressing.

An explicit dependency meta-argument used when Terraform cannot infer ordering from expressions, forcing one resource or module to be processed after another.

Settings inside a resource that adjust how Terraform treats it, including create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by.

A reusable collection of Terraform configuration files that groups related resources and exposes variables and outputs, so one pattern can be reused many times.

The configuration in the directory where you run Terraform commands; it is the top-level module that calls any child modules and holds the working directory's state.

Any module invoked from another module through a module block; it receives values through its input variables and returns results through its outputs.

The required source argument of a module block, which can be a local path, a registry address, or a version-control URL, telling Terraform where to fetch the module code.

The stored mapping between resources in your configuration and real infrastructure objects, recording attributes and dependencies that Terraform uses to plan accurate changes.

A backend configuration that keeps state in a shared remote location such as object storage or HCP Terraform instead of a local file, supporting teamwork, locking, and durable storage.

A backend capability that prevents two Terraform operations from writing the same state at once, protecting it from corruption; not every backend type supports it.

A group of subcommands for inspecting and modifying state, including list, show, mv, rm, and pull, typically reserved for advanced repairs rather than routine changes.

A named, independent state instance kept inside one configuration directory, letting a single set of files manage multiple environments without duplicating code.

A command that attaches existing real infrastructure to a resource address in state so Terraform can start managing it, without generating matching configuration automatically.

The gap between what state records and what actually exists, caused by changes made outside Terraform or by manual edits, which surfaces when Terraform refreshes during a plan.

An operation that reconciles state with the real attributes of managed objects; it normally runs as part of planning and can be isolated using the refresh-only planning option.

HashiCorp's managed platform for running Terraform, offering remote runs, shared state, variable sets, policy enforcement, and a private registry for modules and providers.

The platform's unit of organization that holds a configuration, its variables, its state, and its run history, roughly equivalent to a working directory plus its state.

Policy-as-code rules evaluated between plan and apply in HCP Terraform, blocking or flagging runs that violate organizational constraints such as permitted regions or instance sizes.

An execution of plan and apply within HCP Terraform, triggerable by a version-control commit, the API, or the CLI, with policy checks and optional approvals in between.