A policy gate denies a Terraform plan over a resource generated three modules deep — how do you resolve it?

### Why this failure feels different from every other denial Most gate failures are self-service: the rule names an attribute, the developer opens the file, changes it, pushes again. A violation inside a nested module breaks that loop in a specific way. The plan expands modules into resources, so the denial's address is fully qualified — `module.platform.module.data.module.storage.aws_s3_bucket.raw` — and describes a declaration living in a repository the developer may not even know exists. They search their own code for `aws_s3_bucket.raw` and find nothing. The gate is correct, the finding is real, and the feedback is useless as delivered. ### Step one: address translation The module path is a chain of call names, read left to right from the root. The first segment, `module.platform`, is the only one present in the developer's own configuration. That is the human-editable anchor, and the denial should lead with it: the call name, the source and version pinned on that call, and then the generated resource address as evidence. The gate already has everything needed to say this — the call is in the plan's configuration section, the resource is in the expanded output, and the address prefix joins them. Doing that join is the operator's job, not the developer's. The same translation decides *who* gets the notification. A denial anchored on a generated address routes to whoever ran the pipeline. A denial anchored on the module call routes to two parties: the caller, who chose to use this module at this version, and the module's owner, who wrote the resource. ### Step two: triage the three real cases **The module already supports the fix.** Many rules — a required tag, an encryption flag, a logging bucket — correspond to an input the module exposes and the caller left unset or set wrongly. The change is one argument in the caller's own module block. This is the outcome you want most denials to reduce to, and it is worth checking first because it is invisible from the address alone. **A newer module version fixes it.** The approved-source-and-pinned-version control pays for itself here: because the call names an exact version, you can compare it against the current release and tell the developer that bumping the pin resolves the finding. The remediation is again a one-line edit in their file. This is also why pinning to an immutable reference matters — without it you cannot say which revision produced the bad resource. **The module itself is wrong.** Now the caller is genuinely blocked on someone else's backlog. Escalate to the module owner with the specific rule and resource, and decide what happens to the caller in the meantime. This is the only case that needs a policy decision rather than an edit. ### Step three: if you must let it through, choose the right unit The instinct is to exempt the failing plan. Resist it. Ten teams calling the same module hit the same violation, so plan-scoped exemptions produce ten records for one defect, ten expiry dates, and no signal that they share a cause — and when the module is finally fixed, nothing retires them. Key the exception to the **module source and version**: it covers every caller at once, it expires naturally when callers move to a version that no longer needs it, and it makes the outstanding work legible as one item on the platform team's list rather than ten on ten teams' lists. It also puts the record where the accountability is. ### Step four: move the finding upstream The structural fix is to stop discovering module defects in callers' pipelines at all. Run the same rule set over the module's own plans — the examples or test configurations in the module repository — as part of its release process. Then a violation is found by the person who can fix it, before a version exists for anyone to pin. A module registry that publishes versions which fail the organisation's own policy is publishing known-bad artifacts and pushing the discovery cost onto every consumer. ### The judgment underneath All of this is the price of a paved road. The moment you require infrastructure to come through shared modules, you have moved a class of failures out of the reach of the people who trip over them. That is a good trade — one review instead of hundreds — but only if two things hold: the module review that justifies the approval is real, and a fixed version reaches the callers quickly. If module fixes take a quarter, your gate has converted a security finding into a delivery blocker for teams who cannot resolve it, and the pressure to blanket-exempt the module becomes irresistible. Operators of this kind of gate should watch the age of open module-scoped exceptions the way they watch the denial rate: it is the honest measure of whether the paved road is maintained.