002 · Domain 6: Advanced Module Usage and Registry Practices · 10% of the exam
Task 6.1: Understand when to refactor a Terraform configuration into a module
When a module earns its keep: repeated patterns, encapsulation and ownership, the cost of thin wrappers, and moving existing resources into a module with moved blocks.
Study it
When a module earns its keep, and moving resources into one
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
A platform team is deciding which of four proposals to turn into a shared module. Following HashiCorp's guidance on when to write a module, which proposal is the strongest candidate?
AA module that wraps aws_s3_bucket alone and exposes each of its arguments as a variable
BA module for each resource type in the account, giving every team the same wrappers
CA log-archive module that combines a bucket, its policy, lifecycle rules and replication
DA module that contains one locals block holding the organization's naming rules
Show the answer and why
AA module that wraps aws_s3_bucket alone and exposes each of its arguments as a variable
Incorrect
HashiCorp advises against thin wrappers around a single resource type; callers can use the resource directly.
BA module for each resource type in the account, giving every team the same wrappers
Incorrect
Wrapping every resource type adds layers without describing any new concept in the architecture.
CA log-archive module that combines a bucket, its policy, lifecycle rules and replication
Correct
A good module describes a higher-level concept built from several resources that are used together, such as a log archive.
DA module that contains one locals block holding the organization's naming rules
Incorrect
It describes no infrastructure concept; the guidance on when to write a module is about raising the level of abstraction over resources.
Write a module when it raises the level of abstraction. If the only good name for a module is the name of the resource inside it, the module is probably adding complexity rather than removing it.
A shared module with three instances has grown too large and will be split into modules x and y. Existing callers must upgrade without replacing any object. What should the original module become?
AA shim that calls x and y and holds moved blocks into them
BAn empty module, with callers running terraform state mv
CA copy of x and y kept side by side for a release
DA deprecated module that destroys and recreates its resources
Show the answer and why
AA shim that calls x and y and holds moved blocks into them
Correct
The original keeps only shim configuration: calls to the new modules plus moved blocks from the old addresses into them.
BAn empty module, with callers running terraform state mv
Incorrect
moved blocks remove the need for manual state commands.
CA copy of x and y kept side by side for a release
Incorrect
Duplicated resources would create second copies of every object.
DA deprecated module that destroys and recreates its resources
Incorrect
The goal is to keep existing objects.
New callers may use the shim or the two new modules directly; existing callers keep their objects through the moved blocks.
A platform team is refactoring five application teams' copied messaging configurations into one shared module. Most teams need the same queue, dead-letter queue and alarms; one team also wants strict ordering, and another a cross-region forwarder that no one else uses. What does HashiCorp's module creation pattern recommend for the module's first release?
AFeature flags with conditional blocks so all five teams adopt it at once
BA separate copy of the module for each team, tuned to its own needs
CNo release until every team's requirements are gathered and built in
DA minimum viable product that covers at least 80% of the use cases
Show the answer and why
AFeature flags with conditional blocks so all five teams adopt it at once
Incorrect
The guidance says to avoid conditional expressions in a first version and never to code for edge cases in modules.
BA separate copy of the module for each team, tuned to its own needs
Incorrect
Copies bring back the duplication that the refactor is meant to remove; modules should follow the DRY principle.
CNo release until every team's requirements are gathered and built in
Incorrect
Modules are never complete, so the guidance aims the first versions at a minimum viable product, starting from an early adopter team.
DA minimum viable product that covers at least 80% of the use cases
Correct
The MVP guidelines say to deliver a module that works for at least 80% of use cases and to leave rare edge cases out.
Rare needs can wait for a later version or stay with the team that has them. A narrow first version is easier to explain, test and adopt, and its scope can grow with requirements gathered from its users.
A compute module must use a special disk image in some environments and a shared existing one in others. What does the module composition guidance recommend?
AA create_image flag with count inside the module
BA data source in the module that fails over to a resource
CAn object input, filled by a resource or a data source
DTwo copies of the module, one per environment type
Show the answer and why
AA create_image flag with count inside the module
Incorrect
The guidance advises against modules that detect or create objects conditionally.
BA data source in the module that fails over to a resource
Incorrect
Modules should not try to detect whether something exists.
CAn object input, filled by a resource or a data source
Correct
Declare an object variable with only the needed attributes, such as id and architecture, and let the caller pass a resource or a data source.
DTwo copies of the module, one per environment type
Incorrect
Duplication defeats reuse.
Terraform accepts any object with at least the declared attributes, so both resource and data source objects fit.