When you author a reusable Terraform module that dozens of teams will consume, how do you design it so it stays safe and maintainable as it spreads across the org?
technical-conceptual · Senior level · cloud-devops-security
What the interviewer is really asking
Probes whether the candidate can reason about IaC at platform scale: secure-by-default inputs, sane variable contracts and versioning, blast-radius isolation through state segmentation, and the paved-road tradeoff between flexibility and guardrails — beyond just writing working HCL.
What to say
- Design the interface for safe defaults: required inputs only where a wrong value is dangerous, opinionated secure defaults (encryption on, public access off) so the easy call is the safe one, and validation on variables to reject bad input early.
- Version and pin deliberately: publish the module with semantic version tags so consumers pin to a known-good version and you can ship breaking changes without surprise, rather than everyone tracking main.
- Bound the blast radius: keep state segmented per consumer/environment so a botched apply can't ripple across teams, and keep the module composable rather than one mega-module that does everything.
What to avoid
- Building a single giant do-everything module with dozens of toggles — it becomes unmaintainable and every consumer pays for complexity they don't use.
- Shipping insecure defaults and relying on consumers to remember to turn on encryption or lock down access.
- Letting consumers track the module's main branch so any change you push instantly hits everyone with no version gate.
Example answers
Strong: I treat the module's variables as an API contract. Defaults are secure — encryption on, no public access — so the lazy path is the safe path, and I add variable validation to reject obviously wrong inputs at plan time. I publish it with semver tags so teams pin a version and I can land breaking changes behind a major bump instead of surprising everyone. And I keep consumers' state segmented per environment so one team's bad apply can't take out another's.
Weak: I'd make the module flexible by exposing every possible setting as a variable so any team can configure it however they want, and they just reference the module from our shared repo so they always get the latest version with all the fixes.