Skip to content
Cheat sheets

004 · Domain 8: HCP Terraform · 12% of the exam

Task 8.4: Configure and use HCP Terraform integration

Connecting the CLI: terraform login and its token, the cloud block with organization and workspaces, migrating local state with init, and running plans remotely from a laptop.

Study it

  • Connecting the CLI: terraform login, the cloud block and state migration

    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 developer runs terraform login on a laptop. What does the command do with the HCP Terraform API token it obtains?

  1. AWrites it into the cloud block of the configuration in the current directory
  2. BSaves it in plain text in credentials.tfrc.json
  3. CKeeps it in memory only until the terminal is closed
  4. DStores it in the dependency lock file, encrypted
Show the answer and why

  • AWrites it into the cloud block of the configuration in the current directory

    Incorrect

    login never edits configuration files.

  • BSaves it in plain text in credentials.tfrc.json

    Correct

    terraform login obtains an API token and by default saves it in plain text in a local CLI configuration file called credentials.tfrc.json.

  • CKeeps it in memory only until the terminal is closed

    Incorrect

    The token is saved to disk by default.

  • DStores it in the dependency lock file, encrypted

    Incorrect

    The lock file holds provider selections, not credentials.

login is for interactive machines; protect or relocate the saved token.

HashiCorp documentation

Task 8.4Report a problem with this question

Question 2 · choose 1

A configuration must use the existing HCP Terraform workspace "network-prod" in the organization "acme". What is the minimal setup?

  1. AA provider "hcp" block with the organization and workspace, then terraform plan
  2. BA backend "local" block with path = "app.terraform.io/acme/network-prod"
  3. CA cloud block naming the organization and workspace, then terraform init
  4. DAn environment variable TF_ORG=acme and no configuration change
Show the answer and why

  • AA provider "hcp" block with the organization and workspace, then terraform plan

    Incorrect

    The connection is configured with the cloud block, not a provider.

  • BA backend "local" block with path = "app.terraform.io/acme/network-prod"

    Incorrect

    The local backend stores state on disk.

  • CA cloud block naming the organization and workspace, then terraform init

    Correct

    The cloud block in the terraform block sets the organization and workspace; after adding or changing it, run terraform init.

  • DAn environment variable TF_ORG=acme and no configuration change

    Incorrect

    TF_ORG is not a variable that Terraform reads.

cloud block plus init connects a working directory to HCP Terraform.

HashiCorp documentation

Task 8.4Report a problem with this question

Question 3 · choose 1

With the cloud block configured, a developer runs terraform plan locally. Where does the plan run, and which variables does it use?

  1. AIt runs on the laptop with only local variables, and uploads the result
  2. BIt runs in HCP Terraform but ignores all workspace variables
  3. CIt is queued until someone approves it in the UI
  4. DRemotely, with the workspace's variables
Show the answer and why

  • AIt runs on the laptop with only local variables, and uploads the result

    Incorrect

    In the CLI-driven workflow the plan executes in HCP Terraform.

  • BIt runs in HCP Terraform but ignores all workspace variables

    Incorrect

    Workspace variables are used in remote runs.

  • CIt is queued until someone approves it in the UI

    Incorrect

    Speculative plans need no approval.

  • DRemotely, with the workspace's variables

    Correct

    CLI-driven runs execute remotely in HCP Terraform, use variables from the workspace and stream progress to the terminal.

The CLI-driven workflow keeps the familiar commands and moves execution to HCP Terraform.

HashiCorp documentation

Task 8.4Report a problem with this question

Question 4 · choose 1

A working directory has been connected to HCP Terraform for years through the older backend "remote" configuration. The team moves it to the current HCP Terraform integration in the CLI. What happens to its existing workspaces and their state?

  1. ANew workspaces are created for the integration, and the old ones are left unused
  2. BTerraform downloads each workspace's state and asks to push it back after the change
  3. CThe workspaces must be deleted and created again before the integration can use them
  4. DTerraform keeps using the same workspaces and their state; nothing is copied
Show the answer and why

  • ANew workspaces are created for the integration, and the old ones are left unused

    Incorrect

    No new workspaces are created; the configuration keeps pointing at the ones it already uses.

  • BTerraform downloads each workspace's state and asks to push it back after the change

    Incorrect

    The state is already in HCP Terraform, so there is nothing to download or push.

  • CThe workspaces must be deleted and created again before the integration can use them

    Incorrect

    Deleting the workspaces would throw away their state and history for no reason; they work as they are.

  • DTerraform keeps using the same workspaces and their state; nothing is copied

    Correct

    When a directory already uses the remote backend, the switch is a configuration change, and Terraform continues to use the same set of HCP Terraform workspaces.

Moving from the remote backend is a change of configuration, not a migration of state: the workspaces, their state versions and their run history stay where they are.

HashiCorp documentation

Task 8.4Report a problem with this question

Question 5 · choose 1

A company runs Terraform Enterprise at tfe.example.com. How does the cloud block point at it instead of HCP Terraform?

  1. AUse a provider "tfe" block with the hostname
  2. BSet hostname = "tfe.example.com" in the cloud block
  3. CSet the hostname in required_providers
  4. DNothing; the CLI detects Terraform Enterprise automatically
Show the answer and why

  • AUse a provider "tfe" block with the hostname

    Incorrect

    The provider manages HCP Terraform objects; it does not connect the CLI.

  • BSet hostname = "tfe.example.com" in the cloud block

    Correct

    The cloud block's hostname defaults to app.terraform.io and can be set to a Terraform Enterprise deployment.

  • CSet the hostname in required_providers

    Incorrect

    required_providers is for providers.

  • DNothing; the CLI detects Terraform Enterprise automatically

    Incorrect

    The default is app.terraform.io.

Same cloud block, different hostname, for Terraform Enterprise.

HashiCorp documentation

Task 8.4Report a problem with this question

Question 6 · choose 1

A developer leaves a shared machine and wants to remove the HCP Terraform token that terraform login saved there. Which command does this?

  1. Aterraform logout
  2. Bterraform login -delete
  3. Cterraform workspace delete
  4. Dterraform init -reconfigure
Show the answer and why

  • Aterraform logout

    Correct

    terraform logout removes credentials stored by terraform login.

  • Bterraform login -delete

    Incorrect

    login has no delete option.

  • Cterraform workspace delete

    Incorrect

    That deletes a workspace's state, not credentials.

  • Dterraform init -reconfigure

    Incorrect

    That reconfigures the backend.

login saves a token; logout removes it.

HashiCorp documentation

Task 8.4Report a problem with this question

Question 7 · choose 1

In the CLI-driven workflow, a developer runs terraform plan -var "replicas=5", while the workspace has a workspace-specific variable replicas = 3. Which value does the remote plan use?

  1. A3, since workspace variables always win in remote runs
  2. BThe plan fails because CLI variables are not allowed with HCP Terraform
  3. C5, since CLI -var overwrites them for the run
  4. DBoth values are averaged
Show the answer and why

  • A3, since workspace variables always win in remote runs

    Incorrect

    CLI -var values take precedence in CLI-driven runs.

  • BThe plan fails because CLI variables are not allowed with HCP Terraform

    Incorrect

    -var is supported in CLI-driven runs.

  • C5, since CLI -var overwrites them for the run

    Correct

    With the CLI workflow, variables applied to a run with -var or -var-file overwrite workspace-specific variables and non-priority variable sets with the same key.

  • DBoth values are averaged

    Incorrect

    One value wins.

Run-specific CLI variables beat stored variables for that run.

HashiCorp documentation

Task 8.4Report a problem with this question

Practise domain 8 →Practise all domains →