AWS provider Practice Exam 3 — 20 Questions

Question 1

What are common reasons to use multiple provider instances? (Select TWO)

Accepted Answer

Using different credentials for different resources.. Option D is correct because multiple provider instances (created with the alias meta-argument) let you attach distinct credential sets to different resources, for example managing resources in separate AWS accounts or with different IAM roles within one configuration. Option E is correct because aliased provider instances are the standard way to target multiple AWS regions in a single configuration, such as provider "aws" { alias = "us_east" } and provider "aws" { alias = "eu_west" }, then referencing them per resource. Option A is not a reason for multiple provider instances, since Terraform CLI performance is governed by parallelism and graph execution, not by the number of provider configurations. Option B is incorrect because provider versions are pinned in the required_providers block, not by instantiating multiple provider instances. Option C is incorrect because a state file is always required for tracking real infrastructure; provider aliases do not eliminate it.

Answer

Increasing performance of the Terraform CLI.

Answer

Installing multiple versions of the same provider.

Answer

Bypassing the need for a state file.

Question 2

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 3

A resource has an attribute 'tags' that is managed by an external script. You want Terraform to ignore any changes made to 'tags' after the initial creation. How should you configure the 'lifecycle' block?

Accepted Answer

ignore_changes = [tags]. The 'ignore_changes' argument within a lifecycle block tells Terraform to ignore changes to the specified attributes after resource creation. Setting 'ignore_changes = [tags]' ensures that any external modifications to the tags attribute are not detected as drift, preventing Terraform from reverting them. This is the correct way to handle attributes managed outside of Terraform.

Answer

lifecycle { tags = ignore }

Answer

prevent_destroy = [tags]

Answer

ignore_changes = [all]

Question 4

A Sentinel policy is failing on a cost estimation result. What is the most likely cause if the cost estimation feature is enabled but the policy still fails?

Accepted Answer

The policy attempts to access cost data before the estimation has completed.. Cost estimation in Terraform Cloud runs asynchronously after the plan. If a Sentinel policy references cost data (e.g., 'tfrun.cost_estimate') before the estimation has completed, the policy will fail because the data is not yet populated. This is the most likely cause when cost estimation is enabled but the policy still fails.

Answer

The cost estimation provider is not configured for AWS.

Answer

The workspace does not have Sentinel enabled.

Answer

The API key for AWS is invalid.

Question 5

You are writing a Terraform configuration that uses a dynamic block to generate multiple ingress rules within an aws_security_group resource. The dynamic block iterates over a variable named ingress_rules. Inside the content block, you need to reference the current rule. Which expression correctly accesses the current element?

Accepted Answer

rule.value. Inside a dynamic block, the iterator object is named after the block's label unless an iterator argument is explicitly provided. With a dynamic block labeled rule, the current element is accessed via rule.value. This allows the content block to reference attributes of the current item. The other options confuse the iterator with other meta-argument contexts or with the variable name.

Answer

ingress_rules.value

Answer

each.value

Answer

dynamic.value

Question 6

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 7

What happens if you set 'ignore_changes = all' in a resource lifecycle block?

Accepted Answer

It causes Terraform to ignore all changes to the resource attributes.. Setting ignore_changes = all in a lifecycle block tells Terraform to ignore all attribute changes for that resource, so drift or configuration changes to attributes will not trigger updates. Terraform still manages the resource's existence, creating or destroying it as needed, but it will not modify attributes. This is useful for resources managed partly outside Terraform.

Answer

It disables the prevent_destroy rule.

Answer

It ignores the resource existence entirely.

Answer

It causes a syntax error.

Question 8

A platform engineer is preparing a Terraform configuration that will run in an environment where the AWS provider must be pinned to a specific minor version, and the provider must be sourced from the public Terraform Registry. The engineer also wants to ensure that `terraform init` records the selected version and checksums for later verification. Which two actions should the engineer take? (Choose two.)

Accepted Answer

Add a `required_providers` block in the `terraform` block specifying the AWS provider with a `source` of `hashicorp/aws` and a version constraint such as `~> 5.40.0`.. Declaring the AWS provider in `required_providers` with a `~>` version constraint pins the minor version and confirms the public registry source, while committing the generated lock file preserves the exact version and checksums for reproducible, verified installs. Together these actions enforce version discipline and integrity across runs.

Answer

Add a `provider "aws"` block with a `version` argument set to the desired minor version.

Answer

Set the `TF_CLI_CONFIG_FILE` environment variable to point at a file that contains the provider version constraint.

Answer

Run `terraform providers lock -platform=linux_amd64` to generate checksums for all platforms.

Question 9

Your organization uses HCP Terraform with remote runs. A workspace named 'prod-network' has its execution mode set to Remote. A platform engineer runs `terraform apply` locally after running `terraform plan` on their laptop, but the apply fails with an error because the workspace's state is locked by an active remote run. What is the most likely explanation for this error?

Accepted Answer

A remote run is currently in progress in the workspace, holding the state lock, so a local apply cannot proceed until it finishes or is canceled.. With remote execution mode, all runs occur in HCP Terraform and the workspace state is locked during an active run. A local apply cannot acquire the lock while a remote run is in progress. The engineer must coordinate with the remote run, typically by waiting or canceling, rather than attempting a local apply.

Answer

The workspace's state is stored locally because the backend configuration is missing, causing a lock conflict with the remote run.

Answer

The local CLI is not authenticated to HCP Terraform, so it cannot acquire the state lock.

Answer

The workspace's execution mode is set to Local, so HCP Terraform cannot accept remote applies.

Question 10

An `aws_instance` resource has `lifecycle { ignore_changes = [ami] }`. A security team updates the AMI ID in the Terraform configuration to a new hardened image. The instance is currently running an older AMI. What does Terraform plan for this resource during the next `terraform apply`?

Accepted Answer

Terraform reports no changes for the `ami` attribute and leaves the instance as-is.. The ignore_changes lifecycle argument filters out differences for the named attributes when Terraform compares configuration to state. When ami is ignored, a new AMI ID in configuration produces no planned change, so the instance is not replaced and no update is attempted. This is useful for attributes managed outside Terraform, but it also means security-driven AMI updates require removing the ignore entry first.

Answer

Terraform replaces the instance with one built from the new AMI.

Answer

Terraform updates the instance in place to the new AMI without replacement.

Answer

Terraform fails the plan with an error because the AMI differs from state.

Question 11

You need to ensure that a resource is always recreated if an associated data source value changes. Which meta-argument supports this?

Accepted Answer

replace_triggered_by. The replace_triggered_by meta-argument forces Terraform to destroy and recreate the resource whenever any of the referenced attributes or resources change, including data source values. It is designed exactly for the scenario where a resource must be replaced based on an external or computed value rather than a direct attribute reference. When the referenced value changes between plans, Terraform marks the resource for replacement.

Answer

create_before_destroy

Answer

lifecycle_hooks

Answer

prevent_destroy

Question 12

Your organization has a Sentinel policy with enforcement level 'soft-mandatory' that checks for required tags on AWS resources. During a run, the policy fails because an EC2 instance is missing the 'Environment' tag. The workspace allows users with write access to override policies. What is the immediate outcome of the run?

Accepted Answer

The run is paused and a user with appropriate permissions can choose to override the policy and continue the apply.. When a soft-mandatory Sentinel policy fails, the run pauses and users with override permissions can choose to bypass the policy and continue. This allows for exceptions while still enforcing governance. Hard-mandatory policies cannot be overridden, and advisory policies do not block. The scenario specifies soft-mandatory, so the run is paused for possible override.

Answer

The policy failure is logged as an advisory and the run continues automatically without any intervention.

Answer

The run fails immediately and cannot be overridden, requiring the configuration to be fixed and a new run to be queued.

Answer

The run is canceled and the workspace is locked until the policy is updated to pass.

Question 13

You want to trigger a run only when a specific file within a module path changes. How do you configure this?

Accepted Answer

Use the 'VCS Triggers' setting in the workspace.. HCP Terraform (formerly Terraform Cloud) workspaces support VCS Triggers, which let you specify file or directory paths so that a run is only queued when changes are detected in those paths. This is the native mechanism for path-based run triggering tied to version control commits.

Answer

Use a 'trigger_path' variable in the Terraform code.

Answer

Modify the '.terraform-version' file.

Answer

Use a Sentinel policy to filter changes.

Question 14

You have two resources, A and B. You want B to be replaced whenever A is updated. How do you configure B?

Accepted Answer

In resource B, set lifecycle { replace_triggered_by = [resource_a] }. The replace_triggered_by meta-argument in resource B's lifecycle block specifies that B should be replaced when resource A changes. This directly ties B's replacement to A's updates, ensuring B is recreated whenever A is updated.

Answer

In resource B, set lifecycle { create_before_destroy = [resource_a] }

Answer

In resource A, set lifecycle { triggers = [resource_b] }

Answer

In resource B, set depends_on = [resource_a]

Question 15

Which of the following are true regarding the .terraform.lock.hcl file? (Select TWO)

Accepted Answer

It is automatically generated by terraform init.. Option A is correct because the .terraform.lock.hcl dependency lock file is automatically created and updated by the `terraform init` command when it installs providers, recording the exact provider versions and checksums selected. Option E is correct because HashiCorp recommends committing the .terraform.lock.hcl file to version control so that all team members and CI/CD pipelines use the same provider versions and verified checksums, ensuring reproducible runs. Option B is incorrect because Terraform state is stored in the state file (terraform.tfstate or a configured remote backend), not in the lock file. Option C is incorrect because the lock file is normally generated and updated automatically by Terraform commands such as `terraform init` and `terraform providers lock`, though it can be edited manually if needed. Option D is incorrect because the lock file stores provider version constraints and cryptographic hashes, not secret credentials, which should never be placed in it.

Answer

It is used to store the state file.

Answer

It can only be edited manually.

Answer

It stores secret credentials.

Question 16

You want to use a module that is hosted in a private GitHub repository. Which authentication method should Terraform use to access it?

Accepted Answer

Use the same credentials that 'git clone' would use for that repository.. Terraform's module source supports Git URLs and delegates authentication to the underlying Git client. For a private GitHub repository, Terraform uses the same credentials that 'git clone' would use, such as SSH keys, a credential helper, or a personal access token configured in '~/.netrc' or Git config.

Answer

The module must be public for Terraform to access it.

Answer

Terraform requires a special 'git_token' variable in the module block.

Answer

Embed your GitHub password in the source URL.

Question 17

Which function is most useful when you have a nested list of objects and want to create a single flat list to iterate over with for_each?

Accepted Answer

flatten(). The flatten() function takes a nested list (list of lists) and returns a single flat list containing all elements. When you have a nested list of objects and want to iterate with for_each, flatten() collapses the nesting so each object becomes a top-level element that for_each can key on. This is the idiomatic Terraform pattern for iterating over nested collections.

Answer

concat()

Answer

lookup()

Answer

merge()

Question 18

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 19

You are defining an input variable for a Terraform module that will accept a list of AWS subnet IDs. You want to ensure that the variable only accepts a list of strings and that it is required. Which variable declaration correctly achieves this?

Accepted Answer

variable "subnet_ids" { type = list(string) }. The correct variable declaration uses type = list(string) and does not provide a default, making it a required variable. This ensures that callers must supply a list of strings. The other options either make the variable optional, use a different collection type, or use a scalar type, all of which fail to meet the specified requirements.

Answer

variable "subnet_ids" { type = set(string) }

Answer

variable "subnet_ids" { type = list(string) default = [] }

Answer

variable "subnet_ids" { type = string }

Question 20

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.