A terraform block configures Terraform itself rather than creating infrastructure. It acts as the module’s settings container for provider dependencies, workspace and backend configuration, Terraform version requirements, and selected language features. section 2.1.3 section 2.3
Use the block to control project-level behavior:
- Declare required_providers with each provider’s source and acceptable version range. section 2.1.3 section 2.4.2
- Configure a centralized backend or cloud workspaces when multiple developers share infrastructure state. section 2.3
- Set Terraform version requirements to prevent execution with incompatible features. section 2.3
- Opt into experimental language features only when intentionally testing them; these features can change rapidly between versions. section 2.3
Declare AWS before using AWS resources
terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "us-east-1" } The required_providers block tells Terraform what to install; the separate provider block configures that provider, here by selecting an AWS region. Although Terraform can infer some HashiCorp providers from resource names, explicitly declaring them allows version control and avoids breakage from incompatible provider changes. section 2.1.3 section 2.4.2
Listing 2.17 terraform settings block
terraform {
experiments = [example] #1
required_providers { #2
aws = {
version = "~> 5.0.0"
source = "hashicorp/aws"
}
}
cloud { #3
organization = "example_corp"
hostname = "app.terraform.io"
workspaces {
tags = ["my-app"]
}
}
backend "s3" { #4
bucket = "mybucket"
key = "path/to/my/key"
region = "us-east-1"
}
}
Inspect a complete settings block combining experimental features, provider requirements, cloud workspaces, and an S3 backend. section 2.3
