Skip to content
Cheat sheets

002 · Domain 7: HCP Terraform / Enterprise Operations · 12% of the exam

Task 7.4: Upgrade Terraform versions across workspaces

Moving many HCP Terraform workspaces to a new Terraform version: the workspace version setting, required_version, speculative plans to check, and state that newer versions write.

Study it

  • Upgrading Terraform versions across workspaces

    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

A team tests Terraform 1.15 for a workspace with a speculative plan, switches the workspace's Terraform version in its settings, and merges the matching required_version change. The run that follows reports no changes and does not ask to apply, and the stored state still shows the old Terraform version. What completes the upgrade?

  1. APull the state with terraform state pull and push it back with the newer CLI
  2. BRoll the workspace back to the previous state version and apply a normal run
  3. CStart a new run with the Allow empty apply run type and apply it
  4. DRun another speculative plan with the new version selected
Show the answer and why

  • APull the state with terraform state pull and push it back with the newer CLI

    Incorrect

    Manual state manipulation is not needed and risks overwriting newer data; HCP Terraform provides a run type for this.

  • BRoll the workspace back to the previous state version and apply a normal run

    Incorrect

    A rollback restores an older state version; it does not upgrade the state to the new version.

  • CStart a new run with the Allow empty apply run type and apply it

    Correct

    An empty apply lets Terraform apply a plan without infrastructure changes, upgrading the state file version during the apply.

  • DRun another speculative plan with the new version selected

    Incorrect

    Speculative plans test compatibility but can never be applied, so they cannot write the upgraded state.

Upgrade a workspace in three steps: test with a speculative plan on the new version, change the workspace's Terraform version, then use an empty apply so the state is written by the new version.

HashiCorp documentation

Task 7.4Report a problem with this question

Question 2 · choose 1

A team migrates a project from the CLI to HCP Terraform using Terraform 1.13. Which Terraform version does the new workspace use?

  1. AThe newest release available
  2. BThe version written in required_version
  3. CThe oldest supported release
  4. D1.13, the version used to migrate
Show the answer and why

  • AThe newest release available

    Incorrect

    That applies to workspaces created directly.

  • BThe version written in required_version

    Incorrect

    The workspace sets its own version.

  • CThe oldest supported release

    Incorrect

    No such default exists.

  • D1.13, the version used to migrate

    Correct

    Migrated workspaces use the version of the binary used for migration; new workspaces get the most recent version.

Change the version later in the workspace's general settings.

HashiCorp documentation

Task 7.4Report a problem with this question

Question 3 · choose 1

A pull request raises required_version to "~> 1.15.0", but the workspace still uses 1.14.2. What happens to the speculative plan?

  1. AIt upgrades the workspace automatically
  2. BIt fails on the version constraint
  3. CIt runs with 1.15 for this plan only
  4. DIt passes, as speculative plans skip the check
Show the answer and why

  • AIt upgrades the workspace automatically

    Incorrect

    A plan never changes the workspace's version setting.

  • BIt fails on the version constraint

    Correct

    When the workspace version does not satisfy the constraint, the plan fails until the workspace version is updated.

  • CIt runs with 1.15 for this plan only

    Incorrect

    A speculative plan triggered by the pull request runs with the workspace's version.

  • DIt passes, as speculative plans skip the check

    Incorrect

    The constraint applies to every run.

Upgrading needs both the workspace version and the constraint changed.

HashiCorp documentation

Task 7.4Report a problem with this question

Question 4 · choose 1

A platform team wants fifty workspaces to pick up new 1.15 patch releases without editing each one every time. What does the workspace version setting allow?

  1. AA version constraint such as ~> 1.15.0
  2. BOnly an exact version number
  3. COnly the keyword latest
  4. DA link to a binary URL
Show the answer and why

  • AA version constraint such as ~> 1.15.0

    Correct

    The setting accepts an exact version or a valid version constraint.

  • BOnly an exact version number

    Incorrect

    Constraints are allowed too.

  • COnly the keyword latest

    Incorrect

    Exact versions and constraints are accepted.

  • DA link to a binary URL

    Incorrect

    Versions come from the releases HCP Terraform offers.

Pair the workspace constraint with a matching required_version in the configuration.

HashiCorp documentation

Task 7.4Report a problem with this question

Question 5 · choose 1

Some old workspaces show only partial structured run output in the UI. Which upgrade gives full functionality?

  1. AAny release from 0.12 on
  2. BTurning off the Console UI
  3. CTerraform 1.0.5 or later
  4. DPremium edition
Show the answer and why

  • AAny release from 0.12 on

    Incorrect

    0.15.2 and older give partial results.

  • BTurning off the Console UI

    Incorrect

    Console UI is a separate output option.

  • CTerraform 1.0.5 or later

    Correct

    Structured Run Output needs Terraform 1.0.5 or higher for full functionality.

  • DPremium edition

    Incorrect

    The requirement is a Terraform version.

Version upgrades can unlock UI features as well as language features.

HashiCorp documentation

Task 7.4Report a problem with this question

Practice domain 7 →Practice all domains →