Courseiva
Understand IaC concepts →mediumMultiple Choice

Terraform State Drift: Resources in State but Missing from Config Will Be Destroyed

Exhibit

# terraform plan output
Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c55b159cbfafe1f0"
      + instance_type = "t2.micro"
      + tags          = {
          + "Name" = "WebServer"
        }
    }

  # aws_instance.db will be destroyed
  - resource "aws_instance" "db" {
      - ami           = "ami-0c55b159cbfafe1f0" -> null
      - instance_type = "t2.micro" -> null
    }
Plan: 1 to add, 0 to change, 1 to destroy.

Based on the exhibit, what can be inferred about the Terraform state and configuration?

Quick Answer

The answer is that the aws_instance.db resource in state but missing from config will be destroyed. This is correct because Terraform operates on a desired-state reconciliation model: it compares the current configuration against the state file, and any resource present in state but absent from the configuration is treated as a deletion candidate. The terraform plan output explicitly marks aws_instance.db for destruction, confirming that Terraform will remove it to align real-world infrastructure with the declared config. On the HashiCorp Terraform Associate TF-003 exam, this concept tests your understanding of state drift and how Terraform handles resources that are no longer defined in code—a common trap is assuming Terraform ignores orphaned state entries. Remember the memory tip: "State without config? Terraform sends it to the grave." This behavior is fundamental to Terraform's idempotent infrastructure management, where the config is the single source of truth.

⚠ Common exam trap

HashiCorp often tests the distinction between resources missing from configuration (destroy) versus resources missing from the real world (re-create), and the trap here is confusing manual deletion with configuration removal.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The aws_instance.db resource is in state but not in configuration, so it will be destroyed.

The `terraform plan` output shows that `aws_instance.db` exists in the state file but is absent from the current configuration. Terraform interprets this as a resource that should be removed to align the real-world infrastructure with the configuration, so it will be destroyed. This is a core behavior of Terraform's desired-state management: any resource in state but not in configuration is marked for deletion.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    The aws_instance.db resource is in state but not in configuration, so it will be destroyed.

    Why this is correct

    Terraform state lists aws_instance.db while the configuration no longer declares it, so the resource is orphaned. Applying the plan reconciles state to configuration by destroying that instance, satisfying the stem's inference about drift between the two.

  • ✗

    The configuration for aws_instance.db has been added back to the .tf files.

    Why it's wrong here

    Re-adding configuration would show a plan to create the instance, not the refresh result in the exhibit. It is tempting because editing .tf files is how resources are normally declared, and would be correct if the state listed the resource but the configuration no longer contained its block.

  • ✗

    The aws_instance.db resource was manually deleted from the AWS console.

    Why it's wrong here

    Manual console deletion would remove the instance from state during refresh, producing a plan to create it, which the exhibit does not show. It is tempting because out-of-band changes are a common cause of drift, and would be correct if the state file no longer tracked the resource.

  • ✗

    The aws_instance.web resource is being imported into Terraform management.

    Why it's wrong here

    Importing adds an existing resource to state via terraform import, which the exhibit's plan output does not depict. It is tempting because import reconciles unmanaged infrastructure with configuration, and would be correct when a resource exists in the provider but is absent from the state file.

About these practice questions

This TF-004 question is part of Courseiva's 434-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

2 more ways this is tested on TF-004

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Refer to the exhibit. After applying this configuration, a team member manually changes the instance type to 't2.small' via the AWS console. The next `terraform plan` shows a change to revert to 't2.micro'. What does this demonstrate?

hard
  • A.Terraform's drift detection only
  • B.Immutable infrastructure pattern
  • ✓ C.Terraform's desired state reconciliation
  • D.A misconfiguration in the Terraform code

Why C: Terraform operates on a desired state model: the configuration file defines the target state (t2.micro), and `terraform plan` detects that the actual state (t2.small) has diverged from it. The plan proposes to revert the instance type to t2.micro, demonstrating Terraform's reconciliation of the actual infrastructure back to the declared desired state. This is not merely drift detection (which only reports differences) but active enforcement of the desired configuration.

Variation 2. A team uses Terraform to manage AWS resources. After a manual change to an S3 bucket policy through the AWS console, Terraform's next plan shows that it will revert the policy to the configuration. This is an example of which concept?

medium
  • ✓ A.Configuration drift and correction
  • B.Immutable infrastructure
  • C.Resource tagging
  • D.Imperative provisioning

Why A: This scenario describes configuration drift, where a manual change to an S3 bucket policy via the AWS console creates a difference between the actual state of the resource and the desired state defined in Terraform code. Terraform's next plan detects this drift and will revert the policy to match the configuration, demonstrating its correction mechanism. This is a core principle of declarative IaC tools like Terraform, which enforce the desired state and automatically remediate any out-of-band changes.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.