Controlling Terraform Behavior and Settings

​

Real-world scenarios: why the Terraform block matters

• Scenario 1: Developer A writes and tests infrastructure code using Terraform X.Y.Z, runs a successful terraform plan, and commits the changes. Developer B later pulls the same code but has a different Terraform version installed. Developer B now sees unexpected errors and spends time troubleshooting version mismatches instead of delivering features.

resource "azurerm_resource_group" "prd" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_virtual_network" "dv" {
  name                = "example-network"
  resource_group_name = "azure"
  location            = "west"
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_mssql_database" "db1" {
  name      = "example-db"
  server_id = "server_db"
  collation = "sql_general"
}

• Scenario 2: The CloudOps team commits working code that relies on an older provider version. Later, a different team pulls the code and adds a resource that requires a newer provider. Running terraform init may download the latest provider with breaking changes, causing the configuration to fail and work to stall.

resource "google_service_account" "default" {
  account_id   = "my-custom-sa"
  display_name = "Custom SA for VM Instance"
}

resource "google_compute_disk" "primary" {
  name                      = "my-secure-disk"
  type                      = "pd-ssd"
  zone                      = "us-central1-a"
  physical_block_size_bytes = 4096
}

resource "google_kms_crypto_key" "crypto_key" {
  name     = "example-key"
  key_ring = google_kms_key_ring.key_ring.id
}

​

What the Terraform block controls

1. required_version — which Terraform version(s) may apply the configuration.
2. required_providers — which providers the configuration needs, including the provider source and version constraints.
3. backend — where Terraform will store state (local or a remote backend like S3, Azure Blob, Google Cloud Storage, Terraform Cloud, etc.).

​

Correct structure and an example Terraform block

terraform {
  required_version = "~> 1.10.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.87.0"
    }
  }

  backend "s3" {
    bucket = "prd-terraform-east-2"
    key    = "state/terraform.tfstate"
    region = "us-east-2"
  }
}

• required_version = "~> 1.10.0" ensures Terraform 1.10.x is used (patch updates allowed within 1.10).
• The aws provider is declared with a source and a ~> 5.87.0 constraint, allowing patch updates within 5.87.x.
• The backend "s3" block is declared inside the terraform {} block and points to a remote S3 bucket for state — recommended for team collaboration.

​

Understanding version constraints

1. Exact version

• Syntax: "1.9.8"
• Meaning: Only the specified version is allowed. This gives absolute reproducibility.

terraform {
  required_version = "1.9.8"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.77.0"
    }
  }
}

2. Minimum version (>=)

• Syntax: ">= 1.9.8"
• Meaning: Any version equal to or newer than the specified version is allowed. Useful when you require at least a minimum version but are comfortable with newer releases.

terraform {
  required_version = ">= 1.9.8"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.77.0"
    }
  }
}

3. Tilde greater than (~>) — pessimistic constraint

• Syntax: "~> 1.11.0"
• Meaning: Allows updates only to the last specified component. "~> 1.11.0" allows 1.11.1, 1.11.2, etc., but not 1.12.0. This accepts patch fixes automatically while avoiding minor version changes that may introduce breaking behavior.

terraform {
  required_version = "~> 1.11.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.87.0"
    }
  }
}

​

When to use each approach

• Exact versions:
  • Use when you need strict reproducibility and full control over every change (recommended for immutable CI pipelines).
• >= (minimum):
  • Use when you require a baseline version that contains necessary features or bug fixes, and you accept newer versions automatically.
• ~> (pessimistic):
  • Use when you want automatic patch updates but want to avoid automatic minor version upgrades that could break behavior.

​

Best practices summary

• Always declare required_version and required_providers in your root module to avoid surprises across developers and CI systems.
• Use a remote backend (S3, Azure Blob, GCS, Terraform Cloud, etc.) for state when working in a team to prevent conflicting local state files.
• Choose version constraints deliberately:
  • Exact for strict reproducibility,
  • >= for minimum guarantees,
  • ~> for safe automatic patch updates.
• Pin providers by source (e.g., hashicorp/aws) and version to avoid implicit provider source changes.
• Run terraform init after changing the terraform block or required_providers to ensure the correct providers are installed.

​

Links and references

• Terraform docs — Configuration language: Terraform block
• Terraform docs — Backend types
• Terraform Registry — Provider documentation
• AWS S3, Azure Blob Storage, Google Cloud Storage, Terraform Cloud