002 · Domain 2: Terraform State and Backend Operations · 13% of the exam
Task 2.3: Identify dependency chains before upgrades
Knowing what an upgrade touches before it starts: terraform providers and graph, the dependency graph, version constraints in modules, and the import, moved and removed blocks that a new release may depend on.
Study it
Dependency chains: the graph Terraform walks and the order it implies
Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.
Question 1 · choose 1
The root module wants to move hashicorp/aws from 5.x to 6.x. It calls an in-house network module that requires ">= 5.0" and a third-party database module whose current release requires "~> 5.80". Before changing anything, the team wants to know what will block the upgrade and why. Which conclusion is correct?
Aterraform providers lists each module's requirement; the database module's ~> 5.80 must change first
Bterraform init -upgrade installs 6.x for the root module and 5.x for the database module side by side
Cterraform graph highlights the conflicting version constraints between the modules
DA root constraint of ~> 6.0 takes precedence over the database module's constraint
Show the answer and why
Aterraform providers lists each module's requirement; the database module's ~> 5.80 must change first
Correct
Terraform selects one version per provider that satisfies every module's constraint, so ~> 5.80 rules out 6.x until a new module release relaxes it.
Bterraform init -upgrade installs 6.x for the root module and 5.x for the database module side by side
Incorrect
A configuration uses a single version of each provider, chosen to meet all constraints together.
Cterraform graph highlights the conflicting version constraints between the modules
Incorrect
terraform graph shows dependency ordering between resources, not provider version constraints.
DA root constraint of ~> 6.0 takes precedence over the database module's constraint
Incorrect
Root and child constraints are treated as equal, and Terraform proceeds only when all of them are met.
Version constraints from every module combine. Inspect them with terraform providers, then upgrade or replace the module whose constraint excludes the target version before raising the root constraint.
Before an upgrade window, a team saves tfplan with the new provider release and wants a picture of the dependency ordering Terraform will use to apply exactly that plan. Which command produces it?
Aterraform graph, with no options given at all
Bterraform graph -plan=tfplan > apply.dot
Cterraform show -json tfplan > apply.dot
Dterraform validate -json, with tfplan
Show the answer and why
Aterraform graph, with no options given at all
Incorrect
The default output is a simplified graph of the configuration's resource and data dependencies, not of a specific plan.
Bterraform graph -plan=tfplan > apply.dot
Correct
-plan produces a graph for applying the given plan and implies -type=apply.
Cterraform show -json tfplan > apply.dot
Incorrect
show -json prints JSON, not the DOT language that Graphviz renders.
Dterraform validate -json, with tfplan
Incorrect
validate reports configuration diagnostics; it does not describe operation ordering.
Tying the graph to the saved plan shows the ordering that the apply will follow. Render the DOT output with Graphviz.
Before a provider upgrade, an engineer maps dependencies. Whenever module.network has pending changes, the data sources in module.app show their results as known after apply. The block module "app" sets depends_on = [module.network]. What explains this?
AThe provider upgrade has already changed the data source schemas
BData sources are always read during the apply phase
CTerraform reads data sources only after refreshing every resource
DThat dependency reaches every one of the data sources within it
Show the answer and why
AThe provider upgrade has already changed the data source schemas
Incorrect
The upgrade has not happened yet, and the deferred reads come from the dependency, not from a schema change.
BData sources are always read during the apply phase
Incorrect
Terraform reads data sources during planning when their arguments do not need computing.
CTerraform reads data sources only after refreshing every resource
Incorrect
Refresh happens before planning, and data sources are still read during planning when nothing defers them.
DThat dependency reaches every one of the data sources within it
Correct
When the dependency is an entire module, depends_on affects all of the resources and data sources associated with that module, and the reads wait for the dependency's operations.
Module-level depends_on is a broad dependency chain. Prefer references to specific outputs, as depends_on makes plans more conservative.
A reviewer finds version = "= 2.4.0, < 3.0.0" in a module's required_providers entry. What does the version constraint documentation say about this string?
AIt selects 2.4.0, and the upper bound only records intent
BIt allows any release from 2.4.0 up to but excluding 3.0.0
CIt is invalid: = cannot be combined with other conditions
DIt behaves the same as the constraint ~> 2.4.0
Show the answer and why
AIt selects 2.4.0, and the upper bound only records intent
Incorrect
An exact version cannot be combined with other conditions, so this is not a valid way to record intent.
BIt allows any release from 2.4.0 up to but excluding 3.0.0
Incorrect
That range is written ">= 2.4.0, < 3.0.0"; the = operator allows one version only.
CIt is invalid: = cannot be combined with other conditions
Correct
The = operator, or no operator, allows only one exact version and cannot be combined with other conditions.
DIt behaves the same as the constraint ~> 2.4.0
Incorrect
~> 2.4.0 allows a range of patch releases, not one exact version.
Use a bare exact version to pin, or a range such as ">= 2.4.0, < 3.0.0", but not both in one string.
A shared module enables a language experiment with experiments = [...] in its terraform block, and twelve configurations call it. The platform team is preparing to upgrade Terraform across all of them. What does the terraform block reference say about this dependency?
AExperiments can change in any later release, even minor or patch ones
BExperiments stay stable for the whole v1.x series once they are enabled
CExperiments apply only inside the module, so callers are unaffected
DExperiments are ignored unless each caller enables them too
Show the answer and why
AExperiments can change in any later release, even minor or patch ones
Correct
The reference says experiments are subject to arbitrary changes in later releases, with breaking changes possible in minor and patch releases, so the module must be retested for each upgrade.
BExperiments stay stable for the whole v1.x series once they are enabled
Incorrect
Experimental features are outside the compatibility promises and may change or be removed.
CExperiments apply only inside the module, so callers are unaffected
Incorrect
The module's configuration is part of every caller's configuration, so a changed experiment can break each of them.
DExperiments are ignored unless each caller enables them too
Incorrect
The reference asks nothing of callers; it notes that a module with an experiment enabled warns on every plan and apply.
HashiCorp does not recommend experiments in modules intended for production. To try one in a shared module, enable it only in alpha or beta releases of that module.