Recommended Free Tools
A Terraform plan can show extensive changes even when an application pull request barely touches infrastructure. One reported incident traced that surprise to a CI run selecting a newer AWS provider after the project’s lock file was removed. The lesson is not that every provider upgrade is dangerous: it is that the selected provider version helps determine how Terraform interprets configuration and state, so dependency selection and the resulting plan deserve review.
What happened in the reported AWS-provider incident
Sergey Shinder describes a Tuesday plan with 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 the broad constraint >= 5.0, and a CI runner migration removed the lock file. A fresh container then selected a newer provider version.
As an Amazon Associate I earn from qualifying purchases.
Shinder says the plan made some bucket defaults that had been absent from state explicit, normalized some security-group rule descriptions, and included a launch-template replacement that would have rolled nodes in an autoscaling group. He characterizes most of the changes as harmless. These details and the 62-change count are his account, not an independently reproduced incident; the exact provider release and full resource diffs are not specified. The report therefore illustrates a possible failure mode, not a measure of how often upgrades cause unexpected plans. Read Shinder’s DEV Community article.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why removing the lock file can change a plan
Terraform configuration declares provider requirements, including version constraints. The dependency lock file, .terraform.lock.hcl, records the provider version selected for the working directory. HashiCorp recommends committing that file so selection changes can be reviewed with code.
#1 Best Overall
HashiCorp documents that, when there is no recorded provider selection, terraform init selects the newest available version that satisfies the configured constraints. If a selection is already recorded, normal initialization reuses it; terraform init -upgrade explicitly allows Terraform to select newer versions that meet the constraints. A broad constraint permits a wider range of versions, but does not itself mean Terraform will upgrade on every ordinary initialization when a valid selection is recorded. HashiCorp’s dependency lock file documentation.
A provider is the software Terraform uses to interpret configuration and interact with a service. Changing its version can affect planning behavior, including how provider-managed attributes are represented. The incident does not establish that the reported defaults or description normalization apply universally to AWS resources, or that every provider upgrade changes plans.
How to make provider selection reviewable
Commit the lock file
Keep .terraform.lock.hcl under version control with the Terraform configuration. This preserves the recorded provider selection for future initialization and makes an intentional selection change visible in code review. HashiCorp’s guidance is to include the dependency lock file in version control.
Use read-only lock-file behavior in CI
Shinder reports using terraform init -lockfile=readonly in CI after the incident. This directs initialization to use the committed lock file without updating it. If the file is missing or does not satisfy the configuration, initialization should fail rather than silently write a new selection; restore or deliberately update the lock file through the project’s normal review process.
Choose constraints that reflect your upgrade policy
A constraint such as >= 5.0 allows any matching version from 5.0 upward. A narrower or pessimistic constraint can limit which versions are eligible, but it is not a substitute for keeping and reviewing the lock file. Shinder reports adopting pessimistic provider constraints; the appropriate bound depends on the project’s compatibility and upgrade policy.
Initiate upgrades deliberately
When you intend to refresh provider selections, run terraform init -upgrade in a controlled change, inspect the lock-file diff, and review the resulting plan before applying. This separates a planned dependency update from routine CI initialization.
Review the proposed actions, not just the change count
A plan is a proposed change set, not a safety score. A high count can include many low-impact updates, while a small plan can contain a destructive replacement. Shinder says his pipeline added a human-review gate when plan counts exceeded a workspace threshold; that is one reported safeguard, not a universal threshold or proof that plans below it are safe.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →- Inspect which resources change and whether Terraform will update, create, destroy, or replace them.
- Investigate replacements and other consequential actions, especially when the application or infrastructure configuration change does not seem to explain them.
- Check whether provider selections changed alongside the configuration, and compare the lock-file diff.
- Use a plan-count threshold only as a prompt for review, not as a substitute for reading the proposed actions.
Shinder’s summary captures the dependency angle: “Your infrastructure is defined by your code plus the exact provider binary that interprets it.” The practical implication is to treat both the provider selection and the plan it produces as reviewable parts of an infrastructure change.
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.
