Speaking the Language
Terraform core is deliberately cloud-agnostic. It knows how to build a dependency graph, calculate a diff between desired and actual state, and orchestrate API calls in the right order — but it does not know what an EC2 instance is. That knowledge lives in Providers.
A Provider is a plugin — a compiled binary — that Terraform downloads during terraform init. It translates HCL resource definitions into real API calls. The AWS provider, for example, maps aws_instance to the EC2 RunInstances API. The Kubernetes provider maps kubernetes_deployment to the Kubernetes API server. There are over 3,000 providers in the Terraform Registry, covering everything from cloud platforms to DNS registrars to GitHub.
Crucial Practice 1: Version Pinning
Cloud APIs change. If you write code today and the AWS provider releases version 6.0 tomorrow with breaking changes, your pipeline will fail in ways that are difficult to debug. The fix is simple: always pin your provider versions using version constraints.
The ~> operator (called the "pessimistic constraint operator") is the standard choice. ~> 5.0 means "any version >= 5.0 and < 6.0" — you get bug fixes and minor features automatically, but you are protected from major breaking changes. This constraint is declared once, per provider, in the Terraform configuration block itself. After running terraform init, Terraform writes the exact resolved version to .terraform.lock.hcl. Commit this file to version control. It is the equivalent of package-lock.json in Node.js — it guarantees that every team member and every CI pipeline uses the identical provider binary.
Crucial Practice 2: Multi-Region Aliases
By default, a provider block targets one region. Some architectures require resources in multiple regions simultaneously. The canonical example is AWS CloudFront with ACM certificates: CloudFront is a global service, but it only accepts TLS certificates created in us-east-1, regardless of where your application runs.
Provider aliases solve this by letting you declare multiple instances of the same provider with different configurations — a default aws provider block targeting one region, and a second, explicitly aliased aws provider block targeting us-east-1. Any resource that must live in that other region opts in by referencing the alias directly; everything else silently uses the default. The same pattern applies to multi-account deployments: you can alias providers with different assume_role configurations to deploy into separate AWS accounts from a single Terraform run.
Interviewers frequently ask: "How do you manage resources that must exist in a specific region, like ACM certificates for CloudFront?" The answer is provider aliases. A strong follow-up is to mention that the .terraform.lock.hcl file should always be committed to version control to ensure reproducible provider versions across all environments and CI pipelines — a detail many candidates miss.