AWS provider Practice Test 8 — 10 Questions

Question 1

What is the purpose of the 'terraform init' command when working with modules?

Accepted Answer

It downloads and installs the modules specified in the configuration.. 'terraform init' downloads and installs the modules specified in the configuration into the '.terraform/modules' directory.

Answer

It compiles the modules into machine code.

Answer

It pushes your local modules to the registry.

Answer

It updates the state file to match the modules.

Question 2

You are developing a Terraform module that creates an AWS EC2 instance. You want to expose the instance's private IP address to the caller. How should you define this in the module?

Accepted Answer

Add an output block in the module that references the instance's private_ip attribute.. Outputs are the mechanism for a module to return values to its caller. By defining an output that references the EC2 instance's private_ip attribute, the parent module can access it using module... This is the intended and most efficient way to expose resource attributes from a child module. Other options either do not work or are overly complicated.

Answer

Define a local value in the module and reference it in the root module.

Answer

Use a variable in the module to pass the private IP address to the caller.

Answer

Use a data source in the root module to look up the EC2 instance by its tags.

Question 3

When using 'for_each' on a list of strings, what must you do to ensure the configuration is stable?

Accepted Answer

Convert the list to a set. for_each requires a map or set of strings, not a list, because list indices are positional and unstable — inserting or removing an element shifts every subsequent index, causing Terraform to destroy and recreate resources. Converting the list to a set (e.g., toset(var.list)) gives each element a stable key based on its value, so resource addresses remain consistent across changes.

Answer

Use count instead

Answer

Use the index

Answer

Nothing, it's always stable

Question 4

When using multiple provider instances with different regions, what must be defined in the provider configuration?

Accepted Answer

A unique alias identifier.. When you declare multiple instances of the same provider (e.g., two `aws` providers for different regions), each non-default instance must have a unique `alias` argument. Resources then select the desired instance using the `provider = aws.<alias>` meta-argument. Without an alias, Terraform cannot distinguish the instances and errors on duplicate provider configuration.

Answer

A unique project ID.

Answer

A credentials object.

Answer

A version constraint in each block.

Question 5

Your team requires a custom module to be versioned strictly to prevent breaking changes during deployments. What is the recommended way to reference a module from a private Git repository?

Accepted Answer

Use the 'ref' parameter in the source URL string.. For modules sourced from a private Git repository, Terraform does not support a separate 'version' argument; instead, you pin to a specific commit, tag, or branch using the 'ref' query parameter appended to the source URL (e.g., 'git::https://example.com/module.git?ref=v1.2.0'). This locks the module to an immutable Git reference, preventing unexpected breaking changes when the repository's default branch moves forward. The 'ref' parameter is the only supported mechanism for version pinning with Git-based module sources.

Answer

Set the 'version' block inside the module definition.

Answer

Copy the module code locally every time a new version is released.

Answer

Use the 'module_version' argument in the module block.

Question 6

How can you protect a module's inputs from receiving incorrect types of data?

Accepted Answer

Use a 'validation' block with a condition inside the variable declaration.. Terraform's variable validation block, introduced in Terraform 0.13, allows you to define a condition expression that must evaluate to true for the variable value to be accepted. When placed inside a variable declaration, it can check the type, format, or range of the input and produce a custom error message if the condition fails. This is the native, declarative way to enforce input constraints at plan time, preventing invalid data from propagating into the module.

Answer

Use the 'provider' block to enforce input types.

Answer

Write a custom bash script to check the inputs.

Answer

Terraform automatically validates all inputs as strings.

Question 7

When using 'create_before_destroy', what is a common side effect that may cause the plan to fail?

Accepted Answer

Resource naming collisions.. With create_before_destroy, Terraform creates the new resource before destroying the old one. If the resource has a unique name or identifier (e.g., an AWS resource with a fixed name), the new resource may conflict with the existing one, causing the plan to fail due to naming collisions.

Answer

Terraform will delete the state file.

Answer

Provider credentials will expire.

Answer

All other resources will be destroyed.

Question 8

Which THREE of the following are valid ways to transform data for Terraform configuration?

Accepted Answer

flatten(). Option A, flatten(), is correct because it is a built-in Terraform function that takes a list of lists and transforms it into a single flat list, which is a valid data transformation for configuration. Option B, merge(), is correct because it is a built-in Terraform function that combines multiple maps or objects into one map, a common way to transform and consolidate data in Terraform. Option E, for expressions, is correct because Terraform's for expressions iterate over lists, sets, maps, or objects to produce a new transformed list or map, making them a core transformation mechanism. Option C, split_map(), is not a valid Terraform function, so it cannot transform data. Option D, loop(), is not a Terraform construct; iteration is handled by for expressions, count, or for_each, not a loop() function.

Answer

split_map()

Answer

loop()

Question 9

Where can you define variables that apply to all workspaces within an organization in HCP Terraform?

Accepted Answer

In a Variable Set.. In HCP Terraform (formerly Terraform Cloud), a Variable Set is a named collection of variables that can be applied to multiple workspaces across an organization. Variable Sets are designed specifically to share variables globally or across selected workspaces, making them the correct mechanism for organization-wide variable definitions. They can contain both Terraform variables and environment variables, and can be scoped to all workspaces or a subset.

Answer

In the Private Module Registry.

Answer

In the individual workspace configuration.

Answer

In the organization settings directly.

Question 10

You are configuring RBAC in HCP Terraform. A user needs to trigger runs and view plan logs but should not be allowed to modify workspace variables. Which permission set is appropriate?

Accepted Answer

Grant 'Read' and 'Queue Plan' permissions.. The 'Read' and 'Queue Plan' permissions allow a user to view workspaces and trigger runs, but not modify variables. This follows the principle of least privilege for the required actions.

Answer

Grant Admin access.

Answer

Grant 'Manage Variables' permission.

Answer

Grant 'Write' permission to the workspace.