English for Terraform Modules Developers

Writing and maintaining reusable Terraform modules is a distinct skill from simply applying infrastructure as code, and it comes with its own vocabulary around interfaces, versioning, and composition. When you’re publishing a module for other teams to consume, reviewing a pull request that changes a module’s inputs, or explaining a breaking change in a changelog, precise English matters as much as the code itself. This guide focuses specifically on the terminology used when authoring and versioning Terraform modules, rather than infrastructure as code in general.

Key Vocabulary

Input variable — a parameter a module accepts from whoever calls it, allowing the same module to be configured differently across environments. “We added an input variable for instance_type so callers can choose their own sizing instead of it being hardcoded.”

Output value — data a module exposes back to the caller after resources are created, commonly used to pass information like resource IDs to other modules. “The module exposes the VPC ID as an output value so downstream modules can reference it.”

Module registry — a central catalogue, public or private, where versioned Terraform modules are published and discovered for reuse. “We published the networking module to our private registry so every team pulls the same source of truth.”

Semantic versioning — a versioning scheme (major.minor.patch) that signals whether a module release contains breaking changes, new features, or bug fixes. “Bumping the major version was necessary because we renamed a required input variable, which is a breaking change.”

Module composition — the practice of building larger infrastructure configurations by combining smaller, focused modules rather than one monolithic module. “Through module composition, our root configuration just wires together the networking, database, and compute modules.”

Root module — the top-level Terraform configuration that a user runs directly, which typically calls one or more child modules. “The root module doesn’t define any resources itself, it just composes three child modules together.”

Provider requirement — a declaration inside a module specifying which providers, and which versions of them, it depends on. “We pinned the provider requirement to avoid a breaking change from a future AWS provider release.”

Module source — the location Terraform pulls a module from, which can be a local path, a Git repository, or a registry address. “Update the module source to point at the tagged release instead of the main branch, so builds stay reproducible.”

Common Phrases

• “This is a breaking change, so we need to bump the major version before publishing.”
• “Let’s pin the module source to a tag instead of main so environments don’t drift.”
• “Can we expose that as an output value instead of hardcoding it downstream?”
• “The interface is getting bloated, we should split this into two smaller modules.”
• “Did we update the provider requirement after the last upgrade?”
• “That variable should have a sensible default so most callers don’t need to set it.”

Example Sentences

When explaining Terraform modules to a non-technical stakeholder: “Modules let our infrastructure team package up a standard, tested way of setting up things like databases or networks, so every project uses the same reliable pattern instead of everyone building it from scratch.”

When filing a support ticket: “After upgrading the networking module from v2.3.0 to v3.0.0, our plan fails because the subnet_ids output no longer exists. Was this renamed, and is there a migration guide for the v3 release?”

When discussing architecture in a team meeting: “I’d suggest we extract the database configuration into its own module with clearly defined input variables and outputs, so other teams can consume it through the registry instead of copying our Terraform files.”

Professional Tips

• Always describe module changes in terms of semantic versioning — say “this is a minor release, fully backward compatible” rather than a vague “small update,” since consumers rely on that signal to decide whether to upgrade immediately.
• When reviewing a module’s interface, focus feedback on the input variables and output values first — these form the module’s public contract, while internal resource names are implementation detail.
• Use “pin the module source” when advising teammates to reference an exact version or Git tag rather than a branch, since it’s the standard phrase for avoiding unreviewed drift.
• Clarify whether a discussion is about the root module or a child module early in a conversation — confusing the two levels of composition is a common source of miscommunication in code review.

Practice Exercise

1. A teammate wants to publish a new Terraform module and asks how to decide on the first version number. Write two to three sentences explaining semantic versioning in this context.
2. Explain in one sentence the difference between an input variable and an output value.
3. Draft a short changelog entry announcing a major version bump caused by a renamed required variable.