Terraform · Infrastructure as code

Why pin Terraform and provider versions?

Mediumversion pinninglock fileupgradesUpdated Oct 2026
Quiz this track

Short answer

Pin Terraform with required_version and providers with pessimistic constraints, and commit .terraform.lock.hcl. Upgrade deliberately in a branch, run plan, and review provider changelogs for breaking changes.

Infrastructure code depends on the Terraform binary, provider plugins and modules. Any of those can change behaviour between runs. Pinning makes a plan reproducible and turns an upgrade into an explicit, reviewable change instead of a surprise.

hcl
terraform {
  required_version = "~> 1.9.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}
required_version constrains the CLI. The provider constraint allows compatible patch releases within the selected minor line.

What to pin and commit

  • Terraform CLI version in required_version and in CI
  • Provider constraints in required_providers
  • Module versions for registry and Git sources
  • The .terraform.lock.hcl file, including checksums

Upgrade in a dedicated pull request: run terraform init -upgrade, inspect the lock diff, run a plan against a non-production environment, and read the provider changelog for deprecations. A plan that shows replacements after a provider bump is a signal to slow down, not to apply blindly.

Do not use version = "latest". It makes builds non-reproducible and can change behaviour without any change in your repository.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1What is the difference between required_version and a provider version constraint?
  2. 2What does the lock file contain?
  3. 3How do you upgrade a provider safely?
  4. 4Why can a provider upgrade cause resource replacement?

Say it in the interview

I pin the Terraform CLI with required_version, constrain providers with pessimistic version ranges, and commit the lock file with checksums. That makes plans reproducible and turns upgrades into explicit pull requests. For an upgrade I run init -upgrade, review the lock and plan in a non-production environment, and read the changelog. I never use latest, because it can change behaviour without a code change.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Terraform mock interview and get scored feedback on depth, clarity and confidence.