Interview Infrastructure as Code (Terraform, Ansible)

Why pin provider and Terraform versions, and how do you do it?

Infrastructure as Code (Terraform, Ansible) · Basic level

Answer

Version pinning makes Terraform runs deterministic. I pin the Terraform CLI with required_version, pin providers with required_providers constraints, and commit .terraform.lock.hcl so CI and developers use the same provider builds. Without pinning, an upstream provider change can alter plan behavior unexpectedly.

Technical explanation

required_version constrains the Terraform CLI feature set used by the configuration.

required_providers constrains provider source and version range.

The lock file pins checksums and selected provider versions for reproducible installs.

Keep Terraform's ownership boundary clear: one state should own a resource or field, and other tools should consume published outputs instead of modifying it.

Use fmt, validate, linting, policy checks, plan review, and state locking before production applies.

Design for small blast radius by splitting state around lifecycle, permissions, and recovery boundaries.

Hands-on example

1. Create version controls for: Why pin provider and Terraform versions, and how do you do it?

2. Add versions.tf:

terraform {

required_version = ">= 1.6, < 2.0"

required_providers {

aws = {

source = "hashicorp/aws"

version = "~> 5.0"

}

}

}

3. Run terraform init, commit .terraform.lock.hcl, and run terraform providers lock for multi-platform CI if needed.

4. Test an upgrade in a branch with terraform init -upgrade, review the provider changelog, and compare plans before merging.

Preparing for an interview?

Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.

More Infrastructure as Code (Terraform, Ansible) interview questions

← All Infrastructure as Code (Terraform, Ansible) questions