IaC Module Design Vocabulary Exercises

1 / 5

A Terraform module exposes the following output:

output "rds_endpoint" {
  value = aws_db_instance.main.endpoint
}

What does this output value provide to callers of the module?

Output values are a module's "return values" — the interface through which a module exposes data to its callers.

Concept	Syntax	Description
Module output reference	`module.database.rds_endpoint`	How the parent module reads an output from a child module
Root module output	`terraform output rds_endpoint`	Root-level outputs are shown after apply and queryable via CLI
sensitive = true	`output "db_password" { sensitive = true }`	Masks the value in `terraform output` and plan logs
output vs. local value	`output` vs. `locals`	Outputs are exported to callers; locals are internal to the module

Modules communicate exclusively via variables (inputs) and outputs (return values). A module cannot read its caller's resources directly — it must receive them as variable arguments.

2 / 5

A team writes a Terraform module with the following variable block:

variable "environment" {
  type        = string
  description = "Target deployment environment"
  validation {
    condition     = can(regex("^(dev|staging|prod)$", var.environment))
    error_message = "Environment must be dev, staging, or prod."
  }
}

What does variable validation provide?

Variable validation is a plan-time guardrail that provides friendly error messages for invalid inputs before any API calls are made.

Feature	Detail
condition	Expression that must evaluate to `true` for validation to pass
can() function	Returns `true` if the inner expression succeeds without error — useful for regex and type checks
precondition (TF 1.2+)	Validates assumptions about resource inputs at plan time inside a resource block
postcondition (TF 1.2+)	Validates that a resource's attributes meet expectations after planning

Plan-time enforcement — validation rejects bad inputs before any cloud resources are touched
Error message quality — a good error_message tells the caller exactly what values are valid, reducing support burden

3 / 5

On the Terraform Registry, a module displays a "verified" badge next to its name. What does a verified module indicate?

Terraform Registry verified modules are reviewed and published by official cloud provider partners (AWS, Google, Azure) or HashiCorp-approved organisations — not just community contributors.

Status	Meaning	Trust level
Verified	Reviewed and published by HashiCorp partner	High — official provider support
Community	Published by individual or organisation, no HashiCorp review	Variable — review source before use

Module versioning — always pin with a version constraint: version = ">= 4.0.0, < 5.0.0"
Module pinning — specifying an exact or constrained version to prevent unexpected upgrades
Source address — registry.terraform.io/hashicorp/consul/aws (registry/namespace/module/provider)

4 / 5

A senior engineer says: "We should refactor this into a module — the current configuration is not DRY."

What does "DRY" mean in an IaC module design context and why does it matter?

DRY is a fundamental software engineering principle (from The Pragmatic Programmer) applied to IaC. If you copy the same RDS module configuration for 5 microservices, a security patch requires 5 separate edits — any missed copy introduces a vulnerability.

Anti-pattern	DRY alternative
Copied `aws_security_group` blocks for each service	A `security_group` module parameterised with port and CIDR inputs
Hardcoded encryption settings in every `aws_s3_bucket`	An `s3_bucket` module that always enforces encryption in its body
Repeated backend configuration blocks across 20 modules	Terragrunt with a root-level `terragrunt.hcl` that generates backend config

module encapsulation — hiding implementation details; caller only needs to know the interface (variables + outputs)
hardcoded vs. parameterised — parameterised resources accept variables for environment-specific values

5 / 5

A Terraform module includes the following pattern:

variable "tags" {
  type    = map(string)
  default = {}
}

locals {
  common_tags = {
    environment = var.environment
    team        = var.team
    cost_centre = var.cost_centre
  }
  all_tags = merge(local.common_tags, var.tags)
}

Why is this merge() tagging pattern recommended for module design?

The merge(local.common_tags, var.tags) pattern ensures governance tags are always applied (the module's responsibility) while allowing callers to add their own context-specific tags (the caller's right).

Tag type	Set by	Examples
Mandatory tags	Module internals (`local.common_tags`)	environment, team, cost_centre, managed_by
Optional tags	Caller (`var.tags`)	service, feature, jira_ticket

merge() behaviour — if both maps share a key, the second argument wins. Put var.tags last if callers should be able to override module defaults; put local.common_tags last to make mandatory tags immutable.
Tag governance — using OPA/checkov to enforce that mandatory tags exist on all resources at CI time
Cost allocation — cost_centre tags enable cloud cost breakdowns per team in AWS Cost Explorer / GCP Billing