Use the preview that matches your tool: terraform plan for Terraform, a change set for CloudFormation, helm template plus a server dry run for Helm, and kubectl diff for Kubernetes manifests. Each shows proposed effects, none guarantees success, and none judges security, so run policy checks on the output.
The decision table
| Tool | Preview | What it shows | What it does not do |
|---|---|---|---|
| Terraform | terraform plan | Proposed create, update and delete actions for a run | Judge whether results are safe |
| CloudFormation | Change set | How proposed changes may affect running resources, including replacements and deletions | Guarantee the update will succeed |
| Helm | helm template | Rendered manifests, computed locally | Server side testing such as API support |
| Helm | install with dry run set to server | A simulated install on the cluster | Policy beyond what the cluster enforces |
| Kubernetes | kubectl diff | Live object versus the would be applied version | Whether admission will accept it |
| Kubernetes | apply with dry run set to server | Admission, validation and conflicts without saving | What changes on the live object |
Notes on each
Terraform plan. Add the detailed exit code option so CI can tell no changes from changes. See the exit codes.
CloudFormation change sets. AWS says they preview how changes might affect running resources and whether critical resources will be deleted or replaced. CloudFormation only makes changes when you execute the change set. AWS also notes that change sets do not guarantee a successful update, because runtime conditions can still cause failures. Checks during change set creation cover common causes such as property syntax errors, name conflicts and service quota limits.
Helm. Template is local and fast. The dry run set to server option asks the cluster. See template versus dry run.
Kubernetes. Diff shows the effect on the live object and exits 1 when it finds differences. Server dry run shows admission results. Use both. See client versus server dry run.
What every preview misses
- Security judgement. A preview says what will change, not whether the result is risky.
- Drift you did not cause. A preview compares your change, not everything someone did by hand.
- Anything after deploy. Runtime behaviour needs monitoring.
So pair every preview with a policy check on its output: the plan JSON, the change set contents, the rendered chart or the diffed manifests.
A short routine for a pull request
- Render or plan with the tool's preview.
- Run policy checks on that output.
- Post the preview as a review artifact.
- Require approval for changes that delete or replace stateful resources.
- Deploy the exact thing you previewed.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a gate sits between the change and the merge. Your preview output is what that gate should be reading.
Quick check
Does a clean change set mean the update will succeed?
No. AWS states that change sets do not guarantee success, since runtime conditions can still cause failures.
Which preview needs no cluster access?
helm template renders locally. A kubectl diff or server dry run needs access to the cluster.
Safeguard runs policies and gates on pull requests, so a failed rule can hold a merge, and its dependency and SBOM scanning covers the packages your infrastructure code pulls in. You can try a free scan at gold.safeguard.sh/scan.
Sources
- Update CloudFormation stacks using change sets, AWS documentation
- terraform plan command reference, HashiCorp
- helm template, Helm documentation
- kubectl diff reference, Kubernetes documentation
Last reviewed: 19 October 2026.
