PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Terraform plan can change even when your application configuration barely does: Terraform’s selected provider version also determines how configuration and state are interpreted. If CI loses its lock file, a fresh initialization can select a newer provider allowed by your version constraint. Commit the lock file, make provider upgrades intentional, and review each proposed action—especially replacements—rather than relying on the plan’s change count.
How a one-tag change became a much larger Terraform plan
Sergey Shinder describes a Tuesday plan that showed 62 changes across four workspaces, even though the pull request changed one S3 bucket tag. In his account, the root modules allowed AWS provider versions matching >= 5.0, and the lock file had been removed during a CI runner migration. A new container then resolved a newer provider. Shinder says some bucket defaults absent from state became explicit and some security-group rule descriptions were normalized. Most changes were harmless, he reports, but one planned launch-template replacement would have rolled nodes in an autoscaling group. These details and the count are Shinder’s account; they are not independently reproduced in the official documentation. The publication year of his article is not verified. Read Shinder’s account on DEV Community.
The general mechanism is documented by HashiCorp: Terraform records selected provider versions in .terraform.lock.hcl. When no selection is recorded, terraform init selects the newest available provider version that satisfies the configured constraints. If a version is already recorded, normal initialization reuses it; terraform init -upgrade requests newer selections within the constraints. HashiCorp’s dependency lock file documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why provider selection can alter a plan
Terraform uses provider plugins to interact with infrastructure services and interpret resource configuration and state. A provider release can change behavior relevant to planning, including how attributes are represented or normalized. If the selected binary changes, Terraform may propose differences even if the configuration change is small. The incident illustrates one possible path; it does not establish that all AWS resources, all defaults, or every provider upgrade produce such changes.
#1 Best Overall
A lock file makes the selected provider version visible in code review and repeatable across clean initializations. It does not prohibit intentional upgrades: a reviewer can examine and approve a lock-file change made through an upgrade. Constraints define which versions are acceptable; the lock file records which acceptable version was selected. Both therefore matter.
Make provider upgrades reviewable in CI
Shinder says he adopted a committed .terraform.lock.hcl, initialized CI with terraform init -lockfile=readonly, used pessimistic provider constraints, and added a pipeline gate for plans whose change counts exceeded a workspace threshold. HashiCorp recommends committing the lock file so provider selection can be reviewed. Read-only lock-file use in CI is an operational choice reported by Shinder, not a universal requirement for every workflow.
- Commit the lock file. Keep
.terraform.lock.hclin version control alongside the Terraform configuration so changes to selected provider versions appear in code review. - Keep routine CI initialization from rewriting it. Shinder reports using
terraform init -lockfile=readonlyfor this purpose. Handle upgrades in a deliberate change that updates and reviews the lock file. - Constrain acceptable versions deliberately. A broad constraint can permit a newer release to be selected when there is no recorded selection. Shinder reports switching to pessimistic constraints; choose a range that matches your upgrade policy rather than assuming a constraint alone pins one exact version.
- Review the plan’s actions. Treat the plan as a proposed change set. Inspect affected resources and action types, with particular attention to replacement or destruction, rather than approving or rejecting it solely by its summary count.
How to judge an unexpectedly large plan
A high change count is a signal to investigate, not proof that a plan is unsafe. A small plan is not proof of safety either: one replacement may carry more operational risk than many low-impact in-place updates. Compare the plan’s actual resource actions with the intended configuration change, and check whether the provider selection changed.
- Check the lock-file diff to see whether the selected provider version changed.
- Check the initialization command and whether CI had access to the committed lock file.
- Inspect replacement and destroy actions individually, including the resources and dependencies involved.
- If the plan is unexpected, pause before applying it and determine whether the provider selection or a real infrastructure change explains the difference.
Shinder’s account is an illustrative failure mode, not a measured estimate of how often upgrades cause unexpected plans. The exact AWS provider release and complete resource diffs are not specified in the available account, so the reported attribute changes should not be treated as universal upgrade behavior.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
