AWS provider Provider Management Practice Test 4 — 15 Questions

Question 1

Which of the following are true regarding the .terraform.lock.hcl file? (Select TWO)

Accepted Answer

It is automatically generated by terraform init.. Option A is correct because the .terraform.lock.hcl dependency lock file is automatically created and updated by the `terraform init` command when it installs providers, recording the exact provider versions and checksums selected. Option E is correct because HashiCorp recommends committing the .terraform.lock.hcl file to version control so that all team members and CI/CD pipelines use the same provider versions and verified checksums, ensuring reproducible runs. Option B is incorrect because Terraform state is stored in the state file (terraform.tfstate or a configured remote backend), not in the lock file. Option C is incorrect because the lock file is normally generated and updated automatically by Terraform commands such as `terraform init` and `terraform providers lock`, though it can be edited manually if needed. Option D is incorrect because the lock file stores provider version constraints and cryptographic hashes, not secret credentials, which should never be placed in it.

Answer

It is used to store the state file.

Answer

It can only be edited manually.

Answer

It stores secret credentials.

Question 2

When debugging provider issues, which commands are most useful? (Select THREE)

Accepted Answer

terraform providers. Option A, `terraform providers`, is correct because it prints the provider requirements and the provider configuration tree for the current working directory, showing which providers each module uses and where they come from, which is essential when diagnosing provider source, version, or inheritance issues. Option B, `TF_LOG=DEBUG`, is correct because setting this environment variable enables detailed Terraform debug logging (including provider plugin communication and API calls), which is the primary way to trace provider errors and failures. Option E, `terraform init`, is correct because it initializes the working directory by downloading and installing the required provider plugins and modules, so it is the command used to resolve or reveal provider installation and version-constraint problems. Option C, `terraform fmt`, is not correct because it only rewrites configuration files to canonical formatting and does not help diagnose provider behavior. Option D, `terraform taint`, is not correct because it merely marks a resource for destruction and recreation on the next apply, which is unrelated to debugging provider issues.

Answer

terraform fmt

Answer

terraform taint

Question 3

Which are characteristics of the Terraform Plugin SDK? (Select TWO)

Accepted Answer

It provides a way to define schema for resources.. Option D is correct because the Terraform Plugin SDK exposes helper packages such as schema.Resource and schema.Schema that let provider developers declaratively define the schema (attributes, types, required/optional/computed flags) for resources and data sources. Option E is correct because the SDK supplies the CRUD lifecycle scaffolding—Create, Read, Update, Delete (and often Import) functions—that Terraform invokes through the provider's gRPC interface to reconcile real infrastructure with configuration. Option A is wrong because the SDK is a library for building providers; the Terraform CLI is a separate binary that talks to providers over the plugin protocol. Option B is wrong because state locking is handled by the Terraform core/backend (for example, DynamoDB for S3, or the local backend), not by the Plugin SDK. Option C is wrong because HCL is parsed and evaluated by Terraform core's HCL library, not compiled to Go code by the Plugin SDK.

Answer

It replaces the Terraform CLI.

Answer

It manages the Terraform state lock.

Answer

It compiles HCL to Go code.

Question 4

What are the ways to configure provider credentials? (Select THREE)

Accepted Answer

Shared credentials file (~/.aws/credentials).. Option A is correct because the AWS provider (and Terraform's provider credential chain) reads static access keys from the shared credentials file at ~/.aws/credentials, typically under a named profile such as [default]. Option B is correct because credentials can be supplied inline within the provider block using arguments like access_key and secret_key, which is valid though less secure than external sources. Option C is correct because the provider credential chain also resolves credentials from environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN. Option D is not correct because .terraform.lock.hcl only records provider version selections and cryptographic hashes for dependency locking, not credentials. Option E is not correct because terraform output only displays values from state (such as outputs) and has no role in configuring provider authentication.

Answer

In the .terraform.lock.hcl file.

Answer

Via the terraform output command.

Question 5

An operations engineer runs 'terraform init' in a directory where the configuration requires the AWS provider from the public registry. The machine has no direct internet access but can reach an internal Terraform registry mirror. Which action must be taken so that init succeeds using the mirror?

Accepted Answer

Configure a provider_installation block in the CLI configuration file (~/.terraformrc or terraform.rc) with a network_mirror or filesystem_mirror directive. Terraform reads provider installation settings from the CLI configuration file, not from the working directory configuration. A provider_installation block with network_mirror or filesystem_mirror directs Terraform to fetch providers from an internal source, which is the correct solution when the public registry is unreachable but a mirror is available.

Answer

Add a source argument pointing to the mirror URL inside the terraform block of the root configuration

Answer

Run 'terraform providers lock' with the -platform flag to pre-populate the lock file from the mirror

Answer

Set the TF_REGISTRY_CLIENT_TIMEOUT environment variable to a longer value and re-run init

Question 6

A platform team maintains a shared Terraform child module that contains only a single `aws_s3_bucket` resource and no `provider` block. The module's `versions.tf` declares `required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } }`. A consumer root module configures the AWS provider with `region = "us-west-2"` and calls the child module without any `providers` argument. During `terraform plan`, which AWS region will be used to evaluate the bucket resource inside the child module?

Accepted Answer

The child module inherits the root module's default AWS provider configuration, so the bucket is planned in us-west-2.. An unaliased provider configuration in the root module is implicitly inherited by every child module that does not declare its own provider block. Since the child module only constrains source and version through required_providers, the root's region = "us-west-2" configuration applies when Terraform evaluates the bucket. No separate provider instance is created, and no environment fallback occurs.

Answer

Terraform fails the plan because a child module that declares required_providers must also declare its own provider block.

Answer

The provider is instantiated independently inside the child module and uses the AWS SDK default region from the execution environment.

Answer

The bucket is planned in the region declared inside the hashicorp/aws provider's own default configuration.

Question 7

A team's CI pipeline runs 'terraform init' on Linux amd64 runners, while developers run it on macOS arm64 laptops. After a developer commits .terraform.lock.hcl generated on their laptop, the CI pipeline fails with 'provider ... does not have a package available for your current platform'. What is the most appropriate fix?

Accepted Answer

Run 'terraform providers lock -platform=linux_amd64 -platform=darwin_arm64' and commit the updated lock file. The dependency lock file records checksums per platform. When it is generated on only one platform, other platforms cannot verify their provider packages and init fails. Regenerating the lock file with terraform providers lock using -platform for each target platform adds the required hashes while keeping the file committed for reproducibility.

Answer

Delete .terraform.lock.hcl from version control and let each environment regenerate it independently

Answer

Add a provider_installation block with direct = true so Terraform ignores the lock file on CI

Answer

Set the TF_PLUGIN_CACHE_DIR environment variable on the CI runner to reuse the developer's cached provider

Question 8

An operations engineer runs terraform init in a CI pipeline and notices the .terraform.lock.hcl file lists hashes for linux_amd64 only. A developer on macOS arm64 runs terraform init in the same repository and Terraform downloads a different provider build. The team wants the lock file to include hashes for both platforms so CI and developer workstations verify the same provider artifacts. Which command should the engineer run?

Accepted Answer

terraform providers lock -platform=linux_amd64 -platform=darwin_arm64. The dependency lock file records provider package hashes per platform. Running terraform providers lock with an explicit -platform flag for each target OS and architecture regenerates the lock file so it contains hashes for linux_amd64 and darwin_arm64. Subsequent init runs on either platform then verify the selected provider build against the recorded hashes without conflict.

Answer

terraform providers schema -json > lock.hcl

Answer

terraform providers mirror ./vendor -platform=linux_amd64 -platform=darwin_arm64

Answer

terraform init -upgrade -platform=linux_amd64,darwin_arm64

Question 9

A platform team maintains a shared Terraform module that must run in three AWS regions simultaneously within a single root configuration. The module itself declares only a generic `aws` provider requirement with no alias, and the team wants each module instance to use a different region without editing the module source. Which configuration approach satisfies this requirement?

Accepted Answer

Declare one aliased provider per region in the root module, then pass the matching provider configuration into each module block using the `providers` argument.. Provider configurations are defined once, typically in the root module, and child modules receive them through the `providers` argument on the module block. Declaring aliased aws providers for each region and mapping each module instance to the appropriate one lets a single root configuration deploy the same module across multiple regions while the module source stays generic.

Answer

Add an `alias` argument inside the shared module's terraform block so the module can select its own region at runtime.

Answer

Create three separate root modules, one per region, and invoke the shared module from each with a different workspace.

Answer

Set the `region` argument directly on the module block so Terraform forwards it to the module's implicit aws provider.

Question 10

During a CI pipeline run, `terraform init` fails with an error stating that the checksums recorded in `.terraform.lock.hcl` do not match any of the packages available from the configured provider mirror. The mirror is an internal registry serving only linux_amd64 builds, while the lock file was generated on a developer's darwin_arm64 laptop. Which action resolves the failure while keeping the lock file authoritative for CI?

Accepted Answer

Run `terraform providers lock` with `-platform=linux_amd64` against the internal mirror and commit the updated lock file.. The lock file pins provider packages by version and by platform-specific checksums. A lock file containing only darwin_arm64 hashes cannot validate a linux_amd64 package, regardless of mirror configuration. Re-running `terraform providers lock` with the target platform against the internal mirror records the linux_amd64 hashes, after which CI can verify and install the provider.

Answer

Add a `provider_installation` block that maps the AWS provider to the mirror and re-run `terraform init -upgrade` to refresh the hashes.

Answer

Delete `.terraform.lock.hcl` in the pipeline and let `terraform init` recreate it from the mirror on every run.

Answer

Set the environment variable `TF_CLI_CONFIG_FILE` to point at a CLI configuration that disables checksum verification during init.

Question 11

An operations engineer runs terraform init in a CI pipeline that has no outbound internet access but does have a local filesystem mirror of providers. The configuration uses the AWS provider and a custom provider named example. The engineer runs: terraform init -plugin-dir=/opt/terraform/plugins. What is the result?

Accepted Answer

Terraform uses the plugin directory as the only source for provider plugins and skips the usual provider installation steps.. The -plugin-dir option tells Terraform to use only the specified directory as the source of provider plugins. It does not perform normal provider installation or update the lock file. For air-gapped pipelines, all required provider binaries must be pre-populated in that directory, and the lock file should already contain matching checksums.

Answer

Terraform ignores the plugin directory because the AWS provider is a hashicorp provider and must be downloaded from the registry.

Answer

Terraform installs both providers from the plugin directory and writes a lock file entry for each.

Answer

Terraform installs the AWS provider from the plugin directory but still downloads the example provider because it is not a hashicorp provider.

Question 12

A team uses the AWS provider to manage resources in three accounts: development, staging, and production. The root module must create an `aws_iam_role` in the production account while all other resources remain in the default development account. The production account's provider configuration is already declared with `alias = "prod"`. Which change to the production `aws_iam_role` resource is required?

Accepted Answer

Add `provider = aws.prod` to the resource block so it uses the aliased production provider configuration.. The provider meta-argument on a resource names the exact provider configuration to use, expressed as the provider type and alias, such as aws.prod. Because the production configuration is already declared with alias = "prod", adding provider = aws.prod to the aws_iam_role routes only that resource to the production account while everything else continues using the default development configuration.

Answer

Declare a second aws provider block without an alias and place it after the default provider block.

Answer

Set `region = "<prod-region>"` directly on the aws_iam_role resource block.

Answer

Move the aws_iam_role resource into a child module and pass the production provider via the module's providers argument.

Question 13

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 14

Your team maintains a Terraform configuration that uses the AWS provider with an S3 backend. A security review requires that provider credentials never be stored in plaintext in the configuration or state. You currently use a shared credentials file referenced by the `profile` argument. Which change best satisfies this requirement while keeping the configuration portable across CI and developer machines?

Accepted Answer

Remove credential arguments and rely on the standard AWS credential provider chain, such as environment variables, IAM roles, or SSO profiles.. The AWS provider integrates with the standard AWS credential provider chain when no explicit credentials are supplied. This allows credentials to be sourced from environment variables, shared files, IAM roles, or SSO, keeping secrets out of Terraform configuration and state. It also supports portability, since CI systems and developer machines can use their own credential mechanisms without changing the Terraform code.

Answer

Create a `terraform.tfvars` file containing the access key and secret key as variables and reference them in the provider block.

Answer

Hardcode the access key and secret key as arguments in the `provider "aws"` block and mark them `sensitive = true`.

Answer

Store the credentials in the S3 backend configuration using the `access_key` and `secret_key` arguments.

Question 15

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.