AWS provider Provider Management — 40 Questions

Question 1

How does Terraform resolve the version of a provider if the version is defined in both 'terraform' block and the 'provider' block?

Accepted Answer

The terraform block takes precedence.. When a version constraint appears in both the `terraform { required_providers }` block and a legacy `provider` block, Terraform treats the `required_providers` declaration as authoritative. The `provider` block's `version` argument was deprecated in Terraform 0.13 and is ignored (or produces a warning) in favor of the centralized `required_providers` constraint. This centralization ensures version resolution happens once during `terraform init`.

Answer

The highest version wins.

Answer

The provider block takes precedence.

Answer

It causes a syntax error.

Question 2

Which attributes can be configured within a provider block? (Select THREE)

Accepted Answer

shared_credentials_file. Region, profile, and credentials (like shared_credentials_file) are all valid provider arguments.

Answer

source

Answer

version

Question 3

Which of the following are valid provider version constraint operators? (Select TWO)

Accepted Answer

=. Option C (=) is a valid Terraform provider version constraint operator, used to pin a provider to an exact version such as = 1.2.3 (or simply 1.2.3), ensuring only that precise version is selected. Option D (~>) is also valid: the pessimistic constraint operator allows only the rightmost version component to increment, so ~> 1.2.0 permits 1.2.x but not 1.3.0, while ~> 1.2 permits 1.x but not 2.0. The other options are not Terraform version constraint operators: || (A) is not supported for combining constraints (Terraform uses commas for AND and separate constraints for OR), && (B) is not a Terraform constraint operator, and !! (E) has no meaning in provider version constraints.

Answer

||

Answer

&&

Answer

!!

Question 4

Which of these are required components when defining a provider in 'required_providers'? (Select TWO)

Accepted Answer

version. In Terraform's required_providers block, each provider entry must specify a source (option C), which is the fully qualified address of the provider such as hashicorp/aws or registry.terraform.io/hashicorp/aws, identifying where the provider plugin is downloaded from. It must also specify a version (option B), a version constraint string like "~> 5.0" that tells Terraform which provider releases are acceptable. Options A (profile) and D (region) are provider-specific configuration arguments set inside the provider block, not part of required_providers, and option E (alias) is an optional meta-argument used to declare multiple configurations of the same provider, not a required component of required_providers.

Answer

profile

Answer

region

Answer

alias

Question 5

What are requirements for a custom provider to be recognized by Terraform? (Select THREE)

Accepted Answer

Must be a compiled binary.. Option C is correct because Terraform providers are distributed as compiled executables that Terraform launches as separate plugin processes over gRPC, so a custom provider must be built into a binary for the target OS/architecture. Option D is correct because Terraform discovers provider plugins using a filesystem layout such as registry.terraform.io/hashicorp/aws/5.0.0/linux_amd64/terraform-provider-aws_v5.0.0, so the directory naming convention (hostname/namespace/type/version/os_arch) is required for recognition. Option E is correct because the Terraform Plugin SDK and Plugin Framework are Go libraries, and providers are implemented in Go to satisfy the plugin protocol and produce the expected binary. Option A is not required because Terraform can use locally installed or filesystem-mirrored providers without registry upload, and Option B is not required because HashiCorp signing is only needed for the public registry, not for Terraform to recognize a custom provider.

Answer

Must be uploaded to the registry.

Answer

Must be signed by HashiCorp.

Question 6

A platform team maintains a shared Terraform module that is used by multiple application teams. The module currently configures the AWS provider internally with a hardcoded region. The platform team wants consuming root modules to be able to supply their own provider configuration, including region and assume_role settings, without editing the shared module. What should the platform team change in the shared module?

Accepted Answer

Remove the provider block from the module and declare a configuration_aliases entry for aws in the module's required_providers block.. Child modules inherit provider configurations from the root module by default, and configuration_aliases lets a module declare that it expects an aliased provider from the caller. By removing the internal provider block and declaring configuration_aliases, the shared module becomes provider-agnostic and consuming teams can inject their own region and assume_role settings without modifying module source.

Answer

Convert the module into a root module and publish it through a private registry so each team can fork it.

Answer

Add a variable named provider and assign it the aws provider configuration inside the module's terraform block.

Answer

Add a provider "aws" block with an alias and reference the alias from every resource in the module.

Question 7

A platform team maintains a shared child module that creates AWS resources in us-east-1. In the root module, they configure two aliased AWS providers: one default for us-east-1 and one aliased as 'west' for us-west-2. They want the child module to use the 'west' provider instance for all AWS resources it creates. Which configuration should they use?

Accepted Answer

In the module call in the root module, add providers = { aws = aws.west }.. Provider instances are passed into child modules through the providers meta-argument on the module block. By mapping the child module's default aws provider name to the root module's aws.west alias, every aws resource inside the child module is created with the us-west-2 configuration, including its credentials and region.

Answer

In the root module's provider block, add a default_tags argument with a tag indicating us-west-2.

Answer

In the child module's provider block, set alias = "west" and region = "us-west-2".

Answer

In the child module's required_providers block, set configuration_aliases = [aws.west].

Question 8

Your organization mirrors all Terraform providers into an internal registry at `registry.example.com`. A root module declares `required_providers { aws = { source = "registry.example.com/hashicorp/aws", version = "5.31.0" } }`. A developer runs `terraform init` from a laptop that has no direct internet access and receives an error stating the provider package could not be retrieved. The internal registry is reachable and hosts the package. Which CLI configuration is required so Terraform contacts the internal registry instead of the public Terraform Registry?

Accepted Answer

A provider_installation block in the CLI configuration file that sets the internal registry as the installation method for the hashicorp/aws provider.. Terraform decides where to obtain provider packages using provider installation methods configured in the CLI configuration file. A provider_installation block can declare a network mirror or restrict installation to specific hosts, causing Terraform to fetch the hashicorp/aws package from the internal registry. Source addresses in required_providers identify the provider, but they do not by themselves select the download location.

Answer

Setting the TF_REGISTRY_CLIENT_TIMEOUT environment variable to a higher value before running terraform init.

Answer

A credentials block in the CLI configuration file containing a token for registry.example.com.

Answer

A terraform block in the root module with a required_version constraint matching the internal registry's Terraform version.

Question 9

A consultant is onboarding a client whose Terraform configuration was written years ago. The root module's terraform block contains only 'required_version' and no required_providers entry for AWS. The client wants to ensure future runs use the modern registry addressing for the AWS provider. What should the consultant do?

Accepted Answer

Add a required_providers block declaring aws with source = "hashicorp/aws" and an appropriate version constraint. Modern Terraform expects providers to be declared in a required_providers block with an explicit source address and version constraint. Adding this to the terraform block replaces legacy implicit provider resolution, ensures the correct registry namespace is used, and gives the client control over provider versions going forward.

Answer

Set the TF_PROVIDER_SOURCE environment variable to hashicorp/aws before each Terraform run

Answer

Add a provider "aws" block with a version argument set to "~> 5.0"

Answer

Run 'terraform providers mirror' to rewrite the configuration with modern provider addresses

Question 10

A security team mandates that all Terraform runs in an AWS account use short-lived credentials obtained from a corporate identity provider. An engineer configures the AWS provider with assume_role using a role ARN and an external_id, but Terraform still reads long-lived access keys from environment variables in CI. What should the engineer do to ensure the provider uses the assume_role configuration instead of the environment credentials?

Accepted Answer

Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables so the provider falls through to the assume_role configuration.. The AWS provider resolves credentials through a precedence chain where static environment access keys outrank assume_role configuration. As long as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY exist in the CI environment, the provider uses them. Removing those variables lets the provider reach the assume_role block and obtain short-lived credentials from the corporate identity provider.

Answer

Set the AWS_SHARED_CREDENTIALS_FILE variable to an empty file so the provider cannot read static keys.

Answer

Add skip_credentials_validation = true to the provider block so it ignores environment credentials.

Answer

Set the AWS_PROFILE environment variable to the role name so the provider prefers the assume_role configuration.

Question 11

Your root module declares the AWS provider with `configuration_aliases = [aws.replica]`, and a child module is expected to create resources in a second region. The child module already contains a `required_providers` block for `hashicorp/aws` but no `provider` block. When you run `terraform validate`, it fails with an error about a missing provider configuration. What should you do in the child module to resolve this?

Accepted Answer

Declare `configuration_aliases = [aws.replica]` inside the child module's `required_providers` block.. A child module that expects an aliased provider configuration must declare that expectation in its own `required_providers` block using `configuration_aliases`. This allows the parent module to pass the specific configuration with the `providers` argument in the `module` block. Without this declaration, Terraform cannot associate the aliased configuration with the module's resources, producing a validation error about a missing provider configuration.

Answer

Add a `provider "aws"` block with `alias = "replica"` and a `region` argument inside the child module.

Answer

Replace the child module's `required_providers` block with a `terraform` block containing `required_version` and no provider requirements.

Answer

Add a `providers` meta-argument in the child module's `module` call mapping `aws.replica = aws.replica`.

Question 12

An organization requires that all Terraform runs in its CI system use AWS credentials obtained from short-lived OIDC federation rather than long-lived access keys, and that no credentials ever be written to configuration files or state. The CI runners already expose a web identity token through environment variables. Which provider configuration approach meets these constraints?

Accepted Answer

Configure the aws provider with `assume_role_with_web_identity` settings that read the token from the standard environment variables, leaving static keys unset.. The AWS provider's assume-role-with-web-identity support exchanges an OIDC token for temporary STS credentials when the token file and role ARN are supplied, typically via the standard environment variables that CI runners already set. Because the resulting credentials are short-lived and derived at runtime, no static keys need to be stored in configuration, variables, or state.

Answer

Rely on the default credential chain to pick up the OIDC token automatically without any assume-role configuration.

Answer

Place `access_key` and `secret_key` arguments in the provider block and populate them from CI secret variables at plan time.

Answer

Store the federated credentials in Terraform Cloud workspace variables marked sensitive and let the provider read them implicitly.

Question 13

A platform team maintains a reusable module that can target either a commercial AWS region or an AWS GovCloud region. The root configuration declares two aliased AWS provider configurations named `aws.commercial` and `aws.govcloud`. The module must accept whichever provider configuration the caller chooses without hardcoding either region. Which configuration in the child module correctly implements this requirement?

Accepted Answer

Declare a `configuration_aliases` entry inside the module's `terraform` block listing `aws.commercial` and `aws.govcloud`, and reference the providers in resources as `aws.commercial` or `aws.govcloud`.. The correct approach declares the aliased provider configurations the module expects through `configuration_aliases` in the module's `terraform` block, then references those aliases in the module's resources. The parent module passes the actual provider configurations via the `providers` meta-argument in the module call. This pattern avoids hardcoding a region and keeps provider configuration ownership in the root module.

Answer

Add a `provider "aws"` block inside the child module with a `region` variable, and let the module create its own provider configuration independently of the root.

Answer

Set the `region` argument inside the module's `required_providers` block for the AWS provider using a variable value.

Answer

Use the `providers` meta-argument in the module call to map `aws` to `aws.commercial` and rely on the module's implicit default provider for GovCloud.

Question 14

An engineer is writing a root module that must deploy resources into two AWS regions using the same AWS provider version. The module already contains a default provider "aws" block for us-east-1. The engineer adds a second provider "aws" block with alias = "west" for us-west-2 and references aws.west in a resource. During plan, Terraform reports that no configuration exists for the aliased provider in the module. What is the most likely cause?

Accepted Answer

The resource references aws.west, but the aliased provider block is missing the required region argument or is not actually present in the configuration being planned.. Terraform requires every referenced provider alias to have a matching provider block in the active configuration. If the resource uses aws.west but the aliased provider block is absent, incomplete, or lacks its region argument, plan fails with a missing configuration error. Verifying that the provider "aws" block with alias = "west" exists and is complete resolves the issue.

Answer

The aliased provider configuration must also be listed in the root module's required_providers block with a matching configuration_aliases entry.

Answer

The aliased provider block must be declared inside a child module, not the root module.

Answer

The AWS provider does not support multiple aliases within a single root module and requires separate workspaces per region.

Question 15

An operations engineer runs `terraform init` in a CI pipeline for a configuration that uses the AWS provider. The pipeline has no outbound internet access to the public Terraform Registry, but a private registry mirror is available at `registry.example.com`. The engineer needs Terraform to fetch the provider from the mirror while still verifying the official signing key. Which combination of settings achieves this?

Accepted Answer

Add a `provider_installation` block in the CLI configuration file with a `network_mirror` source pointing at `https://registry.example.com`, and keep the default `partner` and `community` installation methods for signature verification.. Configuring a `network_mirror` source inside the `provider_installation` block of the CLI configuration file directs Terraform to retrieve providers from the private registry mirror, while the default installation methods continue to enforce official signature verification. This keeps the workflow offline-compatible without weakening integrity guarantees, which is exactly what the CI pipeline needs.

Answer

Set the `TF_REGISTRY_CLIENT_TIMEOUT` environment variable to a high value and run `terraform providers mirror` against the private registry.

Answer

Place the provider binary manually in `.terraform/providers` and run `terraform init -get=false` to skip download.

Answer

Create a `required_providers` entry with a `source` of `registry.example.com/hashicorp/aws` and disable checksum verification in the lock file.

Question 16

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.)

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 17

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 18

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 19

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 20

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.