In Terraform projects, format and validation are your first line of defence against messy code and avoidable runtime errors. Think of them as \u201cstyle checking\u201d and \u201csanity checking\u201d for infrastructure as code.<\/p>\n
Terraform configurations tend to grow into large, multi\u2011module codebases, often edited by several engineers at once. Without conventions and guards:<\/p>\n
main<\/code>.<\/li>\n- Misused modules cause surprises late in
plan<\/code> or even apply<\/code>.<\/li>\n<\/ul>\nFormatting (terraform fmt<\/code>) standardises how the code looks, while validation (terraform validate<\/code> and variable validation) standardises what values are acceptable.<\/p>\n
\nFormatting Terraform Code with terraform fmt<\/code><\/h2>\nWhat terraform fmt<\/code> Actually Does<\/h3>\nterraform fmt<\/code> rewrites your .tf<\/code> files into Terraform\u2019s canonical style.<\/p>\nIt:<\/p>\n
\n- Normalises indentation and alignment.<\/li>\n
- Orders and spaces arguments consistently.<\/li>\n
- Applies a single canonical style across the project.<\/li>\n<\/ul>\n
Typical usage:<\/p>\n
# Fix formatting in the current directory\nterraform fmt\n\n# Recurse through modules and subfolders (what you want in a real repo)\nterraform fmt -recursive<\/code><\/pre>\nFor CI or pre\u2011commit hooks you almost always want:<\/p>\n
terraform fmt -check -recursive<\/code><\/pre>\nThis checks<\/strong> formatting, returns a non\u2011zero exit code if anything is off, but does not modify files. That makes it safe for pipelines.<\/p>\nWhy This Matters Architecturally<\/h3>\n\n- Consistent formatting reduces cognitive load; you can scan resources quickly instead of re\u2011parsing everyone\u2019s personal style.<\/li>\n
- Diffs stay focused on behaviour instead of whitespace and alignment.<\/li>\n
- A shared style is essential when modules are reused across teams and repos.<\/li>\n<\/ul>\n
Treat terraform fmt<\/code> like go fmt<\/code>: it\u2019s not a suggestion, it\u2019s part of the toolchain.<\/p>\n
\nStructural Validation with terraform validate<\/code><\/h2>\nWhat terraform validate<\/code> Checks<\/h3>\nterraform validate<\/code> performs a static analysis of your configuration for syntactic and internal consistency.<\/p>\nIt verifies that:<\/p>\n
\n- HCL syntax is valid.<\/li>\n
- References to variables, locals, modules, resources, and data sources exist.<\/li>\n
- Types are consistent (for example you\u2019re not passing a map where a string is expected).<\/li>\n
- Required attributes exist on resources and data blocks.<\/li>\n<\/ul>\n
Basic usage:<\/p>\n
terraform init # required once before validate\nterraform validate<\/code><\/pre>\nIf everything is fine you will see:<\/p>\n
Success! The configuration is valid.<\/code><\/pre>\nThis does not<\/strong> contact cloud providers; it is a \u201ccompile\u2011time\u201d check, not an integration test.terraformpilot+1<\/p>\nWhy You Want It in Your Workflow<\/h3>\n\n- Catches simple but common mistakes (typos in attribute names, missing variables, wrong types) before
plan<\/code>.<\/li>\n- Cheap enough to run on every commit and pull request.<\/li>\n
- Combined with
fmt<\/code>, it gives you a fast gate that keeps obviously broken code out of main.<\/li>\n<\/ul>\nIn CI, a very standard pattern is:<\/p>\n
terraform fmt -check -recursive\nterraform init -backend=false # or with backend depending on your setup\nterraform validate<\/code><\/pre>\nYou can choose whether init<\/code> uses the real backend or a local one; the key is that validate<\/code> runs automatically.<\/p>\n
\nInput Variable Validation: Types and Rules<\/h2>\n
Terraform also validates values<\/strong> going into your modules via input variables. There are three important layers.<\/p>\n1. Type Constraints<\/h3>\n
Every variable can and should declare a type: string<\/code>, number<\/code>, bool<\/code>, complex types such as list(string)<\/code> or object({ ... })<\/code>. Terraform will reject values that do not conform.<\/p>\nExample:<\/p>\n
variable "tags" {\n type = map(string)\n}<\/code><\/pre>\nPassing a list here fails fast, long before any resource is created.<\/p>\n
2. Required vs Optional<\/h3>\n\n- Variables without<\/strong> a
default<\/code> are required; if the caller does not supply a value, Terraform fails at validation time.<\/li>\n- Variables with<\/strong> a
default<\/code> are optional; they still participate in type and custom validation.<\/li>\n<\/ul>\nThis lets you express what callers must always provide versus what can be inferred or defaulted.<\/p>\n
3. Custom validation<\/code> Blocks<\/h3>\nInside each variable<\/code> block you can define one or more validation<\/code> blocks.<\/p>\nEach block has:<\/p>\n
\ncondition<\/code>: a boolean expression evaluated against the value.<\/li>\nerror_message<\/code>: a human\u2011readable message if the condition is false.<\/li>\n<\/ul>\nExample patterns from common practice include:<\/p>\n
\n- Membership checks with
contains<\/code> or regex.<\/li>\n- Ranges and integer checks for numbers.<\/li>\n
- Multiple validation blocks to capture several independent rules.<\/li>\n<\/ul>\n
The rationale here is strong: you make invalid states unrepresentable<\/strong> at the module boundary, rather than having to handle them deep inside resource logic.<\/p>\n
\nBeyond Variables: Preconditions and Postconditions<\/h2>\n
Terraform also lets you validate assumptions around<\/em> resources and data sources using precondition<\/code> and postcondition<\/code> blocks.<\/p>\n\n- A precondition<\/strong> asserts something must be true before Terraform creates or updates the object (for example, an input computed from multiple variables is within bounds).<\/li>\n
- A postcondition<\/strong> asserts something must be true after the resource or data source is applied (for example, an attribute returned by the provider matches expectations).<\/li>\n<\/ul>\n
Conceptually:<\/p>\n
\n- Variable validation guards inputs to modules<\/strong>.<\/li>\n
- Preconditions\/postconditions guard behaviour of resources and data sources<\/strong> exposed by those modules.<\/li>\n<\/ul>\n
For a team consuming your module, this is powerful: they get immediate, clear errors about violated invariants instead of mysterious provider failures later.<\/p>\n
\nA Simple Example (Format + Validate + Variable Rules)<\/h2>\n
Below is a small, self\u2011contained configuration you can run locally to see formatting and validation in action.<\/p>\n
Files<\/h3>\n
Create the files.<\/p>\n
variables.tf<\/code>:<\/p>\nvariable "environment" {\n description = "Deployment environment."\n type = string\n\n validation {\n condition = contains(["dev", "test", "prod"], var.environment)\n error_message = "Environment must be one of: dev, test, prod."\n }\n}\n\nvariable "app_name" {\n description = "Short application name used in resource naming."\n type = string\n\n validation {\n condition = can(regex("^[a-z0-9-]{3,20}$", var.app_name))\n error_message = "app_name must be 3-20 chars, lowercase letters, digits, and hyphens only."\n }\n}\n\nvariable "instance_count" {\n description = "Number of instances to run."\n type = number\n\n validation {\n condition = var.instance_count >= 1 && var.instance_count <= 10\n error_message = "instance_count must be between 1 and 10."\n }\n\n validation {\n condition = !(var.environment == "prod" && var.instance_count < 3)\n error_message = "In prod, instance_count must be at least 3."\n }\n}<\/code><\/pre>\nThis demonstrates:<\/p>\n
\n- Type constraints on all inputs.<\/li>\n
- A small \u201cenumeration\u201d for
environment<\/code>.<\/li>\n- A format rule enforced via regex on
app_name<\/code>.<\/li>\n- Multiple independent validation rules on
instance_count<\/code>, including one that depends on environment<\/code>.<\/li>\n<\/ul>\nmain.tf<\/code>:<\/p>\nterraform {\n required_version = ">= 1.5.0"\n}\n\nlocals {\n app_tag = "${var.app_name}-${var.environment}"\n}\n\noutput "example_tags" {\n value = {\n Environment = var.environment\n App = var.app_name\n Count = var.instance_count\n AppTag = local.app_tag\n }\n}<\/code><\/pre>\nStep 1 \u2013 Format the Code<\/h3>\n
From inside the folder:<\/p>\n
terraform fmt -recursive<\/code><\/pre>\nObserve that Terraform will adjust spacing\/indentation if you intentionally misalign something and run it again. This confirms fmt<\/code> is active and working.<\/p>\nStep 2 \u2013 Initialize<\/h3>\nterraform init<\/code><\/pre>\nNo providers are actually used here, but validate<\/code> requires initialization.<\/p>\nStep 3 \u2013 Structural Validation<\/h3>\n
Run:<\/p>\n
terraform validate<\/code><\/pre>\nThis checks syntax, references, and type soundness of the configuration itself.<\/p>\n
If you see:<\/p>\n
Success! The configuration is valid.<\/code><\/pre>\nyou know the configuration is structurally sound.<\/p>\n
Step 4 \u2013 Test Variable Validation with plan<\/code> and -var<\/code><\/h3>\nTo exercise your variable validation logic<\/strong> with specific values, use terraform plan<\/code> with -var<\/code> flags.<\/p>\n\n- \n
Valid input:<\/p>\n
terraform plan -var=\"environment=dev\" -var=\"app_name=demo-app\" -var=\"instance_count=2\"<\/code><\/pre>\n\n- Here
-var<\/code> is supported and your custom validation blocks are evaluated.<\/li>\n- This should succeed, producing a plan (no resources, but the important part is that there are no validation errors).<\/li>\n<\/ul>\n<\/li>\n
- \n
Invalid environment:<\/p>\n
terraform plan -var=\"environment=stage\" -var=\"app_name=demo-app\" -var=\"instance_count=2\"<\/code><\/pre>\nExpect Terraform to fail with the custom environment error message from the validation<\/code> block.<\/p>\n<\/li>\n- \n
Invalid app name:<\/p>\n
terraform plan -var=\"environment=dev\" -var=\"app_name=Demo_App\" -var=\"instance_count=2\"<\/code><\/pre>\nYou should see the regex\u2011based app_name<\/code> error.<\/p>\n<\/li>\n- \n
Invalid prod count:<\/p>\n
terraform plan -var=\"environment=prod\" -var=\"app_name=demo-app\" -var=\"instance_count=1\"<\/code><\/pre>\nHere, the environment is valid and the type is correct, but the cross\u2011rule on instance_count<\/code> fails with your custom prod message.<\/p>\n<\/li>\n<\/ol>\nOptional \u2013 Use *.tfvars<\/code> Instead of -var<\/code><\/h2>\nIf you prefer files over command\u2011line flags, create dev.auto.tfvars<\/code>:<\/p>\nenvironment = "dev"\napp_name = "demo-app"\ninstance_count = 2<\/code><\/pre>\nThen just run:<\/p>\n
terraform plan<\/code><\/pre>\nTerraform will automatically load *.auto.tfvars<\/code> files and apply the same variable validations.<\/p>\n
\nRecommended Pattern for Teams<\/h2>\n
Updated to reflect current behaviour:<\/p>\n
\n- Run
terraform fmt -check -recursive<\/code> and terraform validate<\/code> in CI on every PR.<\/li>\n- Use
terraform plan<\/code> (with -var<\/code> or *.tfvars<\/code>) to exercise and gate variable validations for concrete environments (dev, test, prod).<\/li>\n- Enforce types and
validation<\/code> blocks on all externally visible variables, not just a handful.<\/li>\n- Use preconditions and postconditions where module consumers must rely on specific guarantees from your resources.<\/li>\n<\/ul>\n
From an engineering\u2011lead perspective, this gives you a clear division of responsibilities:<\/p>\n
\nfmt<\/code> \u2192 canonical style.<\/li>\nvalidate<\/code> \u2192 structural soundness of the configuration.<\/li>\nplan<\/code> (with variables) \u2192 semantic correctness of inputs and module contracts.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"In Terraform projects, format and validation are your first line of defence against messy code and avoidable runtime errors. Think of them as \u201cstyle checking\u201d and \u201csanity checking\u201d for infrastructure as code. Why Format and Validate at All? Terraform configurations tend to grow into large, multi\u2011module codebases, often edited by several engineers at once. Without […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[94],"tags":[],"_links":{"self":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts\/2131"}],"collection":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2131"}],"version-history":[{"count":1,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts\/2131\/revisions"}],"predecessor-version":[{"id":2132,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=\/wp\/v2\/posts\/2131\/revisions\/2132"}],"wp:attachment":[{"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2131"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2131"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ronella.xyz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2131"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}