They can be proposed automatically, but should be approved by a person who has seen the plan, not only the code diff. An infrastructure fix can replace or delete a live resource, so the output of the plan step is the thing to review before anything is applied.
Why IaC is different from a library bump
A dependency upgrade changes code that your tests exercise. An infrastructure fix changes the environment the code runs in. Closing a security group, enabling encryption or changing a storage setting may force a resource to be recreated, interrupt traffic or lock out a service.
Terraform's plan command compares your configuration with current state and proposes changes without making them. Its documentation says that lets you check proposed actions before applying or share them for review. It also describes saving a plan with the out option, so apply carries out exactly the reviewed actions, an approach it describes as intended for automation. Saved plans may contain sensitive values, so treat them as sensitive artifacts.
A safe automated flow
- The tool proposes a code change in a pull request.
- CI runs a plan against a non production workspace, and attaches the plan output.
- A reviewer reads the plan, looking for any destroy or replace actions.
- Approval is by the resource owner, not only the pull request author.
- Apply happens through your normal pipeline, ideally from a saved plan.
- A post apply check confirms the finding is gone.
What to look at in the plan
| Plan signal | Meaning | Action |
|---|---|---|
| Update in place | Setting change | Usually fine, check the setting |
| Replace | Resource is destroyed and recreated | Check data, IPs, downtime |
| Destroy | Resource is removed | Stop and confirm |
| Many unrelated changes | Drift in state | Resolve drift first |
What to keep manual
Network rules, identity and access policies, encryption keys and anything holding data deserve a named approver and a change window. Low risk items such as adding a tag or enabling a logging option can move faster once you trust the process. See approval tiers by change type.
Production and rollback
Apply to non production first. Know how you would revert, including whether state can be restored. Rollback of a destroyed stateful resource may not exist, which is why destroy actions need a human.
Drift and state
If the real environment differs from what the code describes, a plan shows extra changes that have nothing to do with the fix. Resolve drift before trusting automated infrastructure changes, or the reviewer cannot tell intended from accidental. Keep state storage access limited as well, since a state file can hold sensitive values.
Where Safeguard fits
Safeguard's policies, gates and guardrails can express rules for changes before they merge, and its autonomous remediation is off by default with every category on Manual. Begin with a free scan.
Quick check
Is a code diff enough for review?
No. Read the plan, because it shows what will actually change in the environment.
Should destroy actions ever be automatic?
Keep them manual. They can remove data that cannot be restored.
Sources
Last reviewed: 19 October 2026.
