During a design review, an engineer proposes a module that wraps a single storage bucket resource and exposes every one of the resource's arguments as an input variable with no added logic or defaults. How should the reviewer respond?
Select an answer to reveal the explanation.
Short Explanation
A module should make something easier, not just put a box around it. If you're passing every argument straight through, you've added a layer to maintain and gained nothing, so either use the resource directly or wrap a real pattern.
Full Explanation
HashiCorp's module guidance recommends against modules that are thin wrappers around a single resource type. A module earns its place by raising the level of abstraction: grouping resources that are always deployed together, encoding organizational defaults and guardrails, and exposing a smaller, intention-revealing interface. A wrapper that passes every argument through adds a layer that must be versioned, documented and upgraded whenever the provider schema changes, while offering callers nothing the resource itself does not. Mandating wrappers for every resource type multiplies that maintenance cost across the whole catalog and hides the provider documentation behind an interface that merely mirrors it. Pinning the provider exactly inside a shared module is itself poor practice, because shared modules should declare only a minimum provider version and let the root module choose, and a pin adds no abstraction. The registry imposes no minimum number of resource types; a single-resource module with meaningful defaults and logic can be perfectly reasonable. Exam caveat: a single-resource module can be justified when it enforces policy-driven defaults such as encryption and access blocks that callers cannot switch off. Operational check: compare the module's input list with the resource's argument list; if they match one to one with no defaults or logic, the module is a pass-through.