In a team's Terraform pipeline, why does terraform plan run on the pull request while terraform apply runs only after the change merges to the main branch?

## The pipeline in one paragraph A team Terraform repository normally has exactly two automated paths. On a pull request, CI checks out the branch, runs `terraform init`, then `terraform fmt -check`, `terraform validate` and `terraform plan`, and publishes the plan output where the reviewer can read it — usually as a comment on the PR. Nothing is created. On a merge to `main`, CI checks out `main`, initialises again and runs `terraform apply`, frequently behind a manual approval. Everything else — nightly drift runs, ad-hoc destroys of ephemeral environments — is an extra path bolted onto that spine. ## Why plan belongs on the pull request HCL is not self-evident. A three-line change to a variable default, a module version bump, or an edit to a list can expand into a plan that replaces a database. Reviewing the code alone means reviewing intent; reviewing the plan means reviewing effect. The plan makes the effect concrete: how many resources are added, changed, destroyed, and which ones. The reviewer's real job is to look for the destroys and the replacements, and for a resource count that does not match the size of the diff. Running it in CI rather than on a laptop matters for a second reason: reproducibility. The pipeline runs a pinned Terraform version, a committed provider lock file and the same backend every time, so the plan the reviewer reads is the plan the machine will act on — not one produced by whatever versions happen to be on one engineer's machine. ``` terraform init -input=false terraform plan -input=false -no-color -out=tfplan ``` `-input=false` is the flag that separates automation from interactive use. Without it, a variable with no value makes Terraform prompt on stdin, and a CI job with no stdin simply hangs until its timeout. `-no-color` strips ANSI escapes so the output is readable when pasted into a PR comment. Terraform also honours the `TF_IN_AUTOMATION` environment variable, which suppresses the "run terraform apply next" style hints that make no sense in a pipeline. ## Why apply belongs to main Apply is the half that cannot be undone by closing a browser tab. Tying it to the merge commit gives three properties: 1. **One source of truth.** Whatever is on `main` is the claim about what production looks like. If apply could run from feature branches, two branches could fight over the same state and `main` would describe nothing. 2. **An audit trail for free.** "Who changed prod" becomes "which commit was applied", answerable from Git history plus the run log, without anyone reconstructing console activity. 3. **A credential boundary.** The plan job can hold read-only cloud credentials; only the apply job, which runs on a protected branch, holds credentials that can write. A pull request from an untrusted contributor therefore cannot reach anything that can be changed. The apply job typically also requires a human approval before it proceeds, because merge approval and change approval are not always the same decision — the reviewer approved the code, and someone still has to decide that now is the time to touch production. ## The failure modes this shape has The most common one is **plan/apply skew**. The plan on the PR was computed against the base branch and the state as they were at plan time. By the time the PR merges, another PR may have merged first, or someone may have changed the same resources by hand. Whatever the pipeline does at apply time — re-plan on `main`, or carry the reviewed plan file forward as an artifact — the reviewed plan is a snapshot with an expiry date, and a long-lived PR should be re-planned before it is trusted. The second is **the escape hatch that becomes the habit**. Everyone keeps credentials for emergencies, and every emergency apply from a laptop puts state ahead of `main`, so the next pipeline plan shows a diff nobody wrote. If break-glass access exists, applying from it should be loud, logged, and followed by a commit that makes `main` match reality again. The third is **partial coverage**. A pipeline that plans only the directories a PR touched will miss the case where a change to a shared module affects a root module the PR did not touch. Either plan everything, or make the affected-directory detection follow module dependencies rather than the file paths in the diff.