TF-004 Implement and maintain state Practice Question
Exhibit
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "WebServer"
}
}
# Remote state data source
data "terraform_remote_state" "network" {
backend = "s3"
config = {
bucket = "mycompany-terraform-state"
key = "network/terraform.tfstate"
region = "us-east-1"
}
}
resource "aws_security_group" "web_sg" {
name_prefix = "web-sg-"
vpc_id = data.terraform_remote_state.network.outputs.vpc_id
}Refer to the exhibit. A developer updates the network state and runs terraform apply. The aws_instance.web is not recreated. Which statement explains this behavior?
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 instance resource does not reference the remote state data source, so changes to the remote state do not trigger recreation.
The data source data.terraform_remote_state.network is read during planning and is not stored in state. If the remote state changes, Terraform will see the new vpc_id and may update the security group, but the instance resource does not depend on the remote state, so it is not affected.
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 instance resource does not reference the remote state data source, so changes to the remote state do not trigger recreation.
Why this is correct
The instance resource's configuration arguments did not change as a direct result of the remote state update because it does not explicitly reference any outputs from the `terraform_remote_state` data source. Terraform's core principle for resource recreation is based on detecting a diff in the resource's *own* defined arguments or its direct dependencies. Since the instance resource's definition remained stable and independent of the remote state, it was not marked for recreation, even if other resources that *did* depend on the remote state were updated.
- ✗
Terraform automatically locks the remote state to prevent changes during apply.
Why it's wrong here
Terraform state locking is indeed an automatic mechanism, but its primary purpose is to prevent concurrent *write* operations to the remote state file, which could lead to corruption or data loss. It ensures only one `terraform apply` or `terraform plan -out` operation can modify the state at a time. However, state locking does not prevent other independent Terraform operations from updating the remote state, nor does it prevent a running Terraform process from *reading* the most current state, which is what a `terraform_remote_state` data source does.
- ✗
The security group resource depends on the remote state, and it was updated, but the instance was not affected.
Why it's wrong here
While it is plausible that the security group resource was updated due to a change in the remote state, and the instance might have an implicit dependency on that security group, the instance itself was not recreated. Terraform only recreates an instance when its *own* configuration arguments, such as its AMI, instance type, or explicit security group *ID reference*, are modified. An update to a referenced security group's *rules* typically triggers an in-place update of the security group, not a recreation of the dependent instance, unless the security group *ID* itself changes and forces a new association.
- ✗
The remote state data source is cached and only refreshes every hour.
Why it's wrong here
The `terraform_remote_state` data source is not cached for an hour; instead, it is refreshed dynamically during each `terraform plan` or `terraform apply` operation. When Terraform executes, it queries the specified remote backend to fetch the latest state file, ensuring that any outputs consumed from that remote state are current and accurate for the current run. This real-time refresh ensures that the dependency graph and planned changes are based on the most up-to-date information available.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-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 →
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.