When designing a reusable Terraform module, how do you decide which input variables get a default and which are left required?

## The mechanic first In Terraform, a `variable` block that omits `default` is **required**. If the caller does not supply a value: - Interactively, Terraform prompts on the terminal for it. - With `-input=false` — which is how every CI pipeline should run — the run fails immediately with an error naming the variable. So the choice between required and defaulted is really the choice between "the pipeline stops and asks a human" and "the module quietly picks for you". Everything below is about which of those you want. ```hcl variable "vpc_id" { description = "VPC the cluster is created in" type = string # no default — the caller must decide } ``` ## Leave it required when the caller must decide Three categories belong on the required side: **Identity and placement.** `name`, `environment`, `vpc_id`, `subnet_ids`, `account`, `region`. There is no universally correct value; a default here is either meaningless or actively dangerous, because a caller who forgets the argument gets a *working* plan pointed at the wrong place. The failure mode of a missing required variable is an error message. The failure mode of a wrong default is production traffic in the wrong VPC. **Anything with a cost or capacity consequence.** Instance types, node counts, provisioned throughput, backup retention, multi-AZ toggles. If getting it wrong shows up on an invoice or in a capacity incident, make someone type it. **Anything with a security consequence.** Which CIDR ranges may reach the service, which principals may assume a role, whether a bucket is public. A module that defaults these is deciding another team's security posture in a file they never read. ## Default when there is one right answer Give a default when the value is genuinely uninteresting to most callers and cheap to get wrong: a `tags` map that starts empty, a log retention period matching your organisation's standard, a naming suffix, a feature toggle that is off. Every default you add removes a decision from a caller — that is its value, and the test is whether the decision was ever theirs to make. When you do default, **default to the safe end of the range**, because the default is what an inattentive caller ships: ```hcl variable "ingress_cidrs" { description = "CIDR blocks allowed to reach the service" type = list(string) default = [] # deny by default, never 0.0.0.0/0 } ``` Defaults that are convenient (`0.0.0.0/0`, encryption off, deletion protection off, a public subnet) are the ones that show up in incident reviews, because the module made them easy and invisible. ## The null default `default = null` is a distinct and useful third state. Passing `null` as a resource argument makes Terraform behave as if the argument were not written at all, so the provider applies its own default. That lets a module say "optional, and if you say nothing I will not force a choice": ```hcl variable "kms_key_arn" { description = "Customer-managed key ARN; null uses the AWS-managed key" type = string default = null } ``` It is also the idiom for optional blocks and for conditionally-created resources, and it keeps the module from encoding a guess about what the provider's default should be. ## Defaults are published API This is the point most candidates miss. A default is not a private implementation choice — it is the value every caller who stayed silent is running with. Change `instance_type` from `t3.small` to `t3.medium` in a module and, on the next upgrade, every silent caller's plan shows a replacement they did not ask for. Change a default retention from 7 days to 1 and you have quietly deleted a compliance control across an estate. Practical consequences: - Treat a default change as a behaviour change, not a tidy-up, and call it out in the changelog. - Prefer *adding* a new optional variable with a default that preserves today's behaviour over changing an existing default. - Where a default is genuinely a policy decision (retention, encryption, sizing), consider making it required in the module and defaulting it once in a thin organisation-level wrapper, so the policy lives in one reviewable place instead of inside a general-purpose module. ## The failure you are choosing between Every input is a choice about *where the mistake surfaces*. Required means it surfaces at plan time, in CI, with the variable's name in the error. Defaulted means it surfaces later, in the infrastructure, with no error at all. Modules age well when the expensive, irreversible and security-relevant decisions are the ones that stop the pipeline.