Sample questions
Terraform Providers Lifecycle ProvisionersDifficulty 1
What is the purpose of the required_providers block inside a Terraform terraform {} block?
- aIt lists the cloud regions the configuration is allowed to deploy resources into — this describes a related but distinct concept, not what is actually being asked here
- bIt declares which providers the configuration needs, including their source address and version constraint✓
- cIt stores the provider's API credentials directly in version control, a common misconception that does not hold up when the actual behavior is checked
- dIt defines the naming convention Terraform must use for every resource in the configuration, a common misconception that does not hold up when the actual behavior is checked
Explanation:The required_providers block tells Terraform which providers (by source, e.g. hashicorp/aws) and which version constraints a configuration depends on, so terraform init can download the matching provider plugin. It has nothing to do with regions, credentials, or naming conventions.
Terraform Providers Lifecycle ProvisionersDifficulty 1
In a version constraint like version = "~> 5.10" for a provider, what does the ~> operator generally mean?
- aIt forces Terraform to always install the exact literal version 5.10, with no exceptions, a common misconception that does not hold up when the actual behavior is checked
- bIt means the provider version is completely unrestricted and any version may be installed, which sounds reasonable but is not how this mechanism actually works in practice
- cIt allows the rightmost version component to increase, so newer 5.x releases are allowed but not 6.0✓
- dIt downgrades the provider to the oldest version that ever matched 5.10 — technically incorrect, since it misstates what this feature is actually responsible for
Explanation:The pessimistic constraint operator ~> allows only the rightmost specified version segment to increment. ~> 5.10 permits 5.10, 5.11, 5.12, etc., but not 6.0 — it's a common way to accept patch/minor updates while avoiding accidental major upgrades.
Terraform Providers Lifecycle ProvisionersDifficulty 1
What does a provider "aws" { region = "eu-west-1" } block configure?
- aThe default settings (such as region and credentials) that the AWS provider uses when a resource does not specify an alternate provider✓
- bA new AWS account that Terraform creates on the fly — this describes a related but distinct concept, not what is actually being asked here
- cA resource that must be destroyed before any other resource in the configuration, a common misconception that does not hold up when the actual behavior is checked
- dThe list of allowed AWS services that resources in the configuration may use, a common misconception that does not hold up when the actual behavior is checked
Explanation:A provider block configures a provider instance — things like region, credentials, or endpoint overrides — that resources reference either implicitly (the default provider block for that type) or explicitly via the provider meta-argument.
Terraform Providers Lifecycle ProvisionersDifficulty 2
If a Terraform configuration has no version constraint at all for a provider in required_providers, what is the practical risk?
- aTerraform refuses to run
terraform init until a constraint is added, a common misconception that does not hold up when the actual behavior is checked - bThe provider automatically pins itself to version 1.0.0 for safety, which sounds reasonable but is not how this mechanism actually works in practice
- cTerraform falls back to a built-in provider that ignores all cloud API calls — a plausible-sounding claim that does not match how Terraform actually behaves here
- dA later
terraform init -upgrade (or a fresh clone without a lock file) may pull in a newer, potentially breaking provider version✓
Explanation:Without any version constraint, Terraform is free to select the newest available provider version satisfying no restriction at all, so an upgrade or a fresh environment without the .terraform.lock.hcl committed can silently jump to a version with breaking changes.
Terraform Providers Lifecycle ProvisionersDifficulty 1
What does the alias meta-argument on a provider block enable?
- aRenaming a resource without destroying and recreating it — a plausible-sounding claim that does not match how Terraform actually behaves here
- bDefining an additional, non-default configuration of the same provider, so a single configuration can talk to more than one region or account✓
- cAutomatically encrypting all state written by that provider, which sounds reasonable but is not how this mechanism actually works in practice
- dSkipping the
terraform init step for that specific provider — technically incorrect, since it misstates what this feature is actually responsible for
Explanation:alias lets you declare a second (or third, etc.) named configuration for the same provider type — for example two aws provider blocks with different regions — so resources can pick which configuration to use via provider = aws.<alias>.
Terraform Providers Lifecycle ProvisionersDifficulty 2
A team needs to create an S3 bucket in us-east-1 and a separate bucket in eu-west-1 within the same Terraform configuration, using a single AWS account. What is the standard way to do this?
- aRun two completely separate Terraform configurations in two different git repositories, since one configuration cannot target two regions, which sounds reasonable but is not how this mechanism actually works in practice
- bSet
region twice in a single provider "aws" block, one after another — a plausible-sounding claim that does not match how Terraform actually behaves here, which sounds reasonable but is not how this mechanism actually works in practice - cDefine a default
aws provider for one region and a second, aliased aws provider for the other region, then reference the aliased one on the second bucket's provider argument✓ - dUse
depends_on on the bucket resource to switch its region at apply time, which sounds reasonable but is not how this mechanism actually works in practice, a common misconception that does not hold up when the actual behavior is checked
Explanation:Multi-region (or multi-account) setups within one configuration are the classic use case for provider aliases: one default provider block plus one or more aliased provider blocks, with each resource picking its provider via the provider meta-argument.