A team is writing a reusable module that other teams will call, sometimes with count or for_each, and wants it to create resources in the AWS account and region the caller chooses. How should the module handle the AWS provider?
Select an answer to reveal the explanation.
Short Explanation
Modules borrow their providers from the caller; they don't bring their own. Declare what you need in required_providers, leave the provider block to the root, and count and for_each keep working.
Full Explanation
Provider configurations belong in the root module and are passed down to child modules, either implicitly for the default configuration or explicitly through the providers argument on the module block when aliases are involved. A shared module should declare its provider requirements, the source address and a minimum version, in required_providers and then use whatever configuration the caller supplies, which lets the caller choose account, region and credentials. A module that contains its own provider block is a legacy pattern: it is incompatible with count, for_each and depends_on on the module block, and removing the module later can fail because the provider configuration disappears along with the resources it must destroy. Making the region an input does not fix that, since the provider block still lives inside the module. Each module must declare its own provider requirements so Terraform can resolve a single compatible version and the correct source address; omitting them falls back to assumptions about the provider's namespace instead of an explicit contract. Exam caveat: no-code ready modules are the documented exception, because they must declare their providers directly. Operational check: search the module for provider blocks, confirm there are none, and call it with for_each from a test root to prove it plans cleanly.