Skip to content
Cheat sheets

004 · Domain 2: Terraform fundamentals · 13% of the exam

Task 2.4: Explain how Terraform uses and manages state

Why state exists: mapping configuration to real objects, metadata such as dependencies, performance on large estates, and the default terraform.tfstate file, which holds every value in plain text and is never edited by hand.

Study it

  • What state is for: bindings, metadata, caching, and why it is sensitive

    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

An engineer suggests that Terraform could skip state entirely and find its resources by tags on every run. Why does Terraform keep state instead?

  1. AIt needs a binding for each resource instance, and many resources cannot be tagged
  2. BTags are read-only for providers, so Terraform cannot set them on the resources it creates
  3. CState is only a performance cache, and Terraform could work without it at the cost of speed
  4. DState stores the configuration, so Terraform can run without the .tf files
Show the answer and why

  • AIt needs a binding for each resource instance, and many resources cannot be tagged

    Correct

    State maps configuration to real objects, such as an instance ID; tags were tried early on and failed because not all resources support them.

  • BTags are read-only for providers, so Terraform cannot set them on the resources it creates

    Incorrect

    Providers can usually set tags; the problem is that many resource types have none.

  • CState is only a performance cache, and Terraform could work without it at the cost of speed

    Incorrect

    Caching is the most optional part of state. The mapping and metadata make state a requirement.

  • DState stores the configuration, so Terraform can run without the .tf files

    Incorrect

    State does not replace configuration; it records what the configuration manages.

State is required: it is the database of bindings between configuration and the real world, plus metadata that configuration alone cannot carry.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 2 · choose 1

A configuration has an instance inside a subnet. Both blocks are deleted from the configuration in the same change. The configuration no longer says that the instance depends on the subnet, yet Terraform destroys the instance first. How does it know the order?

  1. AState keeps each resource's most recent dependencies, so the order is still known
  2. BTerraform has a built-in ranking of resource types that puts instances before subnets
  3. CTerraform reads the previous version of the configuration from the .terraform directory
  4. DThe provider deletes resources in the order the API returns them
Show the answer and why

  • AState keeps each resource's most recent dependencies, so the order is still known

    Correct

    Terraform retains a copy of the latest set of dependencies in state so it can order destruction when items are removed from configuration.

  • BTerraform has a built-in ranking of resource types that puts instances before subnets

    Incorrect

    Terraform does not rank resource types; that approach was rejected as too complex across every provider.

  • CTerraform reads the previous version of the configuration from the .terraform directory

    Incorrect

    The .terraform directory holds providers, modules and backend settings, not old configuration.

  • DThe provider deletes resources in the order the API returns them

    Incorrect

    Terraform, not the API listing, decides the order of operations.

Besides mappings, state stores metadata such as dependencies, exactly for operations on resources that have left the configuration.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 3 · choose 1

Before computing a plan, what does Terraform do with the resources already recorded in state, by default?

  1. AIt trusts the recorded attributes and contacts no provider at all
  2. BIt reads their current attributes through the providers
  3. CIt deletes them from state and re-imports them
  4. DIt reads only resources that changed in the configuration
Show the answer and why

  • AIt trusts the recorded attributes and contacts no provider at all

    Incorrect

    By default every plan reads the current attributes first.

  • BIt reads their current attributes through the providers

    Correct

    For every plan and apply, Terraform syncs all resources in state by default before comparing with the configuration.

  • CIt deletes them from state and re-imports them

    Incorrect

    Refreshing updates attributes; it does not remove or re-import bindings.

  • DIt reads only resources that changed in the configuration

    Incorrect

    The default refresh covers every resource in state.

Refresh first, then compare: that is how a plan sees changes made outside Terraform.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 4 · choose 1

A reporting tool needs the values of a configuration's root outputs and the attributes of its resources after each apply in a pipeline. What is the supported integration point?

  1. AParsing terraform.tfstate directly, which holds every value the tool needs
  2. BReading the .terraform.lock.hcl file after apply
  3. CScraping the colored text that terraform apply prints
  4. DThe -json output of terraform output and terraform show
Show the answer and why

  • AParsing terraform.tfstate directly, which holds every value the tool needs

    Incorrect

    terraform.tfstate is not the documented integration point for other software; the JSON output of Terraform's own commands is.

  • BReading the .terraform.lock.hcl file after apply

    Incorrect

    The lock file lists provider selections, not outputs or attributes.

  • CScraping the colored text that terraform apply prints

    Incorrect

    Human-oriented output is not a stable interface; the JSON outputs are.

  • DThe -json output of terraform output and terraform show

    Correct

    terraform output -json and terraform show -json produce JSON intended for external software, so tools do not parse state directly.

Run terraform output -json and terraform show -json right after a successful apply and keep the result as an artifact of the run, so other software never needs to run Terraform itself.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 5 · choose 1

Someone deletes a managed storage bucket in the cloud console. The configuration still declares it. What does the next terraform plan show?

  1. ANo changes, because the bucket is still recorded in state
  2. BAn error until the bucket is removed from the configuration
  3. CThat the bucket will be imported back from the console's trash
  4. DThe bucket will be created, since refresh found it gone
Show the answer and why

  • ANo changes, because the bucket is still recorded in state

    Incorrect

    Refresh updates state from the real infrastructure before planning, so the missing bucket is noticed.

  • BAn error until the bucket is removed from the configuration

    Incorrect

    A missing object is a normal difference to plan for, not an error.

  • CThat the bucket will be imported back from the console's trash

    Incorrect

    Terraform never restores deleted objects; it creates a new one.

  • DThe bucket will be created, since refresh found it gone

    Correct

    During refresh Terraform learns the object no longer exists and the configuration still asks for it, so it plans a create.

State is refreshed against reality; an object that disappeared is simply planned for creation again.

HashiCorp documentation

Task 2.4Report a problem with this question

Question 6 · choose 1

A day after an apply, an engineer runs terraform output in the same working directory and gets the load balancer's address immediately, without any provider being contacted. Where does the value come from?

  1. AThe root module's output values recorded in the state
  2. BA new refresh of the load balancer, run quietly in the background by the output command
  3. CThe saved plan file, which terraform apply leaves in the working directory
  4. DThe .terraform directory, where init caches the configuration's outputs
Show the answer and why

  • AThe root module's output values recorded in the state

    Correct

    terraform output reads output values from the state file, which stores root module outputs after each apply.

  • BA new refresh of the load balancer, run quietly in the background by the output command

    Incorrect

    output does not refresh resources; it reads what the latest state snapshot holds.

  • CThe saved plan file, which terraform apply leaves in the working directory

    Incorrect

    apply without -out writes no plan file, and output does not read plans.

  • DThe .terraform directory, where init caches the configuration's outputs

    Incorrect

    init keeps what it installs and sets up there, never output values.

Root outputs are part of state, so terraform output reads them without planning.

HashiCorp documentation

Task 2.4Report a problem with this question

Practise domain 2 →Practise all domains →