In Terraform 1.3 or later, how do you declare a module input that takes an object where some attributes may be omitted by the caller, and what value do the omitted attributes get?

## The problem optional attributes solve A module that configures something substantial — a database, a service, a network — has a lot of knobs. Two bad shapes used to compete for that job. One was the flat wall: twenty separate `variable` blocks, all with defaults, that a reader has to mentally re-assemble into the structure they represent. The other was a single variable typed `any` (or `map(any)`), where the module dug values out with `lookup(var.config, "engine", "postgres")` — flexible, entirely unchecked, and documented only by reading the module body. Object types with optional attributes give you the third option: one variable whose *type* is the documentation, most of whose attributes the caller can ignore. ## The syntax ```hcl variable "database" { type = object({ engine = string size_gb = number instance_class = optional(string, "db.t3.micro") multi_az = optional(bool, false) parameters = optional(map(string), {}) kms_key_arn = optional(string) }) } ``` `optional(T)` marks the attribute as omittable with no default; `optional(T, default)` supplies one. `engine` and `size_gb` are unwrapped, so they are required and omitting either fails the plan with an error naming the missing attribute. A caller can now write: ```hcl module "db" { source = "./modules/db" database = { engine = "postgres" size_gb = 100 } } ``` and the module sees `instance_class = "db.t3.micro"`, `multi_az = false`, `parameters = {}` and `kms_key_arn = null`. ## Null is a real value here The one-argument `optional(string)` deliberately yields `null` rather than an empty string. That matters because `null` for a resource argument means "I am not setting this" — so `kms_key_arn = var.database.kms_key_arn` passes straight through and, when the caller omitted it, behaves exactly as if the argument had not been written. An empty string would not: it is a value, and the provider would try to use it. ## Defaults are applied recursively The defaults are part of the type conversion, not a runtime lookup, and Terraform applies them throughout the constraint — including to object types nested inside collections: ```hcl variable "buckets" { type = map(object({ versioning = optional(bool, true) prefix = optional(string, "") })) } ``` Each entry of the map gets its own defaults filled in, so a caller can write `{ logs = {}, assets = { versioning = false } }` and both entries come out fully populated. Getting the same effect by hand with `merge` over a `map(any)` is possible and considerably worse to read. ## Where it sits in a module's interface The practical guidance is to reserve required, unwrapped attributes for the things that genuinely have no sensible default — the ones where guessing would be wrong — and make the rest optional with the default the module would have chosen anyway. That gives a two-line call for the common case and a fully specified one for the unusual case, from a single declaration that also serves as the module's documentation. The cost to be aware of: the object type is a contract. Adding a new `optional` attribute with a default is backwards-compatible for existing callers; adding a required one, renaming an attribute, or changing an attribute's type is a breaking change to every caller at once, because the whole value is checked as a unit. ## Version note Optional object type attributes and their defaults became generally available in Terraform 1.3. Earlier versions had an opt-in language experiment with different syntax and no default argument, so module code written for 1.3 and later will not work on an older CLI — which is a reason for such a module to declare a `required_version` constraint.