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 / 15
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 / 15
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
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 / 15
A Terraform module includes the following pattern:
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
6 / 15
Reviewer: 'I'm seeing a lot of repeated `aws_s3_bucket` configurations across our modules. This module seems to be handling the bucket creation and permissions. Could we consider encapsulating this logic into a reusable module for S3 buckets? It would improve consistency and reduce duplication.' What is the reviewer primarily suggesting regarding the design of this module?
The reviewer is advocating for modularization to reduce redundancy and improve maintainability. They specifically mention 'DRY' which highlights the importance of avoiding duplicated code across multiple modules. Options A and D are incorrect because they limit the module's scope unnecessarily; option B would not address the core issue of duplication.
7 / 15
Dev1 (Sarah): 'Just deployed the new staging module. The output is showing an 'aws_ec2_instance.webserver' endpoint with a value of private IP: 10.0.0.5. Is that normal?' What does Sarah likely need to understand about the module's outputs?
Sarah's question reveals she needs to understand that module outputs often provide details about the resources created by the module. The private IP address of an EC2 instance is a critical piece of information for configuring network connectivity within her deployment environment. Option A is incorrect as private IPs are not publicly accessible.
8 / 15
PR Description: 'Updated the `compute` module to include a new variable, `instance_type`, allowing users to specify the EC2 instance type. Added validation to ensure only supported types are used. This improves flexibility and allows for targeted resource sizing.' What is the primary benefit described in this PR description regarding the module's design?
The description explicitly states 'improved flexibility and control…through variable customization.' This highlights a key benefit of IaC modules – allowing users to tailor configurations based on their specific needs. Options A and C are incorrect because they present negative consequences; option D is irrelevant.
9 / 15
Engineer (Mark): 'I'm working on a module for deploying our application servers. I've added a default value to the `instance_count` variable – setting it to 2. This simplifies initial deployments.' What does Mark's action primarily demonstrate about good IaC module design?
Mark's addition of a default value demonstrates the principle of providing sensible defaults to simplify common use cases. This reduces the amount of configuration required by users and makes the module easier to adopt. Option A is incorrect because it contradicts best practices; option C is too restrictive.
10 / 15
Reviewer: 'This module uses a `local` block to define common tags for all resources. It's good practice to avoid hardcoding these values directly within the resource definitions themselves.' What is the reviewer's primary concern regarding this approach?
The reviewer's concern centers on maintaining consistency and avoiding duplication. Hardcoding tags within resource definitions can lead to inconsistencies across different environments or deployments if the tag values aren't updated centrally. While local blocks are useful, they shouldn't be used for fundamental configuration like tagging.
11 / 15
Reviewer: 'I'm seeing a lot of repeated `aws_s3_bucket` configurations across our modules. This module seems to be handling the bucket creation and permissions. Could we consider encapsulating this logic into a reusable module for S3 buckets? It would improve consistency and reduce duplication.' What is the reviewer primarily suggesting regarding the design of this module?
The reviewer is advocating for modularization to reduce redundancy and improve maintainability. They specifically mention 'DRY' which highlights the importance of avoiding duplicated code across multiple modules. Options A and D are incorrect because they limit the module's scope unnecessarily; option B would not address the core issue of duplication.
12 / 15
Dev1 (Sarah): 'Just deployed the new staging module. The output is showing an 'aws_ec2_instance.webserver' endpoint with a value of private IP: 10.0.0.5. Is that normal?' What does Sarah likely need to understand about the module's outputs?
Sarah's question reveals she needs to understand that module outputs often provide details about the resources created by the module. The private IP address of an EC2 instance is a critical piece of information for configuring network connectivity within her deployment environment. Option A is incorrect as private IPs are not publicly accessible.
13 / 15
PR Description: 'Updated the `compute` module to include a new variable, `instance_type`, allowing users to specify the EC2 instance type. Added validation to ensure only supported types are used. This improves flexibility and allows for targeted resource sizing.' What is the primary benefit described in this PR description regarding the module's design?
The description explicitly states 'improved flexibility and control…through variable customization.' This highlights a key benefit of IaC modules – allowing users to tailor configurations based on their specific needs. Options A and C are incorrect because they present negative consequences; option D is irrelevant.
14 / 15
Engineer (Mark): 'I'm working on a module for deploying our application servers. I've added a default value to the `instance_count` variable – setting it to 2. This simplifies initial deployments.' What does Mark's action primarily demonstrate about good IaC module design?
Mark's addition of a default value demonstrates the principle of providing sensible defaults to simplify common use cases. This reduces the amount of configuration required by users and makes the module easier to adopt. Option A is incorrect because it contradicts best practices; option C is too restrictive.
15 / 15
Reviewer: 'This module uses a `local` block to define common tags for all resources. It's good practice to avoid hardcoding these values directly within the resource definitions themselves.' What is the reviewer's primary concern regarding this approach?
The reviewer's concern centers on maintaining consistency and avoiding duplication. Hardcoding tags within resource definitions can lead to inconsistencies across different environments or deployments if the tag values aren't updated centrally. While local blocks are useful, they shouldn't be used for fundamental configuration like tagging.
What will I practise in "IaC Module Design Vocabulary Exercises"?
Practice English for Terraform module design: output values, variable validation, module registry, DRY principles, and tag governance vocabulary for senior infrastructure and platform engineers.
How many exercises are in this module?
This module has 15 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Infrastructure as Code exercises?
Browse the full Infrastructure as Code hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.