Plan/Apply Workflow

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.

Refresh re-reads every resource recorded in Terraform state from the provider API, so the plan diffs real infrastructure against your config. Passing -refresh=false skips those reads — faster and easier on rate limits, but the diff then trusts possibly stale state.

Terraform's -target restricts a run to the addresses you name plus what they depend on, skipping the rest of the configuration and most of its refresh. The apply is therefore deliberately incomplete, which is why a full untargeted plan must follow it.

terraform validate checks a configuration against itself and the installed provider schemas: syntax, references, required arguments, attribute names and type consistency. It contacts no provider API and reads no state, so permissions, quotas and real-world values only surface at plan or apply.

CLI workspaces share one backend, one access policy, one credential set and one configuration, so a mistake in the selected workspace can reach production. Separate root modules give each environment its own state store, permissions and blast radius.

Terraform's -replace option plans a destroy-and-recreate of one named resource instance without any configuration change. You reach for it when the real resource is broken or half-built while its configuration and recorded state still look correct.

The plan job should get read-only access to the managed resources; only the apply job needs permission to create, change and destroy. Both should receive short-lived credentials issued per run through federation, not one static key sitting in CI forever.

terraform destroy proposes deleting everything this configuration currently manages, leaving the code untouched, so a later apply recreates it. Deleting a resource block changes the desired state permanently, so the next apply removes just that one object.

terraform init prepares a working directory: it wires up the backend, installs the providers the configuration requires, and fetches remote modules. Plugins land in .terraform/providers and module copies in .terraform/modules, while .terraform.lock.hcl is written beside your code.

A refresh-only run re-reads real infrastructure and proposes updates to the Terraform state file only — never to infrastructure. Plan shows what drifted; apply writes those observed values into state, leaving the configuration and the real resources untouched.

TFLint adds opinionated and provider-specific rules on top of schema correctness: unused declarations, deprecated idioms, naming conventions, and values a provider will reject such as a nonexistent instance type. Its provider rulesets ship that knowledge as plugins, so the checks stay offline.

Tests are .tftest.hcl files in the module directory or a tests/ subdirectory. Each run block executes a plan or an apply against the module and evaluates assert conditions. Apply runs create real infrastructure, which Terraform destroys when the file finishes.

terraform.workspace evaluates to the active workspace's name as a string. Configurations use it to prefix resource names or to look up per-workspace sizing, but branching real behaviour on it makes the same code mean different things in different states.

Serialise runs per state in the pipeline itself: one concurrency lane per root module, queueing rather than cancelling, so a second run waits its turn instead of racing. The state lock is a last-resort safety net, not a scheduler.

Passing the saved plan forward guarantees the apply performs exactly the change a human approved, with no re-plan in between. The costs are staleness once state moves on, and an artifact that contains sensitive values in the clear.

A saved plan is an opaque binary archive holding the configuration, a snapshot of prior state and every planned attribute value — including values marked sensitive, which are only masked in the printed output, not removed from the file. Protect it exactly like state.

It proposes changing the resource back to whatever the configuration says. Refresh-only updates state, never the .tf files, so the plan now compares an accurate state against an unchanged config and sees a difference it intends to correct.

Run terraform init and a non-interactive plan on a schedule against the deployed branch, and branch on -detailed-exitcode: 0 means no changes, 2 means the world differs from code, 1 means the run itself failed. Alert on 2, page on repeated 1.

A targeted apply evaluates and refreshes only the targeted subgraph, so the first untargeted plan afterwards shows the catch-up work: dependents that never picked up new attribute values, stale outputs, and real-world drift no run had refreshed since.

Plan JSON contains resolved values, so a scanner sees the attribute a resource will really have instead of an unresolved var or module reference. The cost is that it needs init, credentials and a successful plan, so it runs late and can never be a pre-commit check.

Terraform reads the active workspace from .terraform/environment in the working directory. A fresh CI checkout has no such file, so it silently uses default. Make it explicit with TF_WORKSPACE or a terraform workspace select step after init.

With -detailed-exitcode, terraform plan exits 0 when there are no changes, 1 on error, and 2 when the plan succeeded and changes are pending. Scripts use it to tell an empty diff apart from a real one without parsing output.

Destroy inside the workspace first, then select another workspace and delete it. Terraform refuses to delete a workspace whose state still tracks resources unless you pass -force, which discards the state and orphans the real infrastructure.

Terraform's -parallelism sets how many resource operations one run performs concurrently while walking the dependency graph, defaulting to 10. Lowering it thins the burst of API calls the run makes, which is the fastest way to get a throttled apply through.

A mock_provider block replaces the real provider, so Terraform walks the full plan and apply graph while generated values stand in for computed attributes. Nothing is created, no credentials are needed, and tests run in seconds — but no API ever validates the request.

Adopt a run service when the number of Terraform repositories makes hand-rolled jobs a maintenance burden, and when you want cloud credentials, state, run history and approvals owned by one system instead of scattered across CI configurations.