In Terraform, what do `terraform plan -refresh-only` and `terraform apply -refresh-only` do, and when would you reach for them?

## Two things that sound the same and are opposites Terraform has two refresh-related flags that are easy to confuse: - `-refresh=false` — do the diff, but **skip** reading reality. - `-refresh-only` — read reality, and skip **everything else**. A refresh-only run is a deliberately narrowed plan: the only actions it can propose are updates to the state file. It cannot create, update or destroy a real resource, which is why it is safe to hand to someone who is nervous about running Terraform at all. ## What `plan -refresh-only` reports It performs the ordinary refresh — one provider read per resource instance in state — and then prints the differences it found between what state recorded and what the API returned. Typical output opens with a note that objects have changed outside of Terraform, followed by attribute-level before/after pairs, and ends by telling you this plan would only update state. That is the concrete, Terraform-specific way to answer "did anyone touch prod?" It is strictly read-only against the backend as well: like any plan, it does not persist the refreshed values. ## What `apply -refresh-only` does Same refresh, then a prompt, then a state write. After approval, state contains the observed values. Nothing in the cloud changes. Two situations make this worth doing: 1. **The out-of-band change is legitimate and staying.** Someone bumped an instance size during an incident and the team agrees to keep it. Recording it in state first means the follow-up config edit is being written against an accurate baseline. 2. **State has drifted into inconsistency** — for example a resource was deleted out of band and you want state to reflect that before you plan, so the plan proposes a clean create instead of a confusing update. ```bash terraform plan -refresh-only # what changed behind our backs? terraform apply -refresh-only # record it in state, prompt to approve terraform apply -refresh-only -auto-approve # same, unattended ``` ## Why the standalone command went away Before 0.15.4, `terraform refresh` did the state update directly with no preview and no approval. Silently rewriting the single most important file in the workflow, with no diff to look at, was a bad shape — so it was deprecated and its behaviour re-expressed as `terraform apply -refresh-only -auto-approve`. Now the state write goes through the same plan-review-approve loop as everything else. Expect an interviewer to ask what you would run "instead of `terraform refresh`", and answer with the refresh-only apply. ## The limitation that catches people Refresh-only touches **state**, never **configuration**. Your `.tf` files still say what they always said. So after you accept a console change into state, the next normal plan sees config and state disagree and proposes to change the resource back to the configured value. Accepting drift into state is not the same as blessing it — that second step is a code edit and a review. ## Where it fits in a workflow - **Investigating an incident:** refresh-only plan first, because it cannot possibly change anything. - **Before a risky apply:** a refresh-only plan tells you whether reality still matches assumptions, separating "my change" from "someone else's change" in the diff you are about to approve. - **Cleanup after manual intervention:** record what the console did, then decide as a team whether the code adopts it or the next apply reverts it. ## What to say out loud Refresh-only is Terraform's read-the-world-without-touching-it mode: `plan -refresh-only` shows how state differs from reality, `apply -refresh-only` writes those observations into state, both leave infrastructure alone, and neither edits your configuration — so the reconciliation with the code is still a separate, deliberate step.