002 · Domain 2: Terraform State and Backend Operations · 13% of the exam
Task 2.4: Upgrade Terraform versions across environments
Rolling a new Terraform version through development, staging and production: required_version constraints, the v1.x compatibility promises, state written by newer versions, and upgrading one environment at a time.
Study it
Upgrading Terraform environment by environment
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 1
Development, staging and production each have their own root module directory and state, and all call shared modules. The team is moving from Terraform 1.13 to 1.15 one environment at a time, and once an environment is upgraded, nobody must be able to run an older CLI against it. Which plan meets both goals?
AUpgrade production first, since the v1.x promises guarantee older CLIs can read newer state
BSet required_version = ">= 1.15" in the shared modules to move every environment over together at once
CUpgrade each environment's runners in turn and pin that root module's required_version to ~> 1.15
DKeep required_version unchanged in each root module, as the compatibility promises make mixed CLI versions safe
Show the answer and why
AUpgrade production first, since the v1.x promises guarantee older CLIs can read newer state
Incorrect
Upgrades between v1.x releases are supported, but downgrading is not guaranteed: later releases may use state formats earlier ones cannot read.
BSet required_version = ">= 1.15" in the shared modules to move every environment over together at once
Incorrect
Every root module must satisfy its modules' constraints, so this forces all environments to upgrade at once instead of one at a time.
CUpgrade each environment's runners in turn and pin that root module's required_version to ~> 1.15
Correct
Each environment moves on its own schedule, and its required_version makes an older CLI exit with an error before touching its state.
DKeep required_version unchanged in each root module, as the compatibility promises make mixed CLI versions safe
Incorrect
The promises cover upgrading, not running older versions against state that a newer version has written.
Because each environment has its own root module, its required_version can change on its own schedule. A newer CLI may write state that an older one cannot read, so pin the upgraded environment to stop older CLIs.
A team upgrades its runners from Terraform 1.11 to 1.15. The new release works on current build agents, but one legacy Linux agent still runs a 2.6 kernel and can no longer run Terraform. What explains this?
AThe v1.x promises require every agent to run one release
BState written by 1.11 must be upgraded on that agent first
CTerraform 1.15 runs only on ARM-based Linux agents
DTerraform 1.12 and later need Linux kernel 3.2 or newer
Show the answer and why
AThe v1.x promises require every agent to run one release
Incorrect
The promises cover compatibility between releases; they set no rule that all agents match.
BState written by 1.11 must be upgraded on that agent first
Incorrect
Upgrades within v1.x need no extra upgrade steps, and the failure is about the agent itself.
CTerraform 1.15 runs only on ARM-based Linux agents
Incorrect
Official releases cover Linux on x64 as well as ARM.
DTerraform 1.12 and later need Linux kernel 3.2 or newer
Correct
The v1.12 upgrade guide says Terraform requires Linux kernel 3.2 or later, and the promises allow later v1.x releases to end support for earlier kernels.
Check build agents against every upgrade guide between the old and new release, not only the configuration: later v1.x releases may require newer operating system versions.
A team plans to upgrade Terraform across environments whose state lives in the s3 and gcs backends and wants to know what the v1.x compatibility promises cover. What do they say about state storage backends?
AEvery backend that ships with Terraform CLI is covered in the same way
BOnly local and http are covered; s3 and gcs settings may change
CBackends are covered, but only when they use state locking
DNo backend is covered, as backends are separate plugins
Show the answer and why
AEvery backend that ships with Terraform CLI is covered in the same way
Incorrect
The promises cover only the backends that the Terraform team maintains.
BOnly local and http are covered; s3 and gcs settings may change
Correct
Only the local and http backends are subject to the promises; s3 is maintained by another HashiCorp team and gcs by outside contributors, so their arguments can change within v1.x.
CBackends are covered, but only when they use state locking
Incorrect
Coverage depends on who maintains a backend, not on locking.
DNo backend is covered, as backends are separate plugins
Incorrect
Backends are built into Terraform CLI, and the local and http backends are covered.
Before upgrading, read the changelog and upgrade guides for changes to the backends in use, especially community-maintained ones, whose arguments and behavior may change within v1.x.
A team's upgrade automation wraps several CLI commands and must keep working across v1.x releases without changes. Which command is outside the protected workflow commands that the promises cover?
Aterraform plan -out=FILE
Bterraform show -json
Cterraform state mv
Dterraform apply -auto-approve
Show the answer and why
Aterraform plan -out=FILE
Incorrect
plan with -out is a protected workflow command.
Bterraform show -json
Incorrect
show with -json is a protected workflow command.
Cterraform state mv
Correct
state mv is listed among the commands that might change, so automation around it may need updates.
Dterraform apply -auto-approve
Incorrect
apply with -auto-approve is a protected workflow command.
Automation should stick to the protected commands and their JSON output or exit codes; human-readable output is not a stable interface.
A pipeline step must record which Terraform CLI release and provider releases a runner uses, in a format a script can parse reliably. What should it run?
Aterraform version -json
Bterraform providers mirror ./mirror
Cterraform init -upgrade -json
Dterraform -v parsed with a regular expression
Show the answer and why
Aterraform version -json
Correct
The -json option prints machine-readable output and is part of the protected workflow commands.
Bterraform providers mirror ./mirror
Incorrect
That command does not report which releases a runner uses.
Cterraform init -upgrade -json
Incorrect
That can change provider selections, which a version check must not do.
Dterraform -v parsed with a regular expression
Incorrect
Human-readable output is not a stable interface and may change.
Prefer documented JSON output to parsing text when automation needs version facts.