When is writing a Terraform module premature abstraction rather than useful factoring, and how do you decide?

## The question behind the question Interviewers ask this because most Terraform repositories fail in one of two directions, and both are expensive. One is copy-paste sprawl — the same bucket configuration in nine places, eight of them missing encryption. The other is over-modularisation — a private registry of forty modules, most of them one resource deep, where changing a tag means opening three pull requests in three repositories. Knowing how to write a module is table stakes; knowing when not to is the judgment being probed. ## The test: does it encode a decision? A module is an interface with a version, not a folder. It pays for that overhead when it holds knowledge: - **Enforced conventions** — naming, tagging, mandatory encryption, a required log destination. The module makes the safe thing the default and the unsafe thing impossible. - **Multi-resource wiring** — a bucket plus its policy, access logging and lifecycle configuration; a service plus its task role, log group and alarm. Those pieces have no meaning apart, and getting the wiring right once is real value. - **A decision that took an incident to learn** — a health-check grace period, a deletion protection flag, a subnet layout. Encoded once, it stops being rediscovered. If you cannot point at a decision, you have written an alias. ## The anti-pattern in detail The classic premature module wraps one resource and declares one variable per argument: ```hcl # modules/bucket/main.tf — an alias, not an abstraction resource "aws_s3_bucket" "this" { bucket = var.bucket force_destroy = var.force_destroy tags = var.tags } ``` It looks tidy and it costs more than it looks: 1. **Argument starvation.** The provider has dozens of arguments; the module exposes three. The first consumer who needs a fourth files an issue against the module and waits. 2. **Documentation indirection.** The provider docs no longer answer questions directly — a reader has to map every module variable back onto the real argument, and the names rarely match exactly. 3. **Release overhead.** Every trivial change is a module commit, a tag, and a version bump in each consumer before anyone sees it. 4. **Fake flexibility.** To reclaim what was lost, people add `dynamic` blocks and pass-through objects until the module is harder to read than the resource it wraps. 5. **A one-way door.** Un-wrapping later moves every resource address, so the cleanup is a state-moving refactor rather than a delete. ## Wait for repetition Extracting after the second or third genuine use is not laziness, it is information gathering. The first use cannot tell you which parts vary; you guess, and the guess becomes the interface everyone codes against. Duplicated resource blocks are ugly but local — anyone can change one without coordinating. A wrong module interface with six consumers must be changed in lockstep or versioned through a migration. There is a middle ground people forget: a shared `locals` block, a shared tfvars file, or a documented example in the repository often captures the convention with none of the versioning cost. ## The thin wrapper that does earn its place One module shape that looks trivial but is legitimate is the per-environment wrapper root: a small configuration per environment that sets the backend and provider, calls one stack module, and supplies that environment's values. It carries almost no logic, and that is the point — the environments differ only in inputs, and the difference is visible in one file per environment instead of being spread through the stack. Judge it by whether it stays thin: once a wrapper starts adding resources of its own, environments have quietly diverged and the shared stack no longer describes production. ## The direction of the mistake matters The two failure modes are not symmetric in cost. Copy-paste is visible and reversible: you can see the duplication and fold it into a module later. Over-abstraction is invisible and sticky — nobody proposes deleting a module, the layer accumulates consumers, and the refactor out of it moves state. If you are unsure, err toward duplication and extract when the third case arrives with evidence. ## What to say in an interview Give a test rather than a rule: name what a module must contain to be worth its version, name the pass-through wrapper as the anti-pattern, and mention the asymmetry — that the wrong module interface is much harder to undo than duplicated resource blocks. That is a lead's answer, and it is what the question is fishing for.