Provider selection and unsupported arguments

Understand the likely causes

• The provider source address, module-local name, constraint intersection, recorded selection, and installation integrity each play a role. A valid HCL parser cannot certify a provider-specific argument.
• The lock file remembers provider choices, not remote module versions. Conflicting module requirements can leave no compatible single selection for one provider source.

Classify the first actual failure

Record the exact CLI version, configuration revision, provider source and local name, selected lock entry, module versions, and redacted diagnostic. First distinguish a Terraform language/CLI compatibility failure from provider lookup, installation, constraint resolution, and resource-schema validation. Do not upgrade everything or delete the lock file before establishing which stage failed. No Terraform command, registry installation, backend access, or provider execution is performed by this guide.

Read independent ranges explicitly

The complete teaching root below targets Terraform 1.16.x and a separate Random 3.9 patch range. Those are independent constraints, not proof of an installed dependency set. A provider block would configure provider-specific settings; it would not replace the required_providers source declaration. Never invent package checksums to make a lock entry appear valid. Keep real dependency changes inside the approved update and integrity-verification process.

terraform {
  required_version = ">= 1.16.0, < 1.17.0"
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.9.0"
    }
  }
}

All modules need a compatible common selection

The offline model below assumes two stable-version intervals and a tiny authored availability list. It finds their intersection without querying a registry. A recorded lock selection outside the revised allowed set cannot simply be treated as compatible because it worked before. Conversely, a valid recorded selection need not be replaced merely because another newer version exists. Review requirements and update intent before changing dependency evidence. This tuple model deliberately excludes prereleases and full Terraform constraint syntax.

available = [(3, 7, 2), (3, 9, 0), (4, 0, 0)]
first = lambda v: (3, 7, 0) <= v < (4, 0, 0)
second = lambda v: (3, 9, 0) <= v < (3, 10, 0)
compatible = [v for v in available if first(v) and second(v)]
print('compatible=' + ','.join('.'.join(map(str, v)) for v in compatible))

compatible=3.9.0

Resolve unsupported arguments at the actual resource boundary

For Unsupported argument, verify the exact resource type, provider source, selected version, nesting, spelling, and documented feature support. A feature available in current generic documentation may not exist in the pinned provider release. Correct the configuration or review a deliberate tested dependency update; do not assume changing required_version upgrades the provider. Provider aliases configure one selected plugin version and do not solve incompatible version requirements by themselves.

Keep it from recurring

• Pin an appropriate root update policy, review lock diffs, version modules independently, and keep source/schema documentation aligned with selected releases. Separate dependency maintenance from infrastructure execution and avoid broad upgrades as the first response to a narrow diagnostic.