In Terraform, what does `terraform apply -replace="aws_instance.web"` do, and when would you reach for it instead of editing the configuration?

## The problem it solves Terraform decides what to do by comparing three things: your configuration, the recorded state, and the refreshed real-world attributes. When all three agree, the plan is empty — even if the resource is useless. An EC2 instance whose user-data script failed halfway still has the right instance type, the right subnet and the right tags; nothing Terraform can see is wrong. `-replace` is the way to say "I know it looks fine; rebuild it anyway." ## What the option does `-replace=ADDRESS` is accepted by `terraform plan`, `terraform apply` and `terraform destroy`. Terraform resolves the address against the objects in state and plans a **replace** action for it: destroy the existing object, then create a new one from the same configuration. If the resource sets `create_before_destroy` in its `lifecycle` block, the replacement follows that order instead. Crucially, it changes the *plan*, not the state. Nothing is written until you apply, the replacement appears in the diff for a reviewer to see, and backing out means not applying. You can pass the option more than once to replace several objects in one run. ```bash terraform plan -replace='aws_instance.web[0]' -out=replace.tfplan terraform apply replace.tfplan ``` ## Why it replaced taint Before Terraform 0.15.2 the same intent was expressed as `terraform taint aws_instance.web`, which immediately wrote a "tainted" marker into state as a side effect, before anyone had seen a plan. Getting it wrong meant remembering `terraform untaint`, and in an automated pipeline the intent never showed up in the plan the reviewer read. `-replace=` folds the whole thing into the normal propose-then-approve cycle. `terraform taint` and `terraform untaint` still exist in Terraform 1.x for compatibility but are deprecated, and interviewers frequently use the pair to check whether you have kept up. The tainted *status* has not disappeared, because Terraform still sets it on its own: if a create-time provisioner fails, the object exists but its post-create steps did not finish, so Terraform marks it tainted and the next plan proposes a replacement. That is Terraform flagging a half-built object, not a user command. ## Addressing rules The address must identify **one resource instance**, not a whole resource with multiple instances: - plain resource: `-replace='aws_instance.web'` - with `count`: `-replace='aws_instance.web[1]'` (indexes start at 0) - with `for_each`: `-replace='aws_instance.web["blue"]'` - inside a module: `-replace='module.workers.aws_instance.node[0]'` Quote the address in a shell — brackets and quotes are otherwise eaten by the shell. There is no wildcard form; replacing thirty instances means thirty addresses, and if you find yourself doing that, the thing you actually want is a configuration change that forces replacement for everyone. ## What it does not do It does not replace the resources that *depend* on the one you named. Those may still show updates in the plan, because attributes they reference — an id, a private IP, an ARN — become unknown until the new object is created, so Terraform plans to update whatever consumes them. Read that part of the diff: replacing one instance can quietly re-register a load-balancer target or rewrite a DNS record. It is also not a substitute for fixing configuration. If a resource needs rebuilding every time some upstream value changes, that relationship belongs in the configuration — Terraform's `lifecycle` block has a meta-argument for exactly that — rather than in an operator's shell history. ## Operational care Replacement is destructive by definition. On a database, a volume, or anything holding data, destroy-then-create means the data is gone; a `prevent_destroy` lifecycle setting will make the plan fail outright, which is the guardrail working. Always plan first and read the diff before applying, and prefer applying a saved plan so that what was reviewed is exactly what runs. Finally, distinguish `-replace` from its neighbours. `-replace` changes *what action* is planned for an object. `-target` changes *which objects* are considered at all. They answer different questions, and mixing them up is the most common way this topic goes wrong in an interview.