A provider major upgrade removes an argument from the aws_instance resource type and changes its defaults. Before merging the upgrade, the team wants to know exactly which managed instances in this workspace would be affected and how. Which approach scopes the impact?

Two inputs scope a provider upgrade. The terraform state list command enumerates the resource instances in state and accepts address patterns, giving the inventory of every aws_instance object, including those inside modules and for_each or count collections. A plan run with the upgraded provider selected, typically after terraform init -upgrade on a branch, then shows for each instance whether the new schema and defaults produce no change, an in-place update or a replacement, and configuration errors appear for any argument the provider removed. Reviewing that plan before merging is the safe way to learn the real impact. The dependency lock file records the selected version and checksums for each provider, not which resources it manages. A refresh-only apply would write state using the new provider immediately, which is a change rather than an assessment and could be hard to undo if the upgrade is abandoned, since earlier versions may not read it. Inspecting one representative instance ignores that instances often differ in configuration through for_each values, variables or module inputs, so the impact varies. Exam caveat: run the assessment in each environment, because state and variable values differ between them. Operational check: on the upgrade branch, run init -upgrade and plan, export the plan with terraform show -json, and list every aws_instance address whose action is not no-op.