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