AWS provider Provider Management Practice Test 1 — 15 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.