> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Terraform Validate and fmt
> Explains using terraform validate to catch HCL syntax and provider-schema errors and terraform fmt to enforce consistent HCL formatting for local development and CI
This lesson explains how to use `terraform validate` and `terraform fmt` to catch configuration errors early and enforce consistent HCL (HashiCorp Configuration Language) formatting.
## Overview
* `terraform validate` performs static validation of Terraform configuration files. When run after `terraform init`, it loads provider schemas and checks configuration structure and types against those schemas.
* `terraform fmt` reformats HCL files to the canonical style defined by HashiCorp. It changes only formatting (whitespace, indentation) and does not alter any configuration logic.
Both commands are fast and lightweight and are ideal for local development checks and CI pipelines.
## terraform validate — static validation (syntax + provider schema)
`terraform validate` parses your configuration, checks HCL syntax, and — if you previously ran `terraform init` — uses provider schemas to validate resource and argument names and types.
Important: run `terraform init` first so Terraform can download provider plugins and schema information. Without initialization, `terraform validate` still checks basic HCL syntax but may not catch provider-specific schema errors.
Example: an Azure Storage Account resource with a subtle argument-name typo
```hcl theme={null}
resource "azurerm_storage_account" "example" {
name = var.storage_account_name
location = "East US"
resource_group_name = "my-workshop-eus-rg"
account_tier = "Standard"
account_replication_types = "LRS"
public_network_access_enabled = false
}
```
At a glance the block looks valid, but the correct argument name is `account_replication_type` (singular). The typo results in a missing required argument plus an unsupported unexpected argument. After running `terraform init` and `terraform validate`, Terraform will detect both issues and report file/line numbers with suggestions:
```bash theme={null}
$ terraform validate
Error: Missing required argument
on main.tf line 1, in resource "azurerm_storage_account" "example":
1: resource "azurerm_storage_account" "example" {
The argument "account_replication_type" is required, but no definition was found.
Error: Unsupported argument
on main.tf line 6, in resource "azurerm_storage_account" "example":
6: account_replication_types = "LRS"
An argument named "account_replication_types" is not expected here.
Did you mean "account_replication_type"?
```
Key characteristics of `terraform validate`:
* Validates HCL syntax and configuration structure.
* When initialized, validates against provider schemas (argument names, types, required fields).
* Does not make API calls to create or modify cloud resources — no infrastructure changes.
* Excellent to use in pre-commit hooks and CI pipelines to catch schema and syntax problems early.
Run `terraform init` before `terraform validate` to ensure provider schemas are available for full validation.
## terraform fmt — enforce consistent HCL formatting
`terraform fmt` reformats your Terraform configuration files to the canonical HCL style. This improves readability and reduces noisy diffs in version control. It does not check correctness or change resource semantics.
Example of a poorly formatted file:
```hcl theme={null}
resource "azurerm_storage_account" "example" {
name = var.storage_account_name
location = "East US"
resource_group_name = "my-workshop-eus-rg"
account_tier = "Standard"
account_replication_type = "LRS"
public_network_access_enabled = false
}
```
Format the file with:
```bash theme={null}
$ terraform fmt main.tf
```
For CI pipelines, use `terraform fmt -check` to verify that files are already formatted and fail the build if they are not:
```bash theme={null}
$ terraform fmt -check
```
Notes about `terraform fmt`:
* Only modifies whitespace/indentation and formatting.
* Does not validate argument names, types, or provider schemas.
* Useful as an automatic pre-commit hook step or CI gate to enforce a consistent code style.
`terraform validate` does not check runtime constraints or whether a given resource name is already taken by the cloud provider. Those checks require interacting with the provider (for example via `terraform plan`/`apply` or provider APIs).
## Quick reference
| Command | Purpose | CI usage |
| -------------------- | ----------------------------------------------------------------- | ------------------------------------------------------- |
| `terraform init` | Download provider plugins and initialize the working directory. | Always run before `validate` in CI. |
| `terraform validate` | Static validation of HCL and (after init) provider-schema checks. | Run to catch schema/syntax errors early. |
| `terraform fmt` | Reformat files to canonical HCL style. | Use `terraform fmt -check` to enforce formatting in CI. |
## Best practices
* Always run `terraform init` once per working directory (or in your CI job) before `terraform validate`.
* Add `terraform fmt -check` and `terraform validate` to CI pipelines to block malformed or invalid configs.
* Use `terraform fmt` as a pre-commit hook to keep repository diffs clean and consistent.
* Remember that `terraform validate` is static — to confirm resource creation and runtime constraints, use `terraform plan` and `terraform apply` in a safe environment.
## Links and references
* [Terraform CLI Commands — validate](https://www.terraform.io/docs/cli/commands/validate)
* [Terraform CLI Commands — fmt](https://www.terraform.io/docs/cli/commands/fmt)
* [azurerm provider documentation](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs)
Summary:
* Use `terraform validate` to catch syntax and provider-schema issues before planning/applying.
* Use `terraform fmt` to enforce consistent HCL formatting across your team.
* Both commands are quick and should be part of your standard Terraform workflow (locally and in CI) before running `terraform plan` or `terraform apply`.
We'll now cover another Terraform command.