HashiCorp Terraform Associate (004) Question 99
Single answer4b Refer to resource attributes and create cross-resource referencesYour team is provisioning AWS infrastructure with Terraform. A new EC2 instance must be launched into a subnet that Terraform creates in the same configuration. A teammate hard-coded the subnet ID in the instance resource, which caused failures when the subnet was recreated in another environment. You want Terraform to automatically use the ID of the subnet resource created in the same apply. Which configuration change is the best way to create this dependency and avoid hard-coded values?
- A
Set subnet_id = aws_subnet.app.id in the aws_instance resource.
- B
Set subnet_id = "${var.subnet_id}" and manually pass the subnet ID at apply time.
- C
Add depends_on = [aws_subnet.app] to the aws_instance resource, but keep the existing hard-coded subnet_id value.
- D
Set subnet_id = aws_subnet.app[0].arn in the aws_instance resource.
Show answer and explanation
Correct answer: A
Explanation
Terraform best practice is to use expressions that reference resource attributes, such as aws_subnet.app.id, when one resource depends on another resource's computed value. This creates an implicit dependency in Terraform's graph and avoids hard-coded identifiers that can differ across environments. In Terraform language documentation, resource attributes are referenced with the syntax
- A. Correct.
Correct. Referencing aws_subnet.app.id uses a resource attribute from another resource in the same configuration. This creates both the correct value flow and an implicit dependency, so Terraform knows it must create the subnet before creating the EC2 instance. This is the recommended way to build cross-resource references instead of hard-coding provider-assigned IDs.
- B. Incorrect.
Incorrect. Passing the subnet ID through a variable can work in some designs, but it does not solve this specific problem when the subnet is created by Terraform in the same configuration. It also pushes responsibility to the operator and reintroduces the risk of mismatched or stale IDs across environments. The better practice here is to reference the resource attribute directly.
- C. Incorrect.
Incorrect. depends_on only controls ordering; it does not replace the hard-coded subnet ID with the actual ID of the created subnet. The instance would still point to the wrong subnet value if the hard-coded ID is invalid for the environment. A common misconception is that depends_on is how you connect resources, but attribute references are the primary mechanism when one resource needs another resource's value.
- D. Incorrect.
Incorrect. subnet_id expects a subnet ID, not an ARN. Also, aws_subnet.app[0] would only be valid if the subnet resource were created with count or for_each in a way that supports indexed access. Even then, using arn would still be the wrong attribute for subnet_id.