HashiCorp Terraform Associate (004) Question 93
Single answer4a Use and differentiate resource and data blocksYour team manages AWS infrastructure with Terraform. A shared security group named "web-shared-sg" already exists in the target VPC and is maintained by another team outside of your Terraform configuration. You need to launch a new EC2 instance and attach that existing security group without Terraform trying to create or replace it. Which Terraform approach best meets this requirement?
- A
Define the security group with a resource block and reference its id from the instance, because Terraform resources can represent both existing and new infrastructure automatically.
- B
Use a data block to look up the existing security group by name and VPC, then reference the data source attributes from the EC2 instance resource.
- C
Declare the EC2 instance itself as a data block so Terraform will only read the instance configuration and not attempt to create infrastructure.
- D
Store the security group ID in a local value instead of using either a resource or data block, because locals are intended for external infrastructure lookups.
Show answer and explanation
Correct answer: B
Explanation
This question tests the practical distinction between resource and data blocks. In Terraform, resource blocks define infrastructure Terraform should manage, while data blocks read existing infrastructure for use elsewhere in the configuration. In this scenario, the EC2 instance is new and should be created with a resource block, but the security group already exists and is maintained outside the configuration, so it should be referenced with a data source. This is a common real-world pattern when integrating with shared networking, IAM, or security components managed by another team. HashiCorp documentation describes resources as managed objects and data sources as read-only lookups of external or existing objects. Best practice is to use data sources when you need information about infrastructure not managed in the current state, and resource blocks when Terraform should control the lifecycle of the object.
- A. Incorrect.
Incorrect. A resource block tells Terraform to manage an object's lifecycle, including create, update, and destroy actions. If you define an existing security group as a resource without importing it into state, Terraform will treat it as something to create, which does not match the requirement. This reflects a common misconception that resource blocks can automatically adopt existing infrastructure without additional steps such as import.
- B. Correct.
Correct. A data block is used to query and read information about infrastructure that Terraform does not manage in the current configuration. Looking up the existing security group with a data source and passing its ID to the aws_instance resource is the appropriate pattern when another team owns that object and you only need to reference it.
- C. Incorrect.
Incorrect. Data blocks are for reading existing objects, not for declaring desired managed infrastructure. If you want Terraform to create the EC2 instance, it must be defined with a resource block. Using a data block for the instance would not create anything.
- D. Incorrect.
Incorrect. A local value can simplify expressions or store derived values, but it does not query provider APIs. You could place a looked-up ID into a local after retrieving it with a data source, but locals alone are not a substitute for a data block when discovering existing infrastructure.