AWS provider Practice Test 15 — 15 Questions

Question 1

A module needs to render a JSON policy document where the list of allowed actions comes from a variable that may contain duplicates and mixed case, and the final output must be deterministic and free of duplicates. The engineer writes jsonencode({ Version = "2012-10-17", Statement = [{ Effect = "Allow", Action = local.actions, Resource = "*" }] }). Which local definition for local.actions best guarantees determinism and uniqueness?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

actions = sort(distinct([for a in var.actions : lower(a)])). Wrapping the values in a for expression that applies lower() normalizes case, distinct() then collapses duplicates that previously differed only by capitalization, and sort() fixes a stable lexicographic order. The resulting list serializes identically for any caller passing the same logical set of actions, satisfying both determinism and uniqueness for the JSON policy.

Answer

actions = distinct(var.actions)

Answer

actions = sort(distinct(var.actions))

Answer

actions = toset(var.actions)

Question 2

A team wants to ensure that their Terraform configuration always uses a specific version of the AWS provider and that the version constraint is enforced across all modules. They add the following to the root module's terraform block:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

A child module declares the AWS provider without a version constraint. What happens when terraform init is run?

Accepted Answer

Terraform selects the newest AWS provider version that satisfies all constraints, including the root module's ~> 4.0.. Version constraints from all modules are combined, and Terraform chooses the newest provider version that meets every constraint. Since the child module has no constraint, the root module's ~> 4.0 constraint is the only one, so Terraform picks the latest 4.x release. The lock file then records that selection for reproducibility.

Answer

Terraform uses the version from the child module's lock file if present, otherwise it uses the root module's constraint.

Answer

Terraform selects the latest AWS provider version that satisfies the child module's unconstrained requirement, ignoring the root module's constraint.

Answer

Terraform fails because the child module does not specify a version constraint.

Question 3

A platform team maintains a shared child module that creates AWS resources in three different regions. The root module calls this child module three times, once per region. The child module currently declares only a default AWS provider configuration. What is the correct way to make each module instance use a distinct region without modifying the child module's resource blocks?

Accepted Answer

Declare multiple aliased AWS provider configurations in the root module and pass the appropriate `providers` map to each `module` block.. Passing aliased provider configurations into child modules through the `providers` meta-argument is the supported pattern for multi-region module reuse. The root module declares one AWS provider configuration per region with distinct aliases, then each `module` block maps the child's default AWS provider to the matching alias. The child module's resources automatically use the injected provider, so no resource-level changes are needed.

Answer

Duplicate the child module source into three copies, each with a hardcoded region in its `provider` block.

Answer

Add a `region` argument to each `module` block in the root module and reference `var.region` inside the child module.

Answer

Set the `AWS_REGION` environment variable to a different value before each `terraform apply` and rely on the child module to pick it up.

Question 4

A root module configures the AWS provider with `region = "eu-central-1"` and declares an aliased configuration `aws.dr` pointing at `region = "eu-west-1"`. The team wants a single `aws_route53_record` resource to be created in the DR region while all other AWS resources stay in eu-central-1. Which two statements correctly describe how provider selection works for this resource? (Choose two.)

Accepted Answer

The resource must include the meta-argument `provider = aws.dr` to use the DR region configuration.. Provider selection within a module is explicit for aliased configurations and implicit for the default. The route53 record must carry provider = aws.dr to land in eu-west-1, and if that meta-argument is omitted it falls back to the default aws configuration in eu-central-1. Multiple configurations of a provider type are allowed, with only one permitted to be unaliased.

Answer

The aliased aws.dr configuration applies to the route53 record only if the resource is moved into a child module that receives it through the providers argument.

Answer

A single module may define only one provider configuration per provider type, so the aliased aws.dr block is invalid.

Answer

Declaring a second aws provider block with a different region automatically makes the resource use whichever region is defined last in the file.

Question 5

A platform team publishes an internal module that wraps the AWS provider. They want to ensure that consumers cannot use a provider version newer than 5.x but can use any 5.x release. The module's `required_providers` currently specifies `version = "~> 5.0"`. A consumer's root module specifies `version = "~> 4.0"` for the same provider. What happens when the consumer runs `terraform init`?

Accepted Answer

Terraform reports an error because no single provider version satisfies both constraints.. Provider version constraints are combined across the entire configuration. When a child module and the root module specify non-overlapping constraints such as `~> 5.0` and `~> 4.0`, Terraform cannot select any version. `terraform init` fails with a clear error, forcing the team to reconcile the constraints. This ensures a consistent provider version across all modules.

Answer

Terraform upgrades the provider to a version that satisfies both constraints automatically.

Answer

Terraform ignores the module's constraint and uses the root module's 4.x constraint.

Answer

Terraform selects version 4.x for the module and 5.x for the root, allowing both to coexist.

Question 6

A CI pipeline runs Terraform against an AWS account and must assume a dedicated deployment role rather than use long-lived access keys. The role ARN differs between the staging and production pipelines. The team wants a single configuration that works in both environments without embedding credentials. Which approach correctly configures the AWS provider to assume the pipeline-specific role?

Accepted Answer

Define an input variable for the role ARN and reference it in the `assume_role` block of the AWS provider configuration.. The AWS provider supports an `assume_role` block whose `role_arn` and related arguments can reference input variables. By parameterizing the role ARN, a single configuration serves both pipelines: each pipeline passes its own value through a `-var` flag, a `.tfvars` file, or workspace configuration. No credentials are embedded, and the provider assumes the correct role at plan and apply time.

Answer

Hardcode the production role ARN in the `provider "aws"` block and override it with a `-var` flag during staging runs.

Answer

Create two aliased AWS provider blocks, one per environment, and select the correct one using a `count` expression on the provider block.

Answer

Set the `AWS_ROLE_ARN` environment variable and rely on the AWS provider to assume that role automatically without any `assume_role` block.

Question 7

A consultant joins a project and runs `terraform init` on a configuration that references `hashicorp/aws` version `~> 5.0`. The init succeeds, but a teammate later reports that their init fails with a checksum mismatch for the same provider version. The consultant's platform is `linux_amd64` and the teammate's is `darwin_arm64`. What is the most likely explanation and the correct remediation?

Accepted Answer

The teammate's `.terraform.lock.hcl` lacks an entry for `darwin_arm64`, so `terraform providers lock -platform=darwin_arm64` must be run and the updated lock file committed.. The dependency lock file stores provider checksums for the platforms on which it was generated. A lock file created only on `linux_amd64` has no hashes for `darwin_arm64`, so init on Apple Silicon cannot verify the download. Running `terraform providers lock` with both `-platform` values records hashes for each platform, and committing the updated file resolves the mismatch for the whole team.

Answer

The teammate must delete `.terraform.lock.hcl` and re-run `terraform init` so Terraform regenerates it locally.

Answer

The AWS provider version `~> 5.0` is incompatible with `darwin_arm64`, so the teammate must downgrade to version 4.x.

Answer

The teammate should set `TF_REGISTRY_CLIENT_TIMEOUT` to a larger value so the download of the `darwin_arm64` package completes.

Question 8

A consultant is authoring a module that must support both AWS commercial and AWS China regions. The module needs to create resources in whichever partition the caller selects, and the caller may also want to create resources in a second region within the same partition. The module must not hardcode any region. Which approach best satisfies this?

Accepted Answer

Declare two aliased AWS provider configurations in the root with distinct aliases, and have the module declare `configuration_aliases` for both, then reference each alias in the resources that must land in each region.. Using `configuration_aliases` in the child module with two aliased provider configurations supplied by the root gives the module the flexibility to place resources in different regions within whichever partition the caller chooses. This keeps provider configuration centralized and avoids hardcoding regions, which is the cleanest way to support both commercial and China partitions.

Answer

Pass a `region` variable into the module and use the `aws` provider's `default_tags` to set the partition implicitly.

Answer

Create the AWS provider configuration inside the module itself with two `provider "aws"` blocks using different aliases and region variables.

Answer

Use a single default AWS provider configuration in the root and set the `region` argument dynamically inside the module using a variable.

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 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 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 components are part of the 'Workspace' object in HCP Terraform?

Accepted Answer

State file. In HCP Terraform, a Workspace is the fundamental unit that groups a Terraform configuration with its associated data, and the state file (A) is a core component because it stores the mapping between resources and real infrastructure, enabling plan and apply operations. Run history (D) is also part of the Workspace object, as each workspace records the sequence of runs (plan, apply, destroy) along with their status, logs, and outcomes. Variables (E) are included because workspaces hold both Terraform variables and environment variables that parameterize runs, with values that can be set per workspace and marked sensitive. Billing invoice history (B) is not a workspace component; it belongs to the organization or account billing level. Global provider plugins (C) are not part of a workspace either, since provider plugins are installed and cached at the run environment or organization level, not stored within the workspace object itself.

Answer

Billing invoice history

Answer

Global provider plugins

Question 13

Which THREE of the following are valid ways to pass data to a module dynamically?

Accepted Answer

Using variables. Option A (Using variables) is correct because Terraform modules accept input values through declared input variables, and callers pass data dynamically via the module block's arguments (e.g., variable_name = value), which is the standard mechanism for parameterizing a module. Option D (Using for_each on a module block) is correct because Terraform supports for_each on module blocks, allowing multiple module instances to be created dynamically from a map or set, with each instance receiving distinct input values derived from the iteration. Option E (Using complex object types) is correct because input variables can be typed as complex types such as object({...}), map, list, or tuple, enabling structured, dynamic data to be passed into a module rather than only simple primitives. Option B (Directly editing the state) is not a valid way to pass data to a module, since the state file is a record of managed infrastructure and manually editing it is unsupported and does not feed inputs into module configuration. Option C (Using a dynamic block for module calling) is not valid because dynamic blocks only generate repeated nested configuration blocks within a resource, data, or module argument, not the module call itself, so they cannot be used to invoke modules dynamically.

Answer

Directly editing the state

Answer

Using a dynamic block for module calling

Question 14

Which of the following are valid ways to specify provider versions? (Select TWO)

Accepted Answer

In the required_providers block.. Option A is correct because Terraform's modern and recommended method for pinning provider versions is the required_providers block inside a terraform block, where each provider is listed with a source address and a version constraint (e.g., version = "~> 5.0"). Option D is correct because the legacy syntax allowed specifying a version argument directly inside a provider configuration block (e.g., provider "aws" { version = "~> 5.0" }), which still works but is deprecated in favor of required_providers. Option B is incorrect because resource blocks configure resource arguments and do not accept a provider version constraint. Option C is incorrect because backend blocks configure state storage and locking, not provider versions. Option E is incorrect because output blocks only export values from the configuration and have no version attribute.

Answer

In the resource block.

Answer

In the backend block.

Answer

In the output block.

Question 15

Which THREE of the following are true regarding 'create_before_destroy'?

Accepted Answer

It is intended to minimize downtime during updates.. Option A is correct because create_before_destroy changes Terraform's default destroy-then-create ordering so the replacement resource is provisioned first, keeping the old resource serving until the new one is ready and thereby minimizing downtime during updates. Option B is correct because create_before_destroy is a meta-argument configured inside a resource's lifecycle block, for example lifecycle { create_before_destroy = true }. Option C is correct because running both the old and new resource simultaneously requires enough provider quota/capacity to temporarily hold two instances of that resource. Option D is not correct because create_before_destroy does not automatically resolve name collisions; unique-name constraints (such as fixed Name tags or DNS names) can still cause the create step to fail and often require name generators or other workarounds. Option E is not correct because create_before_destroy is a core Terraform lifecycle meta-argument available across providers, not an AWS-only feature.

Answer

It automatically resolves all name collision issues.

Answer

It is only available for AWS providers.