Validating Your Configuration

Terraform validation helps you catch configuration and business-rule problems before they reach production. In this guide you’ll learn the four validation mechanisms Terraform provides, when each runs during the lifecycle, and practical examples to enforce safe infrastructure changes. Imagine deploying on a Friday afternoon. A teammate runs terraform apply and the plan looks fine, but an EC2 instance fails to boot because an ARM AMI was paired with an x86_64 instance type. The HCL was syntactically valid, yet incompatible. Validation catches these semantic problems earlier so you avoid cascading failures and costly troubleshooting. Terraform offers four validation layers:

Variable validation
Preconditions
Postconditions
Checks

Think of these as defensive layers that run at different points during planning and apply. Understanding each stage helps you apply the right guardrail for your team and automation workflow (also useful when preparing for the Terraform Associate certification). So here’s where each validation fits into the workflow:

A slide titled "Validating Your Configuration" showing a left-to-right workflow (Variable Validation → Preconditions → Postconditions → Checks) with purple icons and a long "Terraform Workflow" arrow underneath. The slide uses simple pictograms for checklist, pie chart, flow diagram, and a check-marked inbox.

Variable validation: runs immediately when Terraform creates a plan (before contacting providers). If it fails, Terraform stops.
Preconditions: evaluated when Terraform generates the plan but before it creates any resources.
Postconditions: evaluated after a resource has been created or updated (to verify the result).
Checks: run as the final step of a plan or apply. They produce warnings rather than errors and do not block the operation.

Variable validation Variable validation validates inputs at plan time and prevents bad inputs from progressing to provider APIs. Use it to enforce naming conventions, region allowlists, numeric ranges, and other input-level business rules. Template for variable validation:

variable "example" {
  type = string

  validation {
    condition     = <expression-that-evaluates-to-true-or-false>
    error_message = "A helpful error message describing the rule and remediation steps."
  }
}

Notes:

condition must evaluate to true or false.
error_message displays when condition is false.
Validation runs before contacting providers, giving fast and user-friendly feedback.

Examples

Allowed Azure regions (allowlist)

variable "location" {
  type        = string
  description = "Azure region where resources will be deployed"

  validation {
    condition = contains([
      "eastus",
      "westus2",
      "centralus"
    ], var.location)
    error_message = "Location must be one of the approved US regions: eastus, westus2, or centralus."
  }
}

This prevents accidental deployments to disallowed regions such as westeurope or southeastasia.

Numeric validation with business rules

variable "cpu_count" {
  type        = number
  description = "Number of virtual CPUs for the VM"

  validation {
    condition     = var.cpu_count >= 2 && var.cpu_count <= 16 && var.cpu_count % 2 == 0
    error_message = "CPU count must be an even number between 2 and 16. Single-CPU VMs are not supported in production."
  }
}

Multiple validation rules on one variable

You can combine rules inside a single validation block or use multiple validation blocks (if your Terraform version supports stacking). Each rule is evaluated independently.

variable "instance_type" {
  type        = string
  description = "EC2 instance type for the application server"

  validation {
    condition = contains([
      "t3.micro", "t3.small", "t3.medium",
      "t3.large", "t3.xlarge", "t3.2xlarge",
      "m5.large", "m5.xlarge", "m5.2xlarge",
      "c5.large", "c5.xlarge", "c5.2xlarge"
    ], var.instance_type)
    error_message = "Instance type must be an approved type from the t3, m5, or c5 families. Graviton instances require architecture approval."
  }

  validation {
    condition = (
      var.instance_type == "t3.micro" ||
      var.instance_type == "t3.small" ||
      !startswith(var.instance_type, "t3")
    )
    error_message = "t3.micro and t3.small are only allowed for development. Use t3.medium or larger for staging and production."
  }

  validation {
    condition     = !can(regex("\\.(24|32)xlarge$", var.instance_type))
    error_message = "Extra-large instances (24xlarge and above) require infrastructure team approval. Please submit a request ticket."
  }
}

Preconditions and postconditions Preconditions and postconditions attach to resources inside a resource’s lifecycle block. Use preconditions to verify assumptions before creating/updating a resource, and postconditions to assert that the resource ended up in the expected state after creation or update. Both use the same structure: a condition and an error_message. Precondition template:

resource "azurerm_app_service" "example" {
  # resource configuration ...

  lifecycle {
    precondition {
      condition     = <expression>
      error_message = "Precondition failed: explain what the expectation is and how to fix it."
    }
  }
}

Postcondition example:

resource "google_compute_instance" "web_server" {
  name         = var.instance_name
  machine_type = var.machine_type
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = var.boot_image
    }
  }

  lifecycle {
    postcondition {
      condition     = self.network_interface[0].access_config[0].nat_ip != ""
      error_message = "The instance must have a public IP address assigned. Check your network configuration."
    }
  }
}

Key points:

precondition runs after planning but before any create/update actions. If it fails, Terraform aborts the apply.
postcondition runs after the resource has been created or updated. Use self to reference the resource’s attributes. If it fails, Terraform aborts and shows the error.
Use these to guard incompatible actions (precondition) or to assert that provisioning achieved the expected runtime state (postcondition).

Checks (check blocks) Check blocks are top-level blocks executed as the final step of a plan or apply. They can reference resources, data sources, variables, and outputs. Unlike variable validation, preconditions, and postconditions, check block assertions produce warnings rather than errors — they do not block the operation.

Example check block monitoring a website health endpoint:

check "web_health" {
  data "http" "web_health_endpoint" {
    url = "https://my-awesome.website.com/health"
  }

  assert {
    condition     = data.http.web_health_endpoint.status_code == 200
    error_message = "Web health endpoint returned ${data.http.web_health_endpoint.status_code}. Expected 200."
  }
}

Notes:

If the assertion fails, Terraform emits a warning with the error_message, but the deployment continues.
Check blocks are ideal for non-blocking verification such as endpoint health, certificate expiry, or runtime checks.
On HCP Terraform, check blocks can run continuously to monitor infrastructure health over time.

Choosing the right validation Use the mechanism that matches when and how you want to block or warn:

Validation Type	When it runs	Blocks apply?	Typical use cases
Variable validation	During `terraform plan` before contacting providers	Yes	Validate user inputs, formats, allowlists (`region`, `instance_type`)
Precondition	After planning but before creating/updating a resource	Yes	Prevent incompatible operations (e.g., architecture vs. AMI mismatch)
Postcondition	After resource creation/update	Yes	Verify provisioning result (e.g., public IP assigned, service reachable)
Check block	As the final step of plan/apply (warnings only)	No — emits warnings	Non-blocking runtime checks: health endpoints, cert expiry, observability checks

A purple presentation slide titled "Choosing the Right Validation" that maps tasks (validate user input, verify assumptions, verify results, monitor infrastructure health) to validation types. Arrows show the corresponding types: Variable validation, Precondition, Postcondition, and Check.

Summary

Variable validation runs first during planning and prevents bad inputs from progressing.
Preconditions run after planning but before resource creation; they block incompatible attempts.
Postconditions run after resource creation/update to assert the desired state; they block when assertions fail.
Check blocks run last and emit warnings; they are useful for non-blocking, ongoing checks.

Remember the sequence: variable validation → preconditions → postconditions → checks. Choosing the right validation type ensures you catch the right problems at the right time.

Links and references

Terraform official docs — Validation: https://www.terraform.io/docs
Terraform resource lifecycle: https://www.terraform.io/docs/language/resources/sensitive-data.html (see lifecycle hooks)
HashiCorp Learn — Terraform Associate certification prep: https://learn.hashicorp.com/terraform

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Validating Your Configuration

Watch Video