HashiCorp Terraform Associate (004) Question 94
Single answer4a Use and differentiate resource and data blocksYour team manages shared networking in AWS outside of this Terraform configuration. A separate platform team has already created a VPC and tagged one subnet with Name = "shared-app-subnet". You need a new EC2 instance in that existing subnet, but your Terraform code must not attempt to create or take ownership of the existing VPC or subnet. Which configuration approach best meets this requirement?
- A
Define the VPC and subnet with resource blocks, then add lifecycle settings so Terraform does not modify them, and create the EC2 instance in those managed resources.
- B
Use data blocks to look up the existing VPC and subnet by tags or filters, then reference those data source attributes from a resource block that creates the EC2 instance.
- C
Use a data block for the EC2 instance and resource blocks for the VPC and subnet, because data blocks are intended only for compute objects that already exist.
- D
Import the existing VPC and subnet into the state automatically by referencing them from a resource block, then create the EC2 instance with no additional changes.
Show answer and explanation
Correct answer: B
Explanation
The key distinction is that resource blocks define infrastructure Terraform should create, update, and destroy, while data blocks allow Terraform to read attributes from existing infrastructure without managing it. In a real-world environment with shared networking owned by another team, the recommended approach is to use data sources such as aws_vpc or aws_subnet to discover the existing objects, then pass their IDs into a resource like aws_instance. This pattern avoids accidental ownership conflicts and keeps responsibilities separated across teams and configurations. HashiCorp documentation consistently describes resources as managed objects in configuration and data sources as a way to fetch or compute information for use elsewhere in the configuration.
- A. Incorrect.
Incorrect. Resource blocks declare infrastructure that Terraform manages. If you define the existing VPC and subnet as resources in this configuration, Terraform will treat them as managed objects and expect them to be in state. Adding lifecycle arguments such as ignore_changes does not change the ownership model; it only affects how changes are handled after an object is already managed. This does not satisfy the requirement to avoid creating or taking ownership of the existing network resources.
- B. Correct.
Correct. Data blocks are used to read information about infrastructure that already exists, whether created by Terraform elsewhere or outside Terraform entirely. In this scenario, the existing VPC and subnet should be queried with data sources, and the new EC2 instance should be declared with a resource block that references the looked-up IDs. This is the standard pattern when consuming shared infrastructure without managing it in the current configuration.
- C. Incorrect.
Incorrect. This reverses the correct usage. Data blocks are not limited to compute resources; they are generally used to query existing objects such as VPCs, subnets, AMIs, and many other provider objects. The EC2 instance that you want Terraform to create should be defined as a resource, while the pre-existing network components should be read with data blocks.
- D. Incorrect.
Incorrect. Merely writing a resource block that matches an existing object does not automatically import it into state. Importing existing infrastructure into Terraform state is a separate explicit action. Also, importing would make Terraform manage those objects in this configuration, which conflicts with the requirement not to take ownership of the existing VPC or subnet.