002 · Domain 1: Scalable Terraform Configuration Design · 20% of the exam
Task 1.7: Configure Terraform providers
Provider requirements and configuration at scale: source addresses and version constraints, aliases and configuration_aliases in modules, the dependency lock file, and terraform providers lock for every platform a team runs on.
Study it
Providers at scale: requirements, aliases in modules and the lock file
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 2
The root module defines provider "aws" configurations with the aliases use1,
euw1 and apse1. An engineer writes:
module "edge" {
for_each = toset(["use1", "euw1", "apse1"])
source = "./edge"
providers = { aws = aws[each.key] }
}
Which two statements are correct? (Choose TWO.)
APut a provider block with region = each.key inside ./edge for each instance to configure itself
BProvider associations are static; instances of one module call cannot receive different configurations
CDeclare configuration_aliases for all three configurations in ./edge to let for_each pick one per key
DPass the region as an input variable and set it on the inherited providers inside the module
EWrite one module block per region, each passing its own aliased configuration in providers
Show the answer and why
APut a provider block with region = each.key inside ./edge for each instance to configure itself
Incorrect
A module that contains its own provider configuration cannot be called with for_each at all.
BProvider associations are static; instances of one module call cannot receive different configurations
Correct
Because the association between resources and provider configurations is static, a module call with for_each cannot pass a different configuration to each instance.
CDeclare configuration_aliases for all three configurations in ./edge to let for_each pick one per key
Incorrect
configuration_aliases declares names a module expects to receive; it does not let one module call map instances to different configurations.
DPass the region as an input variable and set it on the inherited providers inside the module
Incorrect
Provider configurations live in the root module; a child module cannot reconfigure an inherited provider from its own variables.
EWrite one module block per region, each passing its own aliased configuration in providers
Correct
A separate module block for each distinct provider configuration is the documented pattern for this case.
Because the association between resources and provider configurations is static, for_each and count cannot vary it per instance. Use a separate module block for each set of provider configurations.
CI runners install providers only from an internal network mirror. The team wants the committed .terraform.lock.hcl to hold the official checksums signed by each provider's publisher for linux_amd64 and darwin_arm64, so that later installs from the mirror are checked against them. A workstation can reach the public registry. What should the team run there?
Entries made from a mirror record the checksums the mirror reports, not the origin registry's signed checksums.
Cterraform init -upgrade on a Linux runner and on a Mac, committing the lock file after each
Incorrect
init through the mirror records only what it can verify for the platform it runs on, and -upgrade may also select newer versions.
Dterraform providers mirror ./mirror, then commit the mirror directory next to the lock file
Incorrect
It does not record the publisher-signed checksums in the lock file, which is what the team needs.
Only an origin registry can supply checksums covered by the publisher's signature. Running providers lock against the registry with each platform pre-populates those hashes, and init through the mirror then verifies against them.
Before a provider upgrade, an engineer edits .terraform.lock.hcl, changes constraints = "~> 5.0" to "~> 6.0" in the hashicorp/aws block, and runs terraform init. Terraform keeps the same 5.x release. Why?
Ainit restores the lock file from the backend before it reads it
BThe hashes no longer match the edited constraints, so init skips the file
Cconstraints only explains a past selection; installs never read it
DOnly terraform providers lock may change entries in the lock file
Show the answer and why
Ainit restores the lock file from the backend before it reads it
Incorrect
The lock file lives in the working directory with the configuration; backends store state, not lock files.
BThe hashes no longer match the edited constraints, so init skips the file
Incorrect
The checksums belong to the selected version's packages; editing constraints does not change them.
Cconstraints only explains a past selection; installs never read it
Correct
The constraints value lists what Terraform considered, to help human readers; it plays no part in installation decisions.
DOnly terraform providers lock may change entries in the lock file
Incorrect
terraform init also maintains the lock file, for example when provider requirements change.
Change the version constraint in required_providers instead, then run terraform init -upgrade so Terraform considers newer versions, and review the resulting lock file diff.
A company builds its own provider and distributes it only through a filesystem directory on build agents. What source address should modules use for it in required_providers?
Asource = "ourcloud", which Terraform then finds in the local plugins directory on each agent
Running terraform providers lock on a laptop downloads every provider again, even though a plugin cache directory is configured. Why?
AThe plugin cache stores only providers that were installed from a network mirror
Bproviders lock always clears the cache before it starts
CThe cache works only with terraform init -upgrade
DThe lock command skips the cache unless -enable-plugin-cache is given
Show the answer and why
AThe plugin cache stores only providers that were installed from a network mirror
Incorrect
The cache can hold providers from any installation method; that is not why it is skipped.
Bproviders lock always clears the cache before it starts
Incorrect
Terraform never deletes plugins from the cache itself.
CThe cache works only with terraform init -upgrade
Incorrect
Normal init runs use the cache too; the lock command is the exception.
DThe lock command skips the cache unless -enable-plugin-cache is given
Correct
The cache is not an authoritative source, so the command, which exists to guard against untrusted versions, does not use it by default.
providers lock fetches packages from the origin registries to record trustworthy checksums. Use the cache flag only when speed matters more than that guarantee.
A provider developer wants Terraform to use a local build of hashicorp/null from /home/dev/null-build while every other provider installs normally. Which CLI configuration does that?
The dev_overrides block must always appear first in the sequence.
Dplugin_cache_dir = "/home/dev/null-build"
Incorrect
The plugin cache stores downloaded releases; it does not override the provider selected for a configuration.
Development overrides bypass version and checksum checks for one provider, so keep them in a separate CLI configuration file that you select with TF_CLI_CONFIG_FILE while developing.