Terraform

Terraform

Load release supplements

Determine the Terraform version governing the files in scope before making version-specific decisions:

1. Read the required_version constraint in the root module's terraform block. Treat its lowest permitted minor release as the target when it establishes one.
2. If the configuration does not establish a lower bound, read .terraform-version or an equivalent version-manager file that applies to the root module.
3. If neither source establishes a version, run terraform version -json and read terraform_version.
4. If no local source establishes a version, use an explicit version from the user's request. Otherwise ask for the target instead of assuming one.

Determine the model's knowledge cutoff. Compare the target Terraform version and cutoff with the release table, then load every listed sibling skill whose version is at or below the target and whose release falls after the cutoff. Load selected skills oldest first.

Terraform version	Release date	Skill
1.5	2023-06-12	terraform-1-5
1.6	2023-10-04	terraform-1-6
1.7	2024-01-17	terraform-1-7
1.8	2024-04-10	terraform-1-8
1.9	2024-06-26	terraform-1-9
1.10	2024-11-27	terraform-1-10
1.11	2025-02-27	terraform-1-11
1.12	2025-05-14	terraform-1-12
1.13	2025-08-20	terraform-1-13
1.14	2025-11-19	terraform-1-14
1.15	2026-04-29	terraform-1-15

Configuration style

Run terraform fmt on changed Terraform files. Preserve established module structure and naming conventions when they are clear.

Declare Terraform and provider requirements explicitly in reusable root modules. Give every provider its full source address and a constraint that allows compatible patch releases without silently crossing an unreviewed major version.

terraform {
  required_version = ">= 1.15.0, < 2.0.0"

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

Prefer typed variables with validation where invalid inputs can be rejected before provider operations. Mark secret-bearing variables and outputs as sensitive; never place credentials or secret values in configuration defaults.

Use locals to name a meaningful derived value or remove genuine repetition. Keep a one-use expression inline when extracting it would obscure the resource configuration.

Prefer for_each with stable domain keys when resource instances have durable identities. Use count for interchangeable instances whose positional identity is intentional.

Keep provider configuration in root modules. Pass providers into child modules explicitly only when aliases or non-default mappings require it.

Treat state as sensitive operational data. Do not edit state files directly. Use configuration-driven refactoring and import features when the target version supports them; use state commands only when no declarative workflow fits.

Use depends_on only for dependencies Terraform cannot infer from value references. Avoid provisioners unless the operation cannot be expressed through a provider, image build, cloud-init, or configuration-management system.

Use lifecycle arguments only for a specific invariant. Do not add ignore_changes to conceal perpetual drift without explaining and verifying the external owner of the ignored attribute.

Verification

Run the narrowest non-mutating checks that cover the change:

1. Run terraform fmt -check for formatting-only verification.
2. Run terraform init -backend=false when provider or module installation is needed for validation and backend access is not required.
3. Run terraform validate after initialisation.
4. Run relevant terraform test files for modules that provide tests.
5. Run terraform plan only when credentials, backend access, and the selected workspace are known to be safe. Never apply unless the user explicitly requests it.