AWS provider Provider Management Practice Test 2 — 15 Questions

Question 1

You are preparing a Terraform configuration for a multi-account AWS environment. The root module must pass two different AWS provider configurations to a child module: one for the primary account and one for a logging account. The child module will create resources in both accounts. Which two actions are required to accomplish this? (Choose two.)

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

Accepted Answer

Define two provider configurations in the root module using `alias` arguments.. Passing multiple configurations of the same provider to a child module requires the root module to define aliased provider configurations and the child module to declare those aliases in its `required_providers` block using `configuration_aliases`. The root then maps them in the `module` block's `providers` argument. This pattern is common in multi-account AWS setups where a module manages resources across accounts.

Answer

Create a separate child module instance for each account and pass a single provider configuration to each.

Answer

Add a `provider` block inside the child module for each account and set the `region` argument directly.

Answer

Use the `providers` argument in the child module's `module` block to map the aliases.

Question 2

A team is preparing a root module that must deploy resources with two different AWS provider configurations: one using a cross-account assumed role for production and one using the default credentials for shared services. They also want a child module to be able to receive the production configuration. Which two configurations are required to achieve this? (Choose two.)

Accepted Answer

Use the `providers` argument on the child module block to map the child's aws requirement to the aliased production provider configuration.. Within a root module, multiple configurations of one provider are separated by `alias`, and a child module receives a specific configuration only through the `providers` argument on its module block. Together these two elements let the production resources and the child module use the cross-account role while shared services continue using the default credentials.

Answer

Reference the production provider configuration inside resource blocks using the `provider = aws.production` meta-argument.

Answer

Add an `alias` argument to the child module's own provider block so it can request the production configuration by name.

Answer

Set `configuration_aliases` in the child module's terraform block to declare which aliased configurations it expects to receive.

Question 3

Your organization uses a private Terraform registry to distribute an internal AWS provider fork. A developer runs `terraform init` and receives an error that the provider cannot be found. The configuration specifies `source = "registry.internal.example.com/org/aws"` and `version = "5.1.0"`. The provider is published and the developer is authenticated. What is the most likely cause?

Accepted Answer

The provider's required host configuration is missing from the CLI configuration file, so Terraform does not know to authenticate or use the private registry.. Terraform determines which registry to use for a provider based on the source address and the CLI configuration. For a private registry, the CLI configuration must include a `provider_installation` block with a `host` entry for that registry. Without this, Terraform attempts to resolve the provider from the public registry and fails, even if the user has authenticated to the private registry through other means.

Answer

Private registry providers must be installed manually with `terraform providers mirror` before `init` can use them.

Answer

The version constraint `5.1.0` is invalid because provider versions must use a pessimistic constraint operator.

Answer

The provider source address must be a fully qualified hostname with a path, and the registry requires a namespace and type separated by a slash.

Question 4

A security team requires that all Terraform runs use temporary AWS credentials obtained from `aws sts assume-role` rather than static access keys. The team uses the AWS provider and wants Terraform to assume a role automatically during each run. Which provider configuration achieves this while still allowing the caller to override the source profile?

Accepted Answer

Configure the AWS provider with `assume_role` blocks that specify `role_arn` and optionally `source_profile`, and allow the `profile` argument to be set from a variable.. The AWS provider's `assume_role` configuration performs the STS role assumption automatically on each run, producing temporary credentials. By exposing the `profile` argument through a variable, callers can choose the source profile without editing the provider block, which satisfies both the security mandate and the override requirement.

Answer

Use the `shared_credentials_file` argument to point at a file containing the assumed-role credentials, and set `skip_credentials_validation` to true.

Answer

Add an `assume_role_with_web_identity` block to the provider and rely on the default credential chain to populate the token.

Answer

Set the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables in the CI system and reference them in the provider block with explicit arguments.

Question 5

A platform team maintains a root module that declares `required_providers` with `aws = { source = "hashicorp/aws", version = "~> 5.40" }` and configures two aliased AWS providers, `aws` and `aws.replica`, plus `configuration_aliases = [aws.replica]`. They plan to call a child module that must create resources in the replica region. Which two provider-related configurations are required for the child module to accept the aliased provider? (Choose two.)

Accepted Answer

The root module must pass the aliased provider explicitly in the module call using `providers = { aws.replica = aws.replica }`.. To pass an aliased provider configuration into a child module, the child module must declare the provider in required_providers with configuration_aliases listing the alias, and the root module must explicitly pass the provider using the providers meta-argument. These two steps ensure the child module can reference the aliased provider and receive the correct configuration.

Answer

The child module must set `version = "~> 5.40"` in its `required_providers` block to match the root module's AWS provider constraint.

Answer

The child module must define its own `provider "aws" { alias = "replica" }` block with region set to the replica region.

Answer

The root module must include a `terraform { required_providers { aws = { configuration_aliases = [aws.replica] } } }` block.

Question 6

A team is using a child module that creates AWS resources. The root module configures the AWS provider with a specific region and profile. The child module does not define any provider blocks. During `terraform plan`, the resources in the child module are planned in a different region than expected. What is the most likely cause?

Accepted Answer

The child module has a variable for the region that is set to a different value than the root module's provider region.. The most likely cause is that the child module uses a variable to specify the region for its resources, and that variable is set to a different value than the root module's provider region. This can happen when resources have an explicit region argument, overriding the provider's region. The other options are less likely or incorrect.

Answer

The child module has a `provider "aws"` block that overrides the root module's provider configuration.

Answer

The AWS provider version in the child module is different from the root module, causing region configuration to be ignored.

Answer

The root module did not pass the provider configuration to the child module using the `providers` meta-argument.

Question 7

What is the purpose of the 'terraform providers lock' command?

Accepted Answer

To secure the provider versions and checksums.. The 'terraform providers lock' command is used to update the dependency lock file (.terraform.lock.hcl) with the checksums of provider packages. It ensures that the provider versions and their checksums are recorded, which helps in verifying the integrity of providers during subsequent init operations. This is particularly useful in air-gapped environments or when you want to ensure consistent provider versions across teams.

Answer

To encrypt the state file.

Answer

To prevent others from running init.

Answer

To download all providers.

Question 8

You are creating a custom provider. What is the standard language used to write Terraform providers?

Accepted Answer

Go. Terraform providers are written in Go, using the Terraform Plugin SDK (or the newer Plugin Framework). Go is the standard because Terraform itself is written in Go, and the plugin architecture relies on Go's support for building shared libraries and gRPC-based plugins. Providers implement CRUD operations for resources and data sources by conforming to the Terraform plugin protocol, which is defined and maintained in Go.

Answer

Python

Answer

Ruby

Answer

HCL

Question 9

You need to manage resources in two different AWS regions using the same provider configuration. How do you achieve this?

Accepted Answer

Use an alias in the provider block and reference it in the resource using the provider meta-argument.. In Terraform, a single provider configuration can only target one region. To manage resources across multiple regions with the same provider type (e.g., AWS), you must define multiple provider blocks, each with a unique alias. The default provider block (without alias) handles the primary region, while additional blocks with aliases (e.g., `alias = "west"`) specify other regions. Resources then use the `provider` meta-argument to select the appropriate aliased provider, e.g., `provider = aws.west`. This allows a single Terraform configuration to manage resources in multiple regions.

Answer

Define the region twice in a single provider block.

Answer

Define two separate aws providers in the same file without aliases.

Answer

Create two separate Terraform projects.

Question 10

If you want to use a provider that is not published in the Terraform Registry, how do you install it?

Accepted Answer

Use a filesystem mirror in the .terraformrc file.. Providers not published in the Terraform Registry are installed by configuring a filesystem mirror in the CLI configuration file (.terraformrc or terraform.rc), which tells Terraform where to find the provider plugin binaries locally. The provider_installation block with a filesystem_mirror directive points Terraform at a directory containing the provider packages, bypassing the default registry lookup. This is the standard approach for air-gapped environments or internal/private providers.

Answer

You cannot use private providers.

Answer

Rename the file to provider.tf.

Answer

Copy it to the root of the project.

Question 11

A team wants to ensure their Terraform configuration uses a specific major version of the AWS provider to prevent breaking changes. Which block should they use?

Accepted Answer

terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 4.0" } } }. The `terraform { required_providers { ... } }` block is the canonical location for declaring a provider's source and version constraint in modern Terraform (0.13+). The `version = "~> 4.0"` pessimistic constraint operator allows any 4.x release but blocks 5.0 and above, which is exactly what's needed to prevent breaking major-version upgrades. This block is also what `terraform init` reads when resolving and locking provider versions in `.terraform.lock.hcl`.

Answer

provider "aws" { version = "~> 4.0" }

Answer

terraform { version = "~> 4.0" }

Answer

provider_version = "4.0"

Question 12

Where are providers physically stored by default when running 'terraform init'?

Accepted Answer

.terraform/providers/. Terraform downloads providers into the .terraform/providers directory within your project working directory.

Answer

The root module directory

Answer

~/.terraformrc

Answer

/usr/local/bin/terraform

Question 13

Which meta-argument is used to explicitly associate a resource with a non-default provider instance?

Accepted Answer

provider. The `provider` meta-argument is used within a resource block to explicitly specify which provider configuration to use, especially when multiple provider configurations exist (e.g., different regions or accounts). For example, `provider = aws.west` tells Terraform to use the `aws` provider instance with the alias `west`. This overrides the default provider configuration for that resource.

Answer

configuration

Answer

alias

Answer

instance

Question 14

A provider binary is not found in the local Terraform registry cache. What command should you run to force Terraform to download the provider again?

Accepted Answer

terraform init -upgrade. The 'terraform init -upgrade' command forces Terraform to re-evaluate and download the latest versions of providers that meet the version constraints, even if a provider is already present in the local cache. This is the correct way to update providers or re-download a missing provider binary. It also updates the dependency lock file.

Answer

terraform plan -refresh-only

Answer

terraform providers install

Answer

terraform refresh

Question 15

Which file is automatically generated to lock provider versions and their checksums?

Accepted Answer

.terraform.lock.hcl. The .terraform.lock.hcl file is automatically generated by Terraform to lock provider versions and record their checksums. It ensures consistent provider versions across runs and verifies integrity.

Answer

terraform.tfstate

Answer

terraform.tfvars

Answer

provider.tf