Describe the Terraform workflow

Say you need to add one server to an environment Terraform already manages. You open the configuration, add a few lines that describe the server, run terraform plan to see exactly what will change, and then run terraform apply to carry it out. Those three moves, in that order, are the whole core Terraform workflow: Write, Plan, and Apply^[1].

Write: author the configuration

In the Write stage you author infrastructure as code in the HashiCorp Configuration Language (HCL), editing .tf files much as you would edit application source. While you iterate, running terraform plan gives quick feedback on whether the configuration expresses what you intend. The Write stage produces the durable artifact the rest of the workflow depends on: a text description of the infrastructure you want to exist.

Plan: preview without changing anything

Plan is the safety stage. When you run terraform plan, Terraform reads the current state of already-existing remote objects, compares the current configuration to the prior state, and proposes a set of change actions^[2] that would bring the real infrastructure in line with the configuration. The property that makes this safe is that the plan command alone does not actually carry out the proposed changes^[2]. It is read-only: it never creates, updates, or destroys a real object, so you can run it as often as you want while you check your work.

Apply: enact the approved plan

Apply is the only stage that changes real infrastructure. The terraform apply command executes the operations proposed in a Terraform plan^[3]. When you run terraform apply without handing it a saved plan file, Terraform creates a new execution plan as if you had run terraform plan, prompts you to approve that plan, and then performs the indicated operations^[3]. That approval prompt is the default gate between preview and change. You can skip it with -auto-approve, but the rule holds either way: only Apply provisions, updates, or destroys resources.

One command sits outside this loop. On a new or freshly cloned directory you first run terraform init, which prepares the working directory by installing the providers and modules the configuration needs and configuring its backend. Init is a prerequisite, not one of the three stages, so an answer that lists it alongside Write, Plan, and Apply is wrong. The figure traces the path from that one-time setup through the loop to infrastructure that matches your configuration.

The write, plan, apply loop is the same whether one person runs it or a team does; what changes on a team is that version control coordinates the work. Because a Terraform configuration is human-readable declarative text, it lives in a version control system (VCS) such as Git right alongside the application code it provisions, and every change to it carries an author, a timestamp, and a reviewable diff.

The individual loop

For a single practitioner the process mirrors ordinary application development. You author the configuration in an editor and store it in version control^[1], using iterative terraform plan runs for feedback as you write. When the configuration is ready you run terraform apply, review the plan it presents, confirm it, and push your repository. The plan you review at apply time is your last checkpoint before anything changes.

The team loop

A team keeps the same three stages but adds review through the repository. Team members work on separate branches so they do not collide with each other's work^[1]. When someone opens a pull request, the plan is surfaced for review so the team can ask questions, evaluate risks, and catch mistakes before any potentially harmful changes are made^[1]. After the change merges, the team applies it against the latest state. The diagram follows that path from a branch to an apply on the main branch.

This is why the configuration, and not the state file, is the artifact you commit. State can contain secrets and should be excluded from Git workflows^[4], and it is written and maintained by Terraform itself, whereas the configuration is the reviewed source of truth a team collaborates on. Reviewing the plan before apply is what makes the loop reliable: it lets a reviewer catch a mistake before it reaches real infrastructure. It lowers the risk of a bad change; it does not make one impossible, so treat the review as a safeguard, not a guarantee.

Every Terraform action you take at the terminal is one CLI (command-line interface) invocation, and they all share a single shape. Knowing that shape tells you where each flag belongs and how to look up any command you are unsure about.

The command pattern

Terraform commands follow one form, terraform [global options] <subcommand> [args], as laid out in the Terraform CLI command documentation^[5]. You type the terraform binary, then any global options, then a subcommand such as plan or apply, then that subcommand's own arguments. Order matters: global options come before the subcommand name, and the subcommand's arguments come after it. In terraform -chdir=infra plan -out=tfplan, -chdir=infra is a global option, plan is the subcommand, and -out=tfplan is an argument to plan. The figure labels each part of that example.

Global options

Global options change how Terraform runs regardless of the subcommand. Two to recognize:

Global option	Effect
-chdir=DIR	Switches to a different working directory before executing the given subcommand[5], so files Terraform would read or write in the current directory are read or written in DIR instead.
-version	An alias for the version subcommand[5]; prints the Terraform version.

-chdir is what you reach for in a continuous integration (CI) job or a wrapper script: instead of changing directory first, you point Terraform at the configuration directory, which keeps the invocation independent of where it is launched.

Getting help for any command

When you do not remember a command's options, ask Terraform. To get help for a specific command, use the -help option with the relevant subcommand^[5]; for example, terraform validate -help prints that command's usage and its options. The flag is -help (equivalently terraform -help <subcommand>), not -usage, -info, or -man.

TA-004 items on the workflow are short and definitional; they test whether you can name the stages, tell preview from change, and read the shape of a Terraform command. No provider-specific detail is required.

A frequent stem asks which steps make up the core Terraform workflow, or asks you to put them in order. The correct answer is Write, Plan, Apply. The classic distractor slips terraform init into that list; reject it, because init is one-time setup that prepares the working directory, not one of the three core stages.

Another stem probes preview versus change. When a question asks which command previews changes without modifying infrastructure, choose terraform plan; when it asks which command actually provisions, choose terraform apply. A distractor claims terraform plan alters resources, or that terraform apply never needs approval. Both are wrong: plan is read-only, and a plain terraform apply prompts for approval unless you pass -auto-approve.

A version-control stem asks what you commit or how teams collaborate. The right answers involve committing the human-readable configuration to a VCS and reviewing the plan on a pull request before apply. Watch two traps: committing the state file rather than the configuration (state can hold secrets and is not the reviewed artifact), and overclaiming that the review workflow makes a bad apply impossible, when review lowers risk rather than removing it.

A CLI stem shows a command line or asks how to get help. Match the pattern terraform [global options] <subcommand> [args]: global options such as -chdir precede the subcommand. To view a subcommand's options the flag is -help (as in terraform plan -help), not -usage or -man.