AWS provider Terraform Modules Practice Test 3 — 15 Questions

Question 1

What is the impact of using 'sensitive = true' in a module output?

Accepted Answer

It prevents the value from being printed in the CLI output.. Marking an output as 'sensitive = true' tells Terraform to redact the value from CLI output, including plan and apply logs, so credentials are not displayed on screen. The value is still stored in state and can still be consumed by other modules or resources. It is a display-level protection, not an encryption or access-control mechanism.

Answer

It disables the ability to use that output in other modules.

Answer

It encrypts the data in the state file.

Answer

It automatically rotates the sensitive credentials.

Question 2

You need to share a module across your entire organization. Which registry type should you use?

Accepted Answer

A private module registry in Terraform Cloud or Enterprise.. A private module registry in Terraform Cloud or Enterprise is the correct answer because it is purpose-built for sharing Terraform modules within an organization. It provides versioned, discoverable modules with access control, integrates natively with Terraform CLI/Cloud workflows, and supports private module sourcing via the `terraform init` command. This ensures secure, consistent, and governed reuse across teams, which is exactly what the scenario requires.

Answer

The public Terraform Registry.

Answer

A shared network drive.

Answer

An S3 bucket with public read access.

Question 3

What is the recommended approach for managing a module that has grown too large?

Accepted Answer

Break the module into smaller, focused sub-modules.. Breaking a large module into smaller, focused sub-modules is the recommended approach because it improves reusability, testability, and blast-radius control. Each sub-module encapsulates a single logical concern (e.g., networking, compute, IAM), making plans faster and state operations safer. Terraform's module composition model is designed for this kind of decomposition, and refactoring can be done with 'moved' blocks to avoid destroying resources.

Answer

Use 'terraform import' to split the resources.

Answer

Combine all files into a single 'main.tf'.

Answer

Rename the module to something more generic.

Question 4

When a module is updated, how do you ensure that all environments using this module get the update?

Accepted Answer

Run 'terraform init -upgrade' to fetch the latest version allowed by the constraints.. Terraform modules sourced from a registry or VCS are cached locally after the first 'terraform init'. To pull a newer version that satisfies the version constraint in the module block, you must run 'terraform init -upgrade', which re-resolves the version and downloads the latest allowed release. Without this flag, Terraform reuses the cached module even if a newer version exists, so environments won't pick up the update.

Answer

The module updates automatically on every 'apply'.

Answer

Delete the state file and re-run apply.

Answer

Restart the Terraform CLI process.

Question 5

What command do you run to view the documentation for a module that has been published to a registry?

Accepted Answer

Check the registry website for the module page.. Terraform has no CLI subcommand for browsing registry module documentation; the canonical way to read a published module's inputs, outputs, and examples is the registry website page for that module. The registry renders the README and auto-generates the input/output tables from the module's variables.tf and outputs.tf. So checking the registry website is the correct answer.

Answer

'terraform view-module'

Answer

'terraform show'

Answer

'terraform doc <module>'

Question 6

Why would you use a 'locals' block within a module instead of passing everything through variables?

Accepted Answer

To reduce repetition and perform transformations on inputs.. A 'locals' block lets you define named expressions that can be reused throughout the module, reducing repetition and enabling transformations (e.g., string concatenation, merging maps, computing tags) on input variables. Locals are computed once per plan and referenced as 'local.name'.

Answer

To allow the user to override internal values easily.

Answer

To bypass input validation.

Answer

To store state data securely.

Question 7

Which THREE actions are best practices when publishing a module to a private registry?

Accepted Answer

Use Semantic Versioning (SemVer) for all releases.. Option A is correct because Semantic Versioning (MAJOR.MINOR.PATCH) gives consumers a predictable contract: breaking changes bump MAJOR, backward-compatible features bump MINOR, and fixes bump PATCH, which private registries rely on for version constraints and dependency resolution. Option B is correct because an 'examples/' directory provides runnable usage snippets that document real inputs/outputs and let consumers validate the module before adopting it. Option D is correct because a root-level README.md is the primary documentation surface a private registry renders, explaining purpose, inputs, outputs, and usage. Option C is not a best practice because mixing tests and all files in the root harms maintainability; tests belong in a 'tests/' or 'test/' directory and modules should be organized into logical subfolders. Option E is not a best practice for a module because the 'terraform-provider-' prefix is a naming convention for Terraform providers, not reusable modules, so it would be misleading.

Answer

Keep all files in the root folder, including tests.

Answer

Prefix the repository name with 'terraform-provider-'.

Question 8

Which THREE of these are benefits of using modules in Terraform?

Accepted Answer

Enforcing standardized configurations across teams.. Option C is correct because modules let platform teams publish a single, versioned implementation of a resource pattern (for example, a standard VPC or S3 bucket baseline) that every team consumes, so required tags, naming conventions, and security settings are applied consistently instead of being re-implemented per team. Option D is correct because a module is written once and then instantiated with different inputs for dev, staging, and production, eliminating the copy-paste of near-identical .tf resource blocks across environments. Option E is correct because a module exposes a small, typed interface of input variables and outputs while hiding the internal resource graph, so callers pass a few values and receive outputs without needing to understand every underlying resource and dependency. Option A is not a module benefit: Terraform still makes the same provider API calls, and module expansion happens at plan time, so execution speed is not inherently improved. Option B is not a module benefit: drift detection and remediation depend on state refresh and plan/apply behavior, and modules do not automatically prevent out-of-band changes to resources.

Answer

Increasing the execution speed of API calls.

Answer

Automatically preventing all resource drift.

Question 9

Which TWO of the following are true regarding variable validation in modules?

Accepted Answer

Validation blocks must return a boolean value.. Option A is correct because a Terraform variable validation block uses a condition expression that must evaluate to a boolean (true/false); if it evaluates to false, Terraform raises the error_message. Option D is correct because within a module, input variable names are arbitrary identifiers chosen by the author, but each variable name must be unique within that module's variable namespace. Option B is wrong because validation failures are surfaced during terraform plan (and validate), not only at apply time. Option C is wrong because validation conditions can only reference the variable itself and cannot read values from other modules or resources. Option E is wrong because validation blocks work with any variable type, including number, bool, list, map, and object, not just strings.

Answer

Validation errors will only show during 'terraform apply'.

Answer

Validation blocks can read from other modules.

Answer

You can only validate string variables.

Question 10

Which THREE items should be included in a well-documented Terraform module?

Accepted Answer

Clear documentation for each output.. Option B is correct because documenting each output (its name, type, and meaning) lets consumers know what values the module returns and how to reference them, which is essential for reusable module interfaces. Option C is correct because every input variable should have a description so users understand its purpose, expected type, default, and whether it is required, making the module self-explanatory. Option E is correct because providing a usage example showing how to call the module with realistic inputs demonstrates correct invocation and accelerates adoption. Option A is not appropriate because listing all possible provider configurations is impractical and unnecessary; provider requirements should instead be declared via required_providers and documented as constraints. Option D is wrong because raw state files contain sensitive data and environment-specific resource mappings, should be stored remotely with locking, and are never part of module documentation.

Answer

A list of all possible provider configurations.

Answer

The raw state file of the module's resources.

Question 11

Which TWO of the following are true about the '.terraform' directory?

Accepted Answer

It contains the module source code downloaded from registries.. Option A is correct because the .terraform directory is where terraform init caches downloaded modules, including module source code fetched from registries or other sources, under .terraform/modules. Option D is correct because terraform init is the command that initializes a working directory and creates/populates the .terraform directory with providers, modules, and backend metadata. Option B is not correct because .terraform is a local cache that should be excluded from version control, typically via .gitignore. Option C is not correct because the state file (terraform.tfstate) is stored in the working directory or a configured remote backend, not permanently inside .terraform. Option E is not correct because provider binaries are downloaded as precompiled plugins into .terraform/providers, not compiled there.

Answer

It should be committed to version control.

Answer

It contains the permanent state file.

Answer

It is where custom provider binaries are compiled.

Question 12

Which THREE of the following are components of the 'source' string when using the Terraform Registry?

Accepted Answer

Provider.. The Terraform Registry module source string follows the format //, so option B (Provider) is correct because the provider segment (e.g., aws, azurerm, google) identifies which provider the module targets. Option D (Module name) is correct because it is the middle segment that names the specific module being referenced. Option E (Namespace) is correct because it is the first segment, identifying the organization or user that publishes the module. Option A (Git branch name) is not part of the Registry source string; branch/ref syntax (e.g., ?ref=) applies to generic Git sources, not the Registry's three-part address. Option C (Operating system) is irrelevant, as the Registry source string does not encode any OS information.

Answer

Git branch name.

Answer

Operating system.

Question 13

Which TWO of the following are valid ways to pass a provider configuration to a child module?

Accepted Answer

Using the 'providers' meta-argument inside the module block.. Option B is correct because Terraform supports the 'providers' meta-argument inside a module block, which explicitly maps a provider configuration from the parent (root) module to a specific provider alias expected by the child module, e.g. 'providers = { aws = aws.usw2 }'. Option E is correct because Terraform automatically inherits the default (unaliased) provider configurations from the root module into child modules, so a child module using 'aws' without its own provider block receives the root's default AWS provider configuration. Option A is not a way to pass a configuration from the parent; defining a provider inside the module's main.tf creates a separate provider configuration local to the module rather than passing one in. Option C is invalid because provider configurations are complex objects, not strings, and cannot be supplied via input variables. Option D is invalid because Terraform has no concept of a 'global variable' for provider credentials; credentials belong in provider blocks or environment variables, not a global variable mechanism.

Answer

Defining the provider inside the module's 'main.tf'.

Answer

Passing the provider as a string input variable.

Answer

Using a global variable for provider credentials.

Question 14

A platform team maintains a module that provisions a VPC and subnets. They want to expose the subnet IDs to callers without allowing callers to modify them. Which Terraform construct should they use in the module?

Accepted Answer

An output block in the module that references the subnet IDs. Output blocks are the supported mechanism for a module to return values to its caller. Because outputs are read-only from the caller's perspective, they naturally expose computed attributes such as subnet IDs without giving callers a way to overwrite them. Variables, locals, and provisioners do not provide that read-only outward-facing contract.

Answer

A resource block with provisioner 'local-exec' that writes the IDs to a file

Answer

A locals block in the module that stores the subnet IDs

Answer

A variable block in the module with type = list(string)

Question 15

A module uses for_each over a map to create several IAM roles, and the map keys are derived from a variable that callers may change. The team wants to avoid replacing roles when only the map's values change. Which change to the module is required?

Accepted Answer

Ensure the for_each keys are stable and derived only from values that should not change. for_each instances are addressed by their map keys, so key stability is what determines whether Terraform updates or replaces resources. When only values change, in-place updates occur. count and lifecycle rules do not change instance identity, and sensitivity is unrelated to addressing, so ensuring stable keys is the correct approach.

Answer

Replace for_each with count and index into the list

Answer

Add lifecycle { create_before_destroy = true } to the role resource

Answer

Mark the for_each map as sensitive in the variable definition