A shared Terraform child module declares its own `provider "aws"` block so it can pin a region. Why is that discouraged, and what should the module and its caller do instead?

## Inheritance is the default, and it is usually enough When the root configuration declares `provider "aws" { region = "eu-west-1" }`, every child module it calls uses that configuration automatically. A module does not need to declare anything to get it. That inheritance is why a `provider` block inside a shared module is almost always a mistake rather than a missing feature: the module is not gaining a capability, it is taking a decision away from its caller. ## Cost 1 — the module can no longer be repeated or ordered A module with its own provider configuration cannot be used with `count`, `for_each` or `depends_on`. The reason is structural: Terraform must resolve provider configurations before it can expand a module into instances or place it in the graph as a unit, so a module that carries its own cannot participate in any of those. In practice this surfaces the day someone tries to write `for_each = var.regions` on the module and gets an error they cannot fix without changing the module itself. ## Cost 2 — the module is not reusable A region pinned inside the module is a region every caller gets. You cannot call it twice for two regions, you cannot run it against a sandbox account, and you cannot test it anywhere other than where it was written. The whole point of a module is that the caller supplies the context. ## Cost 3 — you cannot remove it cleanly This is the failure that turns into an incident. Provider configurations are needed not only to create resources but to **destroy** them. If the provider configuration lives inside the module and you delete the `module` block, the configuration disappears at the same moment Terraform decides those resources should be destroyed — and it has nothing left to destroy them with. The plan errors out asking for a provider configuration that no longer exists in the configuration. The recovery is awkward: put the module block back, apply a change that empties it, or restructure so the provider lives in the root, then remove it. Doing that under time pressure, in a state file shared by a team, is exactly the situation you do not want to discover at decommissioning time. ## The correct shape The child declares its *requirements*, never its *configuration*: ```hcl # modules/bucket/versions.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = ">= 5.0" configuration_aliases = [aws.replica] } } } ``` `configuration_aliases` is how a module says "I need a second AWS configuration, and I will refer to it as `aws.replica` internally" without deciding what it points at. Inside the module, a resource selects it with `provider = aws.replica`. The caller supplies the concrete configurations on the module block: ```hcl module "bucket" { source = "./modules/bucket" providers = { aws = aws.primary aws.replica = aws.eu_west_1 } } ``` The map's keys are the names *inside* the module; the values are configurations that exist *in the caller*. Note that passing `providers` explicitly replaces inheritance for that module — if you specify the map, it must cover every configuration the module needs, because the defaults are no longer inherited implicitly. ## Reading it in review A quick review heuristic for any module you are asked to reuse: open its `versions.tf`. `required_providers` with version constraints and possibly `configuration_aliases` is a module built to be composed. A `provider` block with a hardcoded region or, worse, credentials, is a module that was extracted from someone's root configuration and never finished — and it will fight `for_each` and destruction the first time you need either. ## What an interviewer is listening for A candidate who says only "providers should be in the root" has read the guideline. A candidate who explains that removal breaks destroy, that repetition meta-arguments are incompatible, and who can sketch `configuration_aliases` on one side and `providers = { ... }` on the other, has actually maintained shared modules.