What does `terraform validate` actually check, and why can a configuration pass validate and still fail during apply?

## What validate is for `terraform validate` answers one question: is this configuration internally coherent? It is the second-cheapest check in the Terraform toolchain, sitting just above `terraform fmt -check`, and it is the last one that costs nothing and touches nothing. Concretely it catches: - syntax that parses but does not make sense — a reference to `var.regionn`, an expression pointing at a resource address that is not declared; - schema violations — an argument name that does not exist on that resource type, a required argument that is missing, a block used where the schema expects an attribute; - type inconsistencies — passing a list where the declared type is a string, or a module input whose type constraint does not accept the value being wired in; - duplicate declarations — two resources with the same type and name, two variables with the same name. ## Why it needs `terraform init` first Most of the above is impossible without provider schemas. Terraform has no built-in knowledge that `aws_instance` has an `instance_type` argument; that comes from the AWS provider plugin. So validate requires an initialized working directory: the providers must be downloaded into `.terraform` and any child modules must be installed. Run it in a fresh clone and it tells you to run `init` first. This creates an awkward-looking dependency — an offline check that requires a download step — and the standard resolution is: ```bash terraform init -backend=false terraform validate ``` `-backend=false` skips backend initialization, so the job never reaches for the remote state bucket and never needs credentials. Providers are still installed, so schema checking works. This is the shape you want for a validate job that runs on a fork's pull request, where handing out cloud credentials would be a bad idea. ## What it deliberately cannot see Validate never talks to a provider's API. Everything that depends on the real world therefore passes validation and fails later: - an EC2 instance type that is valid syntax but does not exist in that region; - an S3 bucket name that is globally taken; - an IAM policy the API rejects as malformed, or a role your credentials are not allowed to create; - a service quota you have already exhausted; - a value the provider validates only in its own `ValidateFunc` at plan time, or that the API validates at apply time. It also does not read state, so it knows nothing about drift, about what already exists, or about whether the change would be a destroy. And because unset variables are treated as unknown rather than as an error, a configuration can validate cleanly and then fail plan with "No value for required variable". The useful mental model: **validate checks the code, plan checks the code against reality.** ## The `-json` output `terraform validate -json` emits a machine-readable document with a `valid` boolean and a `diagnostics` array carrying severity, summary, and the file and line range for each finding. That is what you feed to a pipeline annotator so failures land on the right lines of the pull request rather than in a log nobody opens. ## Where it sits against the other checks Validate is not a security tool and not a policy tool. It will happily bless a security group open to `0.0.0.0/0` on port 22, an unencrypted bucket, and a hardcoded secret — all of those are perfectly well-formed configuration. It is also not a best-practice linter: an unused variable, a deprecated idiom, or a nonexistent instance type are all outside its remit, which is where TFLint's rulesets come in. The cheap-to-expensive ordering that follows from all this is: format check, then validate on an init'd-but-backend-less directory, then lint and security scanning, then a real `plan` with credentials. Each layer is slower and needs more access than the one before, and each can only find what the previous layers let through. ## Answering it well The strong answer names the boundary rather than listing checks: validate is scoped to the configuration plus the installed schemas, with no network calls to any provider. Everything you can say about what it catches and what it misses follows from that one sentence.