Terraform validate checks that your configuration is syntactically valid and internally consistent. Plan shows what would change in a specific run. Neither one judges whether a setting is risky, such as a public bucket. A separate security or policy scan does that, so a safe pipeline runs all three in order.
What each step answers
| Step | Question it answers | What it does not do |
|---|---|---|
| terraform validate | Is the code well formed and internally consistent? | Check remote services, state or provider APIs |
| terraform plan | What will change in this workspace with these inputs? | Judge whether the end state is safe |
| Security or policy scan | Does this config or plan break a rule we care about? | Prove the cloud matches the code |
Validate in more detail
The reference says validate checks files in a directory and does not validate remote services such as remote state or provider APIs. It runs regardless of variables or existing state, which makes it most useful for reusable modules. It checks things like attribute names and value types. It is safe to run automatically, for example on save in an editor or as a CI test step.
To validate without touching a configured backend, initialise with the backend disabled. The reference documents terraform init -backend=false for this.
Plan in more detail
Plan includes an implied validation, but in the context of a particular run: a specific workspace and set of variable values. It is the first step that sees real inputs, so it is the first step that can show you a surprise, such as a resource being replaced rather than updated.
Where security checks belong
A valid, planned configuration can still open a database to the internet. The language has no opinion on that. Two places work well for checks:
- On the code, early, in the editor and pull request. Fast feedback, but it cannot see resolved variable values.
- On the plan, converted to JSON, which has real values after evaluation. Slower, more accurate.
Run both if you can. Early checks catch most mistakes cheaply, and plan checks catch the ones that only appear once values are resolved. For more on choosing, see where to enforce policy as code.
A simple pipeline order
- Format check.
- Validate, with the backend disabled.
- Scan the code.
- Plan with the detailed exit code.
- Scan the plan JSON.
- Human approval, then apply the saved plan.
Try it yourself
Click through it at your own pace, or open it full screen.
In the demo, notice which checks run before a merge is allowed. Your validate, scan and plan steps are the same idea applied to infrastructure code.
Quick check
Does terraform validate need cloud credentials?
No. It does not validate remote services. It needs an initialised directory, and you can initialise with the backend disabled.
Can terraform plan tell me a setting is insecure?
No. It shows proposed changes. Judging risk needs a policy or security check on the code or plan.
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
Last reviewed: 19 October 2026.
