fmt and validate

These are the two cheapest quality gates Terraform has, and they catch a surprising amount for what they cost. terraform fmt rewrites your files into canonical formatting — consistent indentation, aligned arguments, one style — and terraform validate checks that the configuration is internally consistent: valid syntax, correct argument types, references that resolve. Both run in under a second and touch nothing real.

They are the floor below which no Terraform code should fall, and they belong at the very front of every pipeline. The trap is mistaking what they prove. A config that formats cleanly and validates is structurally sound; it is not guaranteed to apply. That gap — between "the code is well-formed" and "the change will work against real AWS" — is the single most misunderstood thing about these commands.

terraform fmt

terraform fmt rewrites .tf files in place to the canonical style and ends every formatting argument a team would otherwise have in review. There is exactly one correct format, the tool produces it, and nobody debates brace placement again. For CI you do not want it rewriting files — you want it to fail when files are not already formatted. fmt -check exits non-zero if anything would change and writes nothing; -diff prints what it would have changed so the failure is actionable.

# exits non-zero if any file is not canonically formatted
terraform fmt -check -recursive -diff

The -recursive flag walks subdirectories so a monorepo of modules is checked in one pass. Run this as a gate, not a fixer, in CI: the developer formats locally, and CI only confirms they did.

terraform validate

terraform validate checks a configuration for internal consistency without contacting any provider API or reading state. It catches a reference to an attribute that does not exist, an argument given a string where a number is required, a missing required argument, a malformed expression, a duplicate resource address. It needs terraform init to have run first, because it loads the providers to know each resource's schema — but it makes no API calls and creates nothing.

# init installs providers so validate knows the schemas
terraform init -backend=false

# structural and type checks only — touches no real infrastructure
terraform validate

Passing -backend=false to init lets validate run in CI without configuring or reaching the state backend, since validation does not need it. The output is a clean success or a precise pointer to the file, line, and argument that is wrong.

What validate Does and Doesn't Catch

This is the line that matters. validate verifies structure and types — that the configuration is well-formed and self-consistent. It does not verify that the plan will succeed. It cannot tell you the AMI ID does not exist in your region, that your IAM role lacks permission to create the resource, that you are over a service quota, or that the instance type is unavailable in the chosen availability zone. Those are real-world facts that only plan (which queries AWS) or apply (which tries the operation) can surface.

So validate passing is necessary, not sufficient. It guarantees Terraform can understand your code, not that AWS will accept it. Treat it as the syntax-and-types gate it is, and let plan handle feasibility and policy-as-code handle the rules.

In the Pipeline

Both commands belong in the first stage of CI, before plan, because they are fast and fail on obvious problems for a fraction of a plan's cost. A typical front gate runs fmt -check, then init -backend=false, then validate, and stops the pipeline if any of them fails. There is no reason to spend a plan's API calls and minutes on code that is not even formatted or that references a variable that does not exist.

Locally, the same gates move even earlier. Configure your editor to run terraform fmt on save, and add a pre-commit hook that runs fmt -check and validate so a malformed or unformatted commit never reaches the shared branch. The earlier the gate, the cheaper the failure — a pre-commit catch costs seconds, the same catch in CI costs a queued job and a context switch.