AWS provider Practice Test 9 — 10 Questions

Question 1

You need to output a complex object from a child module to be used by the root module. What is the best practice for defining the output?

Accepted Answer

Define an output block in the child module and reference it in the root module using the module prefix.. Using explicit output blocks in the child module makes the data available for access via 'module..'.

Answer

Assign the output to a global variable in the root module.

Answer

Use a data source to read the child module's internal state.

Answer

Write the output to a local file inside the module and read it in the root.

Question 2

You are attempting to use a conditional expression to set a variable, but the types returned by the true and false results differ. What happens?

Accepted Answer

A type mismatch error is returned. In Terraform, a conditional expression requires both the true and false results to be of the same type. If they differ, Terraform returns a type mismatch error during evaluation. This is because Terraform's type system is strict and does not perform implicit type coercion in conditional expressions.

Answer

The result is coerced to a string

Answer

It defaults to the true result type

Answer

Terraform automatically casts to the most flexible type

Question 3

In a workspace, you define a variable named 'region'. How can you override this value for a specific run without changing the workspace configuration?

Accepted Answer

Using -var flag in terraform apply. The '-var' flag allows you to override a variable's value for a specific Terraform run without modifying the workspace configuration. For example, 'terraform apply -var='region=us-west-2'' sets the value for that run only. Other options do not provide a way to override variables per run.

Answer

By editing the state file

Answer

By modifying the provider block

Answer

By adding a new workspace

Question 4

When refactoring a large infrastructure configuration, you move a resource into a child module. How do you handle the existing state to prevent Terraform from destroying and recreating the resource?

Accepted Answer

Use the 'terraform state mv' command to move the resource address.. When a resource is moved into a child module, its address in state changes from something like 'aws_instance.web' to 'module.child.aws_instance.web'. Terraform sees these as different resources and would plan a destroy/create. The 'terraform state mv' command updates the state address in place, preserving the existing resource without any API calls.

Answer

Run 'terraform refresh' to automatically detect the move.

Answer

Rename the resource in the configuration to match the old state.

Answer

Delete the state file and run 'terraform apply'.

Question 5

Which TWO of the following are true regarding OPA/Sentinel policies?

Accepted Answer

They can be set to advisory mode. Option C is correct because both OPA and Sentinel policies support an advisory (soft-mandatory) enforcement mode, which reports policy violations without blocking the run, unlike hard-mandatory mode that fails the run. Option D is correct because policies can be scoped to specific workspaces, allowing different policy sets to apply only to designated workspaces rather than globally. Option A is incorrect because OPA/Sentinel policies are evaluated during the plan phase (pre-apply), not after apply. Option B is incorrect because these policies are cloud-agnostic and work with any provider, not just AWS. Option E is incorrect because policies govern Terraform configuration compliance and do not replace IAM, which controls authentication and authorization to cloud resources.

Answer

They run after the apply phase

Answer

They can only be used with AWS

Answer

They replace the need for IAM

Question 6

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 7

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 8

Which THREE of the following are consequences of drifting from the Terraform state?

Accepted Answer

The plan may show changes even if the config hasn't changed.. Option A is correct because Terraform compares the configuration against the recorded state to build the plan; if real infrastructure has drifted from that state, the refresh will detect differences and the plan can show changes even though the .tf configuration itself was never modified. Option B is correct because if someone manually deletes a resource that still exists in the state file, the next refresh/plan will fail to find it and Terraform reports an error such as 'Resource Not Found' (or removes it from state depending on version), breaking the expected mapping between state and reality. Option D is correct because when drift is detected, Terraform's plan will propose actions to bring the real infrastructure back in line with the configuration, so the next apply may revert the out-of-band manual changes. Option C is not correct because lifecycle meta-arguments (create_before_destroy, prevent_destroy, ignore_changes, replace_triggered_by) are configuration-level features and are not disabled by state drift. Option E is not correct because Terraform never rewrites your configuration files automatically; drift only affects the state and the plan, not the .tf source code.

Answer

It disables the use of lifecycle meta-arguments.

Answer

It automatically updates the configuration file.

Question 9

Which THREE of the following are true about 'lifecycle' blocks?

Accepted Answer

They are defined inside the resource configuration block.. Option A is correct because lifecycle blocks are nested meta-arguments declared inside a resource block (e.g., resource "aws_instance" "example" { lifecycle { ... } }), not at the top level or in provider blocks. Option B is correct because a single lifecycle block can contain multiple arguments simultaneously, such as create_before_destroy, prevent_destroy, ignore_changes, and replace_triggered_by. Option E is correct because lifecycle settings are processed during the plan phase, where Terraform determines actions like replacement (create_before_destroy) and diffs to ignore (ignore_changes) before producing the execution plan. Option C is not correct because provider versions are constrained via the required_providers block and version arguments, not lifecycle. Option D is not correct because lifecycle is a resource-level meta-argument and is not inherited from provider blocks.

Answer

They allow changing the provider version dynamically.

Answer

They are inherited from the provider block.

Question 10

Which argument in a module block allows you to provide a custom name to the module instance?

Accepted Answer

The label immediately following the 'module' keyword.. In Terraform, a module block is declared as `module "<LABEL>" { ... }`, where the label immediately following the `module` keyword is the local name (instance name) used to reference the module within the configuration. This label is how you distinguish multiple instances of the same module source and how you reference module outputs (e.g., `module.my_module.output_name`).

Answer

'name'

Answer

'instance_name'

Answer

'alias'