AWS provider Practice Test 5 — 10 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.