Advanced module usage and registry practices practice questions

A module enforces standards by keeping opinionated settings inside and exposing only the choices that belong to the caller.

Encapsulating organisational standards is a core reason to write a module: the module's interface is its inputs, so anything not exposed as an input cannot be changed by callers. Exposing every argument with secure defaults looks flexible but lets callers override the controls, and shared tfvars or locals rely on every team wiring them correctly.

1. List what must be guaranteed and what callers may choose.
2. Check whether each option lets a caller override a guaranteed control.
3. Prefer the option whose inputs are only the caller-owned decisions.

Exam tip: What a module does not expose as an input, its callers cannot change.

Choosing between a local module, a versioned shared module and plain for_each depends on who reuses the code and how they adopt changes.

All four options reduce duplication in this root. The deciding constraints are reuse by other root configurations and independent upgrades. Only a module published with release tags (or in a registry) that callers pin satisfies both: each team chooses when to change its pinned version. A local ./modules path is not consumable as a release by other repositories, for_each is not reusable at all, and a branch reference pushes every change to every caller at once.

1. Confirm that every option removes the copies in this root.
2. Apply the first constraint: other root configurations must reuse it.
3. Apply the second: each consumer adopts updates on its own schedule.
4. Only a released, pinnable module meets both.

Exam tip: Reuse across configurations plus independent upgrades means a versioned module, not a local path or a branch.

HashiCorp recommends against modules that are thin wrappers around a single resource type.

A good module raises the level of abstraction by describing a new concept built from several resources. A module that exposes exactly one resource's arguments makes callers learn a second interface for the same thing. The guidance is to use the resource directly; one hint is that you cannot name the module anything other than its main resource type.

1. Count what the module adds: one resource, arguments passed straight through.
2. Recall HashiCorp's guidance on thin wrappers.
3. Reject options that decorate, relocate or version the wrapper without adding a concept.

Exam tip: If a module mirrors one resource, use the resource.

A module should introduce a new architectural concept composed of several resources.

HashiCorp's guidance describes modules as containers for resources that are used together, ideally forming a higher-level concept such as a service with its networking, identity and DNS. Single-resource wrappers, whether they pass arguments through or rename them, add interface without abstraction. Combining several resource types is not enough on its own: a catch-all module that bundles shared networking with every team's services behind create_* flags mixes owners and change rates, and the composition guidance favours small modules composed in the root instead.

1. For each proposal, ask what new concept a caller gets.
2. Discard single-resource wrappers, whether they pass arguments through or rename them.
3. Discard catch-all modules steered by create_* flags.
4. Choose the proposal that composes one service's resources into one unit.

Exam tip: A module earns its place by adding a concept, not by renaming a resource.

Scope modules by volatility: keep long-lived, stateful infrastructure apart from frequently changed infrastructure.

HashiCorp's module creation pattern names three scoping tests: encapsulation (group what is always deployed together), privileges (respect team privilege boundaries) and volatility (separate long-lived from short-lived infrastructure). A database that changes yearly and services that change daily fail the volatility test, so they belong in separate modules. prevent_destroy is a workaround that keeps the coupling, and splits along other lines (networking, IAM) leave the database and the services together.

1. Note the different change rates in the stem.
2. Recall the volatility rule from HashiCorp's module creation guidance.
3. Check each split: does it separate the database from the services?
4. Reject options that keep both together, even if they split something else.

Exam tip: Separate what changes yearly from what changes daily.

Encapsulation, privileges and volatility decide module scope; a dependency between resources does not.

The guidance groups resources that are always deployed together, restricts modules to privilege boundaries and separates long-lived from short-lived infrastructure. Security-administered KMS keys cross a privilege boundary with application code, and daily functions differ in volatility from the database. Dependencies such as functions using a key are expressed by passing the key ARN as an input, so they do not force co-location. One module per resource type swings to the opposite anti-pattern.

1. Identify ownership: network, security and application teams.
2. Identify change rates: daily functions versus a long-lived database.
3. Apply the privilege and volatility rules to choose the splits.
4. Remember that dependencies flow through inputs, not shared modules.

Exam tip: Split by who may change it and how often it changes; wire dependencies through inputs.