Courseiva

CCNA Provider Management Questions

51 questions · Provider Management · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

When defining a provider in Terraform, what does the 'alias' meta-argument signify?

A.It links to a different provider type.
B.It defines the provider's short name.
C.It allows using multiple configurations of the same provider.
D.The provider is deprecated.
AnswerC

The alias meta-argument creates a named, separate instance of a provider configuration, letting one module address multiple regions, accounts or endpoints of the same provider. Without it, only a single default configuration per provider could be declared.

Why this answer

The 'alias' meta-argument lets you declare multiple configurations of the same provider within a single configuration, each with different settings (e.g., different AWS regions or accounts). Resources then reference the aliased provider to control which configuration they use.

Exam trap

The trap is thinking alias renames or re-points the provider type — candidates confuse it with the local name in required_providers, but alias is strictly for multiple configurations of the same provider.

How to eliminate wrong answers

Option A is wrong because alias does not link to a different provider type — it creates a named variant of the same provider. Option B is wrong because the provider's short name is defined by the local name in required_providers, not by alias. Option D is wrong because alias has nothing to do with deprecation; it is purely a mechanism for multiple provider configurations.

Practice this question →
2
MCQhard

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?

A.Create a `terraform.tfvars` file containing the access key and secret key as variables and reference them in the provider block.
B.Remove credential arguments and rely on the standard AWS credential provider chain, such as environment variables, IAM roles, or SSO profiles.
C.Hardcode the access key and secret key as arguments in the `provider "aws"` block and mark them `sensitive = true`.
D.Store the credentials in the S3 backend configuration using the `access_key` and `secret_key` arguments.
AnswerB

The AWS provider automatically uses the default credential provider chain when no explicit credentials are set. This includes environment variables, shared credentials files, IAM roles for EC2 or ECS, and AWS SSO. Relying on this chain keeps secrets out of the configuration and state, and allows each environment to supply credentials through its native mechanism, satisfying portability and security.

Why this answer

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.

Exam trap

The trap here is thinking that marking credentials as sensitive or placing them in tfvars or backend configuration removes plaintext exposure, when in fact only relying on the credential provider chain avoids storing secrets in Terraform artifacts.

Practice this question →
3
MCQhard

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?

A.Add a `provider_installation` block that maps the AWS provider to the mirror and re-run `terraform init -upgrade` to refresh the hashes.
B.Delete `.terraform.lock.hcl` in the pipeline and let `terraform init` recreate it from the mirror on every run.
C.Set the environment variable `TF_CLI_CONFIG_FILE` to point at a CLI configuration that disables checksum verification during init.
D.Run `terraform providers lock` with `-platform=linux_amd64` against the internal mirror and commit the updated lock file.
AnswerD

`terraform providers lock` records checksums for the platforms you name, so adding linux_amd64 lets CI verify the mirror's package against the lock file. Because the mirror only serves linux_amd64, this is the platform whose hashes must be present, and regenerating the file against the mirror captures the correct values.

Why this answer

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.

Exam trap

The trap here is treating the lock file as platform-neutral, when its checksums are recorded per operating system and architecture.

Practice this question →
4
MCQmedium

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

A.configuration
B.alias
C.provider
D.instance
AnswerC

The provider meta-argument explicitly binds a resource block to a named provider configuration, such as aws.west, overriding the default instance. This satisfies the requirement to associate a resource with a non-default provider instance within the same configuration.

Why this answer

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.

Exam trap

The trap here is confusing the `alias` argument in a provider block with the `provider` meta-argument in a resource block; candidates often mistakenly select `alias` because it is associated with provider instances, but the correct meta-argument for resource association is `provider`.

How to eliminate wrong answers

Option A is wrong because `configuration` is not a valid meta-argument in Terraform; it does not exist for associating resources with providers. Option B is wrong because `alias` is used within a provider block to create a named instance, not within a resource block to reference one. Option D is wrong because `instance` is not a Terraform meta-argument; it might be confused with provider instance terminology but is not used in resource configuration.

Practice this question →
5
MCQhard

An operations engineer runs `terraform init` and notices Terraform downloads the AWS provider from `registry.terraform.io`. The organization requires all provider packages to come from an internal mirror at `mirror.example.com` for compliance. The engineer adds a `provider_installation` block to the CLI configuration file. Which CLI configuration file location and block structure will make Terraform use the mirror for the AWS provider while still allowing other providers from the public registry?

A.Create a `.terraform.lock.hcl` entry mapping the AWS provider to the mirror hostname so `terraform init` reads the source from the lock file.
B.Set the `TF_REGISTRY_CLIENT_TIMEOUT` environment variable to the mirror URL so Terraform prefers the mirror over the public registry.
C.Add a `provider_installation` block inside the root module's `terraform` block so it applies to every workspace using that configuration.
D.Place a `provider_installation` block with a `filesystem_mirror` or `network_mirror` directive in the `.terraformrc` file in the user's home directory, or in `terraform.rc` on Windows.
AnswerD

The CLI configuration file is `~/.terraformrc` on Unix-like systems and `terraform.rc` in the user's `%APPDATA%` directory on Windows. A `provider_installation` block there can define a `network_mirror` or `filesystem_mirror` source, optionally scoped to the `hashicorp/aws` provider, so only AWS resolves from the mirror while other providers continue from the public registry.

Why this answer

Provider install sources are controlled by the CLI configuration file, which lives at `~/.terraformrc` on Unix-like systems and `terraform.rc` under `%APPDATA%` on Windows. A `provider_installation` block there can declare a `network_mirror` or `filesystem_mirror` and include or exclude specific provider source addresses, so the AWS provider resolves from the internal mirror while others continue to use the public registry.

Exam trap

The trap here is confusing Terraform language configuration with CLI configuration and attempting to place `provider_installation` inside a `terraform` block or the lock file.

Practice this question →
6
MCQhard

How do you pass a provider instance from a root module into a child module?

A.Use a module output.
B.Use a variable.
C.Use the 'providers' map in the module block.
D.You cannot pass providers.
AnswerC

The providers map inside a module block passes a configured provider instance, aliased or default, into the child module, so the child uses the parent's configuration rather than instantiating its own. This satisfies explicit provider inheritance across module boundaries.

Why this answer

The providers map inside a module block explicitly passes a configured provider instance (or alias) from the root module into the child module, allowing the child to use a specific provider configuration rather than inheriting the default. This is required when the child module needs a non-default provider alias, a differently configured region, or a provider defined only in the parent. The syntax is providers = { aws = aws.us_east_1 } inside the module block.

Exam trap

The trap is assuming variables or outputs can carry provider configurations — they cannot, because providers are special runtime objects that must be passed via the providers map in the module block.

How to eliminate wrong answers

Option A is wrong because module outputs flow data out of a child module to the parent, not provider configurations into the child — outputs cannot carry provider instances. Option B is wrong because input variables pass values (strings, numbers, lists, objects) but cannot carry provider configurations, which are special runtime objects. Option D is wrong because Terraform explicitly supports passing providers via the providers map, and this is the documented mechanism for provider aliasing across module boundaries.

Practice this question →
7
MCQmedium

What is the primary function of the 'source' attribute in the 'required_providers' block?

A.To define the local path of the provider code.
B.To define the AWS region.
C.To specify the registry address.
D.To enable debugging.
AnswerC

The source attribute gives the provider's registry address, such as registry.terraform.io/hashicorp/aws, telling Terraform where to resolve and download the plugin. This satisfies the requirement to identify the provider's origin rather than merely its local name or version constraint.

Why this answer

The 'source' attribute in the 'required_providers' block specifies the global source address of the provider, which is the registry hostname, namespace, and type. This tells Terraform where to download the provider from, such as 'hashicorp/aws' or 'registry.terraform.io/hashicorp/aws'. It does not define a local path or region.

Exam trap

The trap here is confusing the 'source' attribute with the provider's configuration block, where region and other settings are defined. Candidates might think 'source' refers to a local path or region due to its name.

How to eliminate wrong answers

Option A is wrong because the local path of provider code is not defined by 'source'; instead, a filesystem mirror or local registry can be used, but that is configured via CLI or provider installation methods. Option B is wrong because the AWS region is configured in the provider block or via environment variables, not in 'required_providers'. Option D is wrong because debugging is enabled via TF_LOG environment variable, not through the 'source' attribute.

Practice this question →
8
MCQmedium

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?

A.Add an `alias` argument inside the shared module's terraform block so the module can select its own region at runtime.
B.Create three separate root modules, one per region, and invoke the shared module from each with a different workspace.
C.Set the `region` argument directly on the module block so Terraform forwards it to the module's implicit aws provider.
D.Declare one aliased provider per region in the root module, then pass the matching provider configuration into each module block using the `providers` argument.
AnswerD

The `providers` argument maps a module's provider requirement to a specific provider configuration from the calling module, so three module blocks can each receive a differently aliased aws provider targeting a distinct region. This keeps the shared module region-agnostic and avoids duplicating its source.

Why this answer

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.

Exam trap

The trap here is assuming a module block can accept provider-specific arguments such as region, when only provider configuration blocks accept them.

Practice this question →
9
MCQmedium

A DevOps engineer runs `terraform init` in a CI pipeline that has no internet access. The configuration uses the AWS provider from the public Terraform Registry. The pipeline fails because Terraform cannot download the provider. The team wants to use a local filesystem mirror containing the required provider packages. Which Terraform CLI configuration block should be used to point Terraform to the local mirror?

A.terraform { required_providers { aws = { source = "local/aws" } } }
B.provider_installation { network_mirror { url = "file:///opt/terraform/providers" } }
C.provider_installation { filesystem_mirror { path = "/opt/terraform/providers" } }
D.provider_installation { direct { exclude = ["hashicorp/aws"] } }
AnswerC

The provider_installation block with filesystem_mirror configures Terraform to install providers from a local directory. This is the correct way to use an offline mirror. The path points to a directory structured with provider packages, allowing terraform init to succeed without internet access.

Why this answer

To use a local filesystem mirror for provider installation, the CLI configuration must include a provider_installation block with filesystem_mirror and the path to the mirror directory. This allows Terraform to install providers without network access, which is essential for air-gapped CI pipelines.

Exam trap

The trap here is confusing network_mirror with filesystem_mirror, or attempting to change the provider source in required_providers instead of using CLI configuration.

Practice this question →
10
MCQeasy

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

A.To secure the provider versions and checksums.
B.To encrypt the state file.
C.To prevent others from running init.
D.To download all providers.
AnswerA

The command writes provider checksums into the dependency lock file for multiple platforms, securing the exact provider versions and their hashes. This satisfies the requirement to verify provider integrity across platforms, preventing tampering or unexpected version drift during init.

Why this answer

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.

Exam trap

AWS provider exam often tests the misconception that 'terraform providers lock' encrypts state or prevents init, rather than its actual role in securing provider versions and checksums.

How to eliminate wrong answers

Option B is wrong because encrypting the state file is not the purpose of this command; state encryption is handled differently (e.g., using backend encryption). Option C is wrong because the command does not prevent others from running init; it only locks provider versions and checksums. Option D is wrong because while it may download providers to compute checksums, its primary purpose is to lock versions and checksums, not just download.

Practice this question →
11
MCQeasy

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?

A.terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 4.0" } } }
B.provider "aws" { version = "~> 4.0" }
C.terraform { version = "~> 4.0" }
D.provider_version = "4.0"
AnswerA

The `~>` pessimistic constraint operator permits patch and minor upgrades within major version 4, blocking the breaking changes that version 5 would introduce. Placing it inside `required_providers` within the `terraform` block satisfies the stem's requirement to pin a specific major version of the AWS provider.

Why this answer

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

Exam trap

The trap here is confusing the `terraform` block's own `required_version` (Terraform CLI version) with `required_providers` (provider version), and assuming the legacy `provider { version = ... }` syntax still works.

How to eliminate wrong answers

Option B is wrong because the `version` argument inside a `provider` block was deprecated in Terraform 0.13 and removed in later versions — version constraints must live in `required_providers`. Option C is wrong because the `version` argument directly inside the `terraform` block sets the required Terraform CLI version, not the AWS provider version. Option D is wrong because `provider_version` is not a valid Terraform argument anywhere in the configuration language.

Practice this question →
12
MCQeasy

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?

A.Configure a provider_installation block in the CLI configuration file (~/.terraformrc or terraform.rc) with a network_mirror or filesystem_mirror directive
B.Add a source argument pointing to the mirror URL inside the terraform block of the root configuration
C.Run 'terraform providers lock' with the -platform flag to pre-populate the lock file from the mirror
D.Set the TF_REGISTRY_CLIENT_TIMEOUT environment variable to a longer value and re-run init
AnswerA

Terraform's CLI configuration file supports a provider_installation block where you can declare network_mirror or filesystem_mirror sources. When direct registry access is blocked but an internal mirror is reachable, this block redirects provider downloads to the mirror, allowing init to install the AWS provider without public internet access.

Why this answer

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.

Exam trap

The trap here is conflating the provider source argument in required_providers with mirror configuration, when mirror redirection is controlled only by the CLI configuration file.

Practice this question →
13
MCQeasy

A team wants to reuse an existing, manually managed AWS provider configuration located in a separate directory as the source of truth for a new Terraform configuration, instead of declaring a fresh provider block. Which statement describes how Terraform obtains provider configurations from elsewhere?

A.Use `terraform import` with the provider address to copy the provider configuration into the new working directory.
B.Reference the other directory through a module block and inherit its provider configuration implicitly.
C.Declare a `provider` data source that reads the settings from the other directory at plan time.
D.Provider configurations cannot be imported or shared across directories; each root module must declare its own provider configuration for the AWS provider.
AnswerD

Provider configurations are not resources and cannot be imported, referenced across directories, or shared between root modules. Each root module declares the providers it needs, so the new configuration must define its own aws provider block, even if it mirrors the settings of the existing one.

Why this answer

Provider configurations live in configuration, not state, and are scoped to the root module that declares them. They cannot be imported, copied between directories, or read through a data source. The new configuration must declare its own AWS provider block, optionally using variables or environment variables to mirror the settings of the existing setup.

Exam trap

The trap here is conflating provider configurations with resources, leading to attempts to import or reference them across directories.

Practice this question →
14
MCQhard

An operations engineer runs `terraform init` in a directory whose configuration uses the AWS provider. After init, the engineer inspects `.terraform.lock.hcl` and sees multiple `zh:` hash entries alongside `h1:` entries for the hashicorp/aws provider. A colleague on a different platform then runs `terraform init` and Terraform reports that the provider package does not match any of the checksums recorded in the lock file. Which action most directly resolves the mismatch while preserving reproducibility?

A.Set the environment variable TF_SKIP_PROVIDER_VERIFY=true for the colleague's init run.
B.Add `-upgrade` to the colleague's terraform init command to force Terraform to re-resolve provider versions.
C.Delete .terraform.lock.hcl and rerun terraform init so Terraform regenerates hashes for the current platform.
D.Run `terraform providers lock -platform=<colleague's platform>` and commit the updated lock file.
AnswerD

The zh: entries are platform-specific package hashes, and the colleague's platform is missing from the lock file, so Terraform cannot verify the downloaded package. terraform providers lock with the additional -platform flag records hashes for that platform, and committing the file lets both engineers verify the same provider version reproducibly. This preserves pinning while extending platform coverage.

Why this answer

The lock file stores per-platform package hashes in zh: entries plus a package-level h1: hash. When a platform is absent, verification fails. Running terraform providers lock with the -platform flag for the missing platform adds those hashes, and committing the result keeps the pinned version while allowing every supported platform to verify the same package.

Exam trap

The trap here is reaching for a flag or environment variable that disables verification instead of extending the lock file with the missing platform's hashes.

Practice this question →
15
Multi-Selectmedium

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

Select 3 answers
A.Shared credentials file (~/.aws/credentials).
B.Directly in the provider block.
C.Environment variables (e.g., AWS_ACCESS_KEY_ID).
D.In the .terraform.lock.hcl file.
E.Via the terraform output command.
AnswersA, B, C

Storing long-lived access keys in ~/.aws/credentials lets the AWS CLI and SDKs resolve credentials automatically via the default profile chain, satisfying the requirement for a file-based configuration method without embedding secrets in code or environment variables.

Why this answer

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.

Practice this question →
16
MCQeasy

What is the correct way to specify a version constraint for a provider that must be at least 3.0 but less than 4.0?

A.version = ">= 3.0"
B.version = "3.0"
C.version = "> 3.0, < 4.0"
D.version = "~> 3.0"
AnswerD

The pessimistic constraint operator ~> 3.0 permits versions from 3.0 upward but below 4.0, since it locks the major version while allowing minor and patch increments. This satisfies the stated range of at least 3.0 and less than 4.0.

Why this answer

The pessimistic constraint operator ~> 3.0 means '>= 3.0 and < 4.0', allowing any 3.x release while preventing upgrades to 4.0. This matches the requirement of at least 3.0 but less than 4.0 exactly. It is the idiomatic Terraform way to pin to a major version while accepting minor and patch updates.

Exam trap

The trap is confusing ~> 3.0 (allows 3.x) with ~> 3.0.0 (allows only 3.0.x), or picking >= 3.0 which lacks the required upper bound.

How to eliminate wrong answers

Option A is wrong because >= 3.0 has no upper bound, so it would allow 4.0 and beyond, violating the less-than-4.0 requirement. Option B is wrong because "3.0" is an exact version pin, not a range — it would reject 3.1, 3.2, etc., which the requirement allows. Option C is wrong because > 3.0 excludes 3.0 itself (the requirement says at least 3.0, i.e. >= 3.0), and while < 4.0 is correct, the combination fails the inclusive lower bound.

Practice this question →
17
MCQhard

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?

A.terraform providers schema -json > lock.hcl
B.terraform providers mirror ./vendor -platform=linux_amd64 -platform=darwin_arm64
C.terraform init -upgrade -platform=linux_amd64,darwin_arm64
D.terraform providers lock -platform=linux_amd64 -platform=darwin_arm64
AnswerD

The providers lock command regenerates the dependency lock file and, with repeated -platform flags, records hashes for each specified platform. Including linux_amd64 and darwin_arm64 makes the lock file cover both the CI runner and the Apple Silicon developer workstation, so both environments verify the same provider versions and hashes during init.

Why this answer

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.

Exam trap

The trap here is assuming terraform init can add platform hashes, when only terraform providers lock accepts repeated -platform flags to record hashes for multiple operating systems and architectures.

Practice this question →
18
MCQhard

What happens if you have a provider version conflict in your module dependencies?

A.Terraform will pick the newest version.
B.Terraform will fail to initialize.
C.Terraform will ignore the constraints.
D.Terraform will pick the oldest version.
AnswerB

Terraform resolves a single provider version across all modules during init. If constraints are mutually exclusive, no version satisfies every module, so initialisation aborts before any plan or apply runs, satisfying the conflict scenario described in the stem.

Why this answer

When two modules or the root module declare incompatible version constraints for the same provider, Terraform cannot satisfy both and aborts during 'terraform init' with a provider version conflict error. Terraform does not silently pick a version when constraints are mutually exclusive; it requires the user to reconcile the constraints. This fail-fast behavior prevents unpredictable provider behavior across modules.

Exam trap

The trap is assuming Terraform resolves conflicts by picking a version (newest or oldest) — candidates forget that Terraform fails fast on unsatisfiable constraints rather than guessing.

How to eliminate wrong answers

Option A is wrong because Terraform does not default to the newest version when constraints conflict — it only selects the newest version that satisfies all constraints, and if none exists, it errors. Option C is wrong because Terraform never ignores version constraints; they are enforced during initialization and dependency resolution. Option D is wrong because Terraform does not fall back to the oldest version — there is no such fallback logic in the provider installer.

Practice this question →
19
MCQhard

A Terraform module is used by multiple teams. The module requires the AWS provider but should not enforce a specific provider configuration. The module's author wants to ensure that when the module is used, the caller must pass an AWS provider instance with a specific alias. What should the author include in the module's terraform block?

A.required_providers { aws = { source = "hashicorp/aws" } } and a provider "aws" block with alias = "west".
B.required_providers { aws = { source = "hashicorp/aws", configuration_aliases = [aws.west] } }.
C.A terraform block with required_version = ">= 1.0" and a provider "aws" block with region = "us-west-2".
D.A variable named aws_alias with a default value of "west" and a provider "aws" block using alias = var.aws_alias.
AnswerB

The configuration_aliases argument inside required_providers declares that the module expects an additional provider configuration with the alias aws.west. This informs Terraform that the module's resources may use aws.west, and the caller must pass a matching provider instance using the providers meta-argument.

Why this answer

To require a specific provider alias when a module is used, the module author declares configuration_aliases in the required_providers block. This tells Terraform that the module expects a provider instance with that alias. The caller must then pass it using the providers meta-argument in the module block, such as providers = { aws.west = aws.west }.

Exam trap

The trap here is thinking that a module can define its own aliased provider block, when actually aliased providers must be configured in the root module and passed in.

Practice this question →
20
MCQhard

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

A.Use a filesystem mirror in the .terraformrc file.
B.You cannot use private providers.
C.Rename the file to provider.tf.
D.Copy it to the root of the project.
AnswerA

A filesystem mirror lets Terraform install a provider from a local directory instead of the public Terraform Registry, satisfying the constraint that the provider is unpublished. The .terraformrc provider_installation block redirects installation to that mirror, so no registry lookup occurs.

Why this answer

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.

Exam trap

The trap is thinking private providers are unsupported or that dropping a binary in the project directory works — Terraform requires an explicit mirror or registry configuration via the CLI config file.

How to eliminate wrong answers

Option B is wrong because Terraform fully supports private and custom providers — they simply need to be distributed via a mirror, network mirror, or private registry rather than the public Registry. Option C is wrong because renaming a file to provider.tf has no effect on provider installation; provider installation is controlled by required_providers and CLI configuration, not filenames. Option D is wrong because copying a provider binary to the project root does not register it with Terraform's plugin discovery mechanism — Terraform looks in specific cache/mirror directories defined in the CLI config.

Practice this question →
21
MCQmedium

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

A.Define the region twice in a single provider block.
B.Define two separate aws providers in the same file without aliases.
C.Create two separate Terraform projects.
D.Use an alias in the provider block and reference it in the resource using the provider meta-argument.
AnswerD

Provider aliases create distinct configurations within one provider block, each pinned to a different region. Referencing the alias via the provider meta-argument on a resource directs that resource to the aliased instance, satisfying the requirement to manage two regions from a single configuration.

Why this answer

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.

Exam trap

The trap here is assuming that a single provider block can handle multiple regions by specifying the region multiple times, or that separate projects are needed; candidates often overlook the alias and provider meta-argument mechanism.

How to eliminate wrong answers

Option A is wrong because a provider block cannot contain duplicate `region` arguments; Terraform would throw a duplicate argument error. Option B is wrong because defining two provider blocks of the same type without aliases causes a conflict—Terraform requires aliases to distinguish multiple configurations of the same provider. Option C is wrong because separate Terraform projects would not allow managing resources in multiple regions within the same configuration and state; it also increases complexity and prevents cross-region references.

Option D is correct because using aliases and the `provider` meta-argument is the standard, supported way to use multiple provider configurations in a single module.

Practice this question →
22
Multi-Selectmedium

A platform team is standardizing Terraform provider usage across many AWS accounts. They want to enforce a specific AWS provider version and ensure every root module records the provider source explicitly so that ambiguous provider lookups do not occur. Which two actions should the team take? (Choose two.)

Select 2 answers
A.Rely on the implicit hashicorp/aws lookup by referencing aws in resources without declaring required_providers, since Terraform resolves it automatically.
B.Declare the AWS provider in the terraform block's required_providers with an explicit source = "hashicorp/aws" and a version constraint.
C.Commit the generated .terraform.lock.hcl to version control so all root modules use consistent provider selections.
D.Run terraform providers lock after init to record platform hashes, and rely on that lock file alone to enforce the version.
E.Add a version argument inside the provider "aws" block to lock the provider version.
AnswersB, C

Specifying source and a version constraint in required_providers pins the provider to the intended registry namespace and version range. This removes ambiguity in provider lookup and enforces the standardized version across root modules, directly satisfying both the source-explicitness and version-enforcement goals the platform team defined.

Why this answer

Enforcing a provider version and making source explicit requires declaring source and a version constraint in required_providers, then committing the resulting lock file so selections are reproducible. The provider block cannot carry a version argument, implicit lookup leaves source ambiguous, and the lock file alone does not constrain future resolution without a declared constraint.

Exam trap

The trap here is treating the lock file or an implicit provider lookup as sufficient version enforcement, when the constraint must be declared in required_providers and the lock file committed alongside it.

Practice this question →
23
Multi-Selecthard

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

Select 2 answers
A.It replaces the Terraform CLI.
B.It manages the Terraform state lock.
C.It compiles HCL to Go code.
D.It provides a way to define schema for resources.
E.It handles resource lifecycle methods (Create, Read, Update, Delete).
AnswersD, E

The Plugin SDK exposes schema definition constructs that providers use to declare resource and data source attributes, including their types, optionality and validation. This schema drives Terraform's configuration parsing and state handling, making schema definition a core SDK capability.

Why this answer

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.

Practice this question →
24
MCQhard

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?

A.Terraform ignores the plugin directory because the AWS provider is a hashicorp provider and must be downloaded from the registry.
B.Terraform installs both providers from the plugin directory and writes a lock file entry for each.
C.Terraform installs the AWS provider from the plugin directory but still downloads the example provider because it is not a hashicorp provider.
D.Terraform uses the plugin directory as the only source for provider plugins and skips the usual provider installation steps.
AnswerD

When -plugin-dir is specified, Terraform searches only the given directories for provider plugins and does not attempt to install providers from a registry or from other configured sources. This is intended for offline or air-gapped environments where providers are pre-placed in a local directory.

Why this answer

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.

Exam trap

The trap here is confusing -plugin-dir with provider installation from a filesystem mirror, which does create lock file entries and follows the normal installation workflow.

Practice this question →
25
MCQhard

When writing a custom provider, what is the 'Schema' used for?

A.To define the attributes of resources.
B.To define the cloud service billing.
C.To define the provider's icon.
D.To store state.
AnswerA

The Schema block declares each resource's attributes, their types, and whether they are required, optional, or computed. This lets Terraform validate configuration and map values to the provider's API calls, satisfying the need to describe resource structure before CRUD operations run.

Why this answer

In the Terraform Plugin SDK, a provider's 'Schema' defines the structure, types, and behaviour of every attribute on a resource or data source — including whether fields are Required, Optional, Computed, their types, defaults, and validation. It is the contract between Terraform configuration and the provider's CRUD functions.

Exam trap

The trap is conflating the Schema with state or provider metadata — candidates who have not written a provider may pick 'to store state' because the Schema is serialized into state, but its actual purpose is to define resource attributes.

How to eliminate wrong answers

Option B is wrong because billing is handled by the cloud provider's APIs and the AWS provider's cost estimation integration, not by the resource Schema. Option C is wrong because the provider's icon/logo is metadata in the registry manifest, not part of the Schema. Option D is wrong because state storage is handled by Terraform's state backend and the SDK's state serialization, not by the Schema definition itself — the Schema describes attributes, while state is the persisted representation of those attributes.

Practice this question →
26
Multi-Selectmedium

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

Select 2 answers
A.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.
B.A single module may define only one provider configuration per provider type, so the aliased aws.dr block is invalid.
C.The resource must include the meta-argument `provider = aws.dr` to use the DR region configuration.
D.If the resource omits the provider meta-argument, it uses the default aws configuration in eu-central-1.
E.Declaring a second aws provider block with a different region automatically makes the resource use whichever region is defined last in the file.
AnswersC, D

Provider selection is opt-in per resource. Without the provider meta-argument naming the alias, the resource uses the module's default aws configuration and would be created in eu-central-1. Writing provider = aws.dr explicitly binds the route53 record to the DR configuration, which is the only supported way to target an aliased provider from within the same module.

Why this answer

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.

Exam trap

The trap here is thinking that defining an aliased provider block changes the target region for resources automatically rather than requiring each resource to name the alias.

Practice this question →
27
MCQmedium

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?

A.Pass a `region` variable into the module and use the `aws` provider's `default_tags` to set the partition implicitly.
B.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.
C.Create the AWS provider configuration inside the module itself with two `provider "aws"` blocks using different aliases and region variables.
D.Use a single default AWS provider configuration in the root and set the `region` argument dynamically inside the module using a variable.
AnswerB

Declaring `configuration_aliases` in the child module for the two aliases lets the caller pass the appropriate commercial or China provider configuration for each alias. Resources then target the correct alias, so the module supports both partitions and multiple regions without hardcoding a region or partition, matching the requirement exactly.

Why this answer

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.

Exam trap

The trap here is believing that setting a region variable inside the module is sufficient to switch partitions, when partition selection is governed by the provider configuration supplied by the root.

Practice this question →
28
MCQeasy

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?

A.The teammate must delete `.terraform.lock.hcl` and re-run `terraform init` so Terraform regenerates it locally.
B.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.
C.The AWS provider version `~> 5.0` is incompatible with `darwin_arm64`, so the teammate must downgrade to version 4.x.
D.The teammate should set `TF_REGISTRY_CLIENT_TIMEOUT` to a larger value so the download of the `darwin_arm64` package completes.
AnswerB

The dependency lock file records checksums per platform. If it was generated only on `linux_amd64`, it contains no hashes for `darwin_arm64`, so init on macOS fails verification. Running `terraform providers lock -platform=linux_amd64 -platform=darwin_arm64` adds the missing hashes, and committing the result lets every platform verify the same provider version.

Why this answer

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.

Exam trap

The trap here is treating a checksum mismatch as a corruption or network problem and deleting the lock file instead of adding the missing platform hashes.

Practice this question →
29
MCQhard

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?

A.Delete .terraform.lock.hcl from version control and let each environment regenerate it independently
B.Add a provider_installation block with direct = true so Terraform ignores the lock file on CI
C.Run 'terraform providers lock -platform=linux_amd64 -platform=darwin_arm64' and commit the updated lock file
D.Set the TF_PLUGIN_CACHE_DIR environment variable on the CI runner to reuse the developer's cached provider
AnswerC

The providers lock command with multiple -platform flags records package checksums for each specified platform in .terraform.lock.hcl. Including both linux_amd64 and darwin_arm64 ensures every environment finds a matching entry, so init succeeds on CI and developer machines while preserving checksum verification and version pinning.

Why this answer

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.

Exam trap

The trap here is thinking the lock file is platform-agnostic and that any regenerated copy works everywhere, when in reality missing platform hashes cause init failures on other operating systems.

Practice this question →
30
MCQeasy

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

A.terraform.tfstate
B.terraform.tfvars
C..terraform.lock.hcl
D.provider.tf
AnswerC

The `.terraform.lock.hcl` file is created automatically by `terraform init` to record the exact provider versions selected and their cryptographic checksums. This satisfies the stem's requirement for a generated file that locks versions and verifies integrity, ensuring consistent provider installations across runs and preventing tampering.

Why this answer

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.

Exam trap

The trap is confusing the lock file with state or variable files. Candidates might think terraform.tfstate locks providers, but it only stores resource state. The exam tests knowledge of the specific file for provider version locking.

How to eliminate wrong answers

Option A is wrong because terraform.tfstate stores the state of managed resources, not provider locks. Option B is wrong because terraform.tfvars is for variable values, not provider locking. Option D is wrong because provider.tf is a user-created configuration file for provider blocks, not an auto-generated lock file.

Practice this question →
31
Multi-Selecteasy

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

Select 2 answers
A.In the required_providers block.
B.In the resource block.
C.In the backend block.
D.In the provider block using the 'version' argument (deprecated).
E.In the output block.
AnswersA, D

The `required_providers` block within a `terraform` block accepts a `version` argument, letting you pin or constrain a provider's version directly in configuration. This satisfies the stem's requirement for a valid specification method, as Terraform reads these constraints during initialisation to select a compatible provider release.

Why this answer

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.

Exam trap

The trap is assuming version can be set anywhere provider-related — candidates pick resource or backend blocks, but only required_providers and the deprecated provider-block argument are valid.

Practice this question →
32
Multi-Selectmedium

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

Select 3 answers
A.terraform providers
B.TF_LOG=DEBUG
C.terraform fmt
D.terraform taint
E.terraform init
AnswersA, B, E

`terraform providers` lists every provider required by the current configuration and its child modules, showing the source address and version constraints each module declares. This directly exposes version conflicts or missing provider requirements during debugging, satisfying the need to inspect provider dependencies across the configuration.

Why this answer

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.

Exam trap

The trap is selecting formatting or taint commands as debugging tools — only providers, TF_LOG, and init actually expose provider installation, version, or runtime behavior.

Practice this question →
33
MCQmedium

If a resource is not specified with a provider meta-argument, which provider instance does it use?

A.The first one defined.
B.The provider configuration without an alias.
C.The one with the latest version.
D.It causes an error.
AnswerB

When a resource omits the provider meta-argument, Terraform binds it to the default provider configuration — the one declared without an alias in the required_providers block. Aliased configurations are only selected through an explicit provider argument, so the unaliased instance is the implicit default.

Why this answer

When a resource omits the provider meta-argument, Terraform associates it with the default provider configuration — the one declared without an alias. Aliased provider configurations (e.g., provider "aws" { alias = "west" }) are only used when a resource explicitly references them via provider = aws.west. This default-association rule is fundamental to how Terraform resolves provider instances.

Exam trap

The trap is assuming Terraform uses the first-declared or latest-version provider; candidates miss that the unaliased (default) configuration is the one automatically applied when provider is omitted.

How to eliminate wrong answers

Option A is wrong because Terraform does not pick 'the first one defined' — provider selection is based on the absence of an alias, not declaration order. Option C is wrong because provider version selection is handled separately via required_providers version constraints, not by which configuration a resource uses. Option D is wrong because omitting the provider argument is perfectly valid and does not cause an error as long as a default (unaliased) provider configuration exists for that provider type.

Practice this question →
34
MCQmedium

When using multiple provider instances with different regions, what must be defined in the provider configuration?

A.A unique alias identifier.
B.A unique project ID.
C.A credentials object.
D.A version constraint in each block.
AnswerA

Multiple provider blocks for the same provider need a unique alias so resources and modules can reference the intended region explicitly, for example aws.west versus aws.east. Without distinct aliases Terraform cannot tell the instances apart.

Why this answer

When you declare multiple instances of the same provider (e.g., two `aws` providers for different regions), each non-default instance must have a unique `alias` argument. Resources then select the desired instance using the `provider = aws.<alias>` meta-argument. Without an alias, Terraform cannot distinguish the instances and errors on duplicate provider configuration.

Exam trap

The trap is thinking multiple provider blocks can coexist without aliases, or that credentials/version constraints are what differentiate them — the `alias` argument is the mandatory differentiator.

How to eliminate wrong answers

Option B is wrong because a 'project ID' is not a Terraform provider concept — it's a GCP-specific identifier and irrelevant to aliasing. Option C is wrong because a credentials object is not required to define multiple provider instances; credentials can be inherited from environment variables, shared config files, or IAM roles, and are orthogonal to aliasing. Option D is wrong because version constraints belong in `required_providers`, not in each aliased provider block, and are not what distinguishes multiple instances.

Practice this question →
35
MCQeasy

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

A.The root module directory
B.~/.terraformrc
C..terraform/providers/
D./usr/local/bin/terraform
AnswerC

Terraform caches downloaded provider plugins in the .terraform/providers/ directory within the working directory, so subsequent runs reuse them without re-downloading. This satisfies the default storage location constraint, as init installs providers there unless a plugin cache directory is configured.

Why this answer

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

Practice this question →
36
MCQmedium

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?

A.Define an input variable for the role ARN and reference it in the `assume_role` block of the AWS provider configuration.
B.Hardcode the production role ARN in the `provider "aws"` block and override it with a `-var` flag during staging runs.
C.Create two aliased AWS provider blocks, one per environment, and select the correct one using a `count` expression on the provider block.
D.Set the `AWS_ROLE_ARN` environment variable and rely on the AWS provider to assume that role automatically without any `assume_role` block.
AnswerA

The AWS provider's `assume_role` block accepts `role_arn`, `session_name`, and related arguments, and any of them can reference input variables. Feeding the role ARN from a variable lets the same configuration target staging or production based on the variable value supplied by the pipeline, without embedding credentials or duplicating provider blocks.

Why this answer

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.

Exam trap

The trap here is believing that an environment variable like `AWS_ROLE_ARN` alone makes the Terraform AWS provider assume a role, or that `-var` can override a hardcoded provider argument.

Practice this question →
37
MCQeasy

Which command helps verify if the providers are properly initialized?

A.terraform validate
B.terraform show
C.terraform plan
D.terraform providers
AnswerD

`terraform providers` lists every provider required by the configuration alongside its source address and version constraints, reading the dependency lock file and module manifests. This directly satisfies the stem's requirement to verify proper initialisation, since missing or uninitialised providers appear as unresolved entries rather than confirmed installations.

Why this answer

'terraform providers' lists all providers required by the configuration, confirming they are initialized.

Practice this question →
38
MCQeasy

Which block is used to configure provider-level settings like region or profile?

A.module {}
B.provider "aws" {}
C.terraform {}
D.resource "aws_instance" {}
AnswerB

The provider block, such as provider "aws" {}, declares and configures the provider plugin, accepting arguments like region and profile. This directly satisfies the requirement to set provider-level settings, since these values are passed to every resource managed by that provider.

Why this answer

The 'provider' block is used to configure the provider itself.

Practice this question →
39
MCQhard

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?

A.terraform plan -refresh-only
B.terraform init -upgrade
C.terraform providers install
D.terraform refresh
AnswerB

terraform init -upgrade re-resolves provider version constraints and downloads the newest permitted versions, bypassing the cached binary. This satisfies the stem's requirement to force a fresh download when the provider binary is missing from the local registry cache.

Why this answer

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.

Exam trap

The trap is confusing 'terraform init -upgrade' with other commands like 'terraform refresh' or 'terraform plan -refresh-only', which do not handle provider installation. Candidates might also think 'terraform providers install' exists.

How to eliminate wrong answers

Option A is wrong because 'terraform plan -refresh-only' only refreshes the state to match remote objects and does not install or upgrade providers. Option C is wrong because 'terraform providers install' is not a valid Terraform command; provider installation is done via 'terraform init'. Option D is wrong because 'terraform refresh' updates the state file with real-world resources but does not manage provider installation.

Practice this question →
40
MCQhard

If a developer wants to use a provider that is not in the public registry, can they still use it?

A.Yes, by using a local registry or filesystem mirror.
B.No, only registry providers are supported.
C.Yes, by setting the env var TF_IN_AUTOMATION.
D.Yes, by recompiling Terraform binary.
AnswerA

Terraform resolves providers through installation sources beyond the public registry, including local filesystem mirrors and private registries. Configuring such a source lets the developer install and use the provider normally, so absence from the public registry is not a blocker.

Why this answer

Terraform supports provider installation from local filesystem mirrors or a local registry, not just the public Terraform Registry. A filesystem mirror is a directory containing provider packages in the expected layout, and a local registry can serve providers over HTTP. This allows developers to use custom or private providers without publishing them publicly.

Exam trap

The trap here is assuming that Terraform only supports providers from the public registry, overlooking the provider installation configuration options like filesystem mirrors and local registries.

How to eliminate wrong answers

Option B is wrong because Terraform can install providers from sources other than the public registry, such as filesystem mirrors or network mirrors. Option C is wrong because TF_IN_AUTOMATION is an environment variable that adjusts Terraform's output to be more automation-friendly; it does not enable provider installation from non-public sources. Option D is wrong because recompiling the Terraform binary is not required to use custom providers; Terraform's provider plugin architecture allows external providers to be installed and used without modifying the core binary.

Practice this question →
41
MCQmedium

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?

A.Terraform fails the plan because a child module that declares required_providers must also declare its own provider block.
B.The child module inherits the root module's default AWS provider configuration, so the bucket is planned in us-west-2.
C.The provider is instantiated independently inside the child module and uses the AWS SDK default region from the execution environment.
D.The bucket is planned in the region declared inside the hashicorp/aws provider's own default configuration.
AnswerB

Because the child module declares no provider block of its own, it automatically inherits the root module's default (unaliased) provider configuration, including region us-west-2. The required_providers entry only constrains source and version, it does not create or isolate a provider instance. This inheritance is the standard behavior for unaliased providers passed implicitly down the module tree.

Why this answer

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.

Exam trap

The trap here is assuming that declaring required_providers inside a child module forces that module to define or isolate its own provider configuration.

Practice this question →
42
MCQmedium

What is the effect of running 'terraform init -upgrade' on the '.terraform.lock.hcl' file?

A.It deletes the file.
B.It makes the file read-only.
C.It hides the file.
D.It updates the file to reflect new provider versions.
AnswerD

Running `terraform init -upgrade` re-resolves provider version constraints and rewrites `.terraform.lock.hcl` with the newest versions permitted by your configuration, along with fresh checksums. This satisfies the stem's requirement to reflect upgraded provider selections, whereas a plain `terraform init` installs only the versions already recorded in the lock file.

Why this answer

Running 'terraform init -upgrade' re-resolves provider version constraints against the registry and updates the .terraform.lock.hcl file to record the newly selected provider versions and their hashes. It is the supported way to move to newer provider releases without deleting the lock file manually.

Exam trap

The trap is thinking the lock file is immutable or that init -upgrade deletes it — it actually rewrites the file to capture upgraded provider versions and hashes.

How to eliminate wrong answers

Option A is wrong because init -upgrade rewrites the lock file rather than deleting it. Option B is wrong because the lock file remains writable by Terraform; it is not chmod'd to read-only. Option C is wrong because the file is not hidden — it is a normal dotfile in the working directory.

Practice this question →
43
MCQmedium

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?

A.Declare a second aws provider block without an alias and place it after the default provider block.
B.Add `provider = aws.prod` to the resource block so it uses the aliased production provider configuration.
C.Set `region = "<prod-region>"` directly on the aws_iam_role resource block.
D.Move the aws_iam_role resource into a child module and pass the production provider via the module's providers argument.
AnswerB

A resource selects a non-default provider configuration through the provider meta-argument, written as the provider type followed by the alias, aws.prod. Without it, the resource would use the default configuration and be created in the development account. This is the standard mechanism for directing individual resources to aliased provider instances within the same module.

Why this answer

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.

Exam trap

The trap here is assuming that an aliased provider configuration is applied automatically based on proximity or declaration order rather than being explicitly referenced by each resource.

Practice this question →
44
MCQmedium

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?

A.Duplicate the child module source into three copies, each with a hardcoded region in its `provider` block.
B.Add a `region` argument to each `module` block in the root module and reference `var.region` inside the child module.
C.Declare multiple aliased AWS provider configurations in the root module and pass the appropriate `providers` map to each `module` block.
D.Set the `AWS_REGION` environment variable to a different value before each `terraform apply` and rely on the child module to pick it up.
AnswerC

Provider configurations are inherited by child modules, and the `providers` meta-argument on a `module` block lets the root map each child's default AWS provider to a specific aliased root provider configuration. This changes the region per module instance without editing the child module's resources, which is exactly the intended mechanism for multi-region reuse of a shared module.

Why this answer

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.

Exam trap

The trap here is assuming a `region` argument can be placed on a `module` block or that a child module can define its own provider block to control region independently.

Practice this question →
45
MCQmedium

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`?

A.Terraform upgrades the provider to a version that satisfies both constraints automatically.
B.Terraform reports an error because no single provider version satisfies both constraints.
C.Terraform ignores the module's constraint and uses the root module's 4.x constraint.
D.Terraform selects version 4.x for the module and 5.x for the root, allowing both to coexist.
AnswerB

Terraform intersects all provider version constraints from the root module and every child module. The child requires `~> 5.0` and the root requires `~> 4.0`, which have no overlap. During `terraform init`, Terraform fails with an error indicating that no available version meets the combined constraints, and the user must align the constraints before proceeding.

Why this answer

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.

Exam trap

The trap here is assuming Terraform can install different provider versions for different modules or that the root module's constraint always wins, when in fact constraints are intersected and must all be satisfied by one version.

Practice this question →
46
MCQmedium

If a user omits the 'version' in 'required_providers', what version does Terraform use?

A.It will fail to initialize.
B.The latest available version.
C.Version 1.0.0.
D.The oldest available version.
AnswerB

Omitting the version constraint lets Terraform select the newest provider release available in the registry, satisfying the stem's scenario where no version is pinned. Terraform resolves this during initialisation, installing the latest matching version and recording it in the dependency lock file.

Why this answer

When the 'version' argument is omitted inside a required_providers block, Terraform does not pin the provider to any specific release and instead resolves to the newest version available in the configured registry (public Terraform Registry or private registry). This is why HashiCorp strongly recommends always pinning versions in production to avoid unexpected breaking changes.

Exam trap

The trap here is assuming Terraform requires an explicit version and will error out — candidates confuse 'recommended' with 'required', but version is optional and defaults to latest.

How to eliminate wrong answers

Option A is wrong because omitting 'version' is perfectly valid syntax — Terraform will still initialize and simply select the latest compatible release. Option C is wrong because Terraform does not default to 1.0.0; there is no implicit baseline version. Option D is wrong because Terraform selects the newest version, not the oldest, since it always prefers the most recent release that satisfies any constraints.

Practice this question →
47
MCQmedium

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?

A.Terraform selects the newest AWS provider version that satisfies all constraints, including the root module's ~> 4.0.
B.Terraform uses the version from the child module's lock file if present, otherwise it uses the root module's constraint.
C.Terraform selects the latest AWS provider version that satisfies the child module's unconstrained requirement, ignoring the root module's constraint.
D.Terraform fails because the child module does not specify a version constraint.
AnswerA

Terraform collects version constraints from every module's required_providers block and selects the newest provider version that satisfies all of them. The child module's unconstrained declaration imposes no restriction, so the root module's ~> 4.0 constraint determines the upper and lower bounds for selection.

Why this answer

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.

Exam trap

The trap here is thinking that a child module's missing version constraint causes failure or overrides the root constraint, when actually it simply adds no restriction.

Practice this question →
48
Multi-Selectmedium

What are common reasons to use multiple provider instances? (Select TWO)

Select 2 answers
A.Increasing performance of the Terraform CLI.
B.Installing multiple versions of the same provider.
C.Bypassing the need for a state file.
D.Using different credentials for different resources.
E.Deploying resources to multiple AWS regions.
AnswersD, E

Separate provider instances each carry their own authentication configuration, so distinct credential sets can be applied per instance. Resources referencing the appropriate alias then authenticate with the intended credentials, satisfying the need to isolate access across resources.

Why this answer

Option D is correct because multiple provider instances (created with the alias meta-argument) let you attach distinct credential sets to different resources, for example managing resources in separate AWS accounts or with different IAM roles within one configuration. Option E is correct because aliased provider instances are the standard way to target multiple AWS regions in a single configuration, such as provider "aws" { alias = "us_east" } and provider "aws" { alias = "eu_west" }, then referencing them per resource. Option A is not a reason for multiple provider instances, since Terraform CLI performance is governed by parallelism and graph execution, not by the number of provider configurations.

Option B is incorrect because provider versions are pinned in the required_providers block, not by instantiating multiple provider instances. Option C is incorrect because a state file is always required for tracking real infrastructure; provider aliases do not eliminate it.

Practice this question →
49
Multi-Selecthard

A platform engineer is preparing a Terraform configuration that will run in an environment where the AWS provider must be pinned to a specific minor version, and the provider must be sourced from the public Terraform Registry. The engineer also wants to ensure that `terraform init` records the selected version and checksums for later verification. Which two actions should the engineer take? (Choose two.)

Select 2 answers
A.Add a `provider "aws"` block with a `version` argument set to the desired minor version.
B.Add a `required_providers` block in the `terraform` block specifying the AWS provider with a `source` of `hashicorp/aws` and a version constraint such as `~> 5.40.0`.
C.Commit the generated `.terraform.lock.hcl` file to version control after running `terraform init`.
D.Set the `TF_CLI_CONFIG_FILE` environment variable to point at a file that contains the provider version constraint.
E.Run `terraform providers lock -platform=linux_amd64` to generate checksums for all platforms.
AnswersB, C

Declaring the AWS provider in `required_providers` with an explicit `source` and a `~>` version constraint pins the provider to the specified minor version range and confirms the public registry as the source. This is the standard way to enforce version discipline and ensure the correct provider is selected during initialization.

Why this answer

Declaring the AWS provider in `required_providers` with a `~>` version constraint pins the minor version and confirms the public registry source, while committing the generated lock file preserves the exact version and checksums for reproducible, verified installs. Together these actions enforce version discipline and integrity across runs.

Exam trap

The trap here is assuming that a `version` argument inside a `provider` block still constrains provider versions, when modern Terraform requires version constraints in `required_providers`.

Practice this question →
50
Multi-Selecthard

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

Select 2 answers
A.It is automatically generated by terraform init.
B.It is used to store the state file.
C.It can only be edited manually.
D.It stores secret credentials.
E.It should be committed to version control.
AnswersA, E

Terraform generates the dependency lock file during `terraform init`, recording the exact provider versions and hashes selected. This satisfies the stem's requirement for a true statement about the file's origin, since initialisation resolves and pins providers before any plan or apply runs.

Why this answer

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.

Exam trap

The trap is assuming the lock file stores state or secrets — it stores provider version pins and checksums, and the exam tests whether you know it belongs in version control.

Practice this question →
51
MCQmedium

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

A.Python
B.Ruby
C.HCL
D.Go
AnswerD

Terraform providers are written in Go, using the Terraform Plugin SDK or Plugin Framework. This satisfies the stem's requirement for the standard language: HashiCorp builds and distributes all official providers in Go, and the plugin protocol's libraries are Go-first, making it the only supported choice for custom provider development.

Why this answer

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.

Exam trap

The trap here is confusing the language used to write Terraform configurations (HCL) with the language used to implement Terraform providers (Go), or assuming that because Terraform supports multiple languages via CDKTF, providers can be written in any language.

How to eliminate wrong answers

Option A is wrong because Python is not used to write Terraform providers; while Python can be used with CDK for Terraform (CDKTF) to synthesize Terraform configurations, that is a different abstraction and does not create providers. Option B is wrong because Ruby is not a supported language for provider development; no official Terraform plugin SDK exists for Ruby. Option C is wrong because HCL (HashiCorp Configuration Language) is the declarative language used to write Terraform configurations, not the imperative code that implements provider logic.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Provider Management questions.

Start 20-question session