HashiCorp Terraform Associate (004) Question 116
Single answer4f Define resource dependencies in configurationYour team provisions AWS infrastructure with Terraform. An application EC2 instance must not be created until a security group rule allowing HTTPS from the corporate CIDR has been added to the instance's security group. The current configuration creates the security group, the rule, and the instance in the same apply. However, the EC2 instance only references the security group ID, and Terraform sometimes plans the instance creation before the rule is applied. You want to enforce the required ordering while keeping the configuration maintainable. Which approach should you use?
- A
Add an explicit depends_on argument to the aws_instance resource that references the aws_security_group_rule resource.
- B
Add a local value that stores the security group rule ID and reference that local from the aws_instance resource.
- C
Use terraform refresh before every apply so Terraform detects that the security group rule must exist before the instance.
- D
Add depends_on to the provider "aws" block so all AWS resources are created in the correct order.
Show answer and explanation
Correct answer: A
Explanation
Terraform builds a dependency graph primarily from expression references. When resource A uses an attribute from resource B, Terraform infers that B must be created first. In this scenario, the aws_instance depends implicitly on the aws_security_group because it uses the security group ID, but it does not depend on aws_security_group_rule unless that rule is referenced directly. If there is a real operational requirement that the rule exist before instance creation, this is a hidden dependency and should be modeled with depends_on. HashiCorp documentation recommends relying on implicit dependencies when possible and using depends_on only when Terraform cannot infer the dependency from arguments. This keeps the graph accurate without introducing unnecessary coupling.
- A. Correct.
Correct. Terraform automatically infers dependencies when one resource argument references another resource's attributes. In this scenario, the instance references the security group, but not the security group rule, so Terraform has no implicit dependency on the rule. If the creation order must include the rule before the instance, an explicit depends_on on aws_instance referencing aws_security_group_rule is the appropriate solution. This is the intended use of depends_on for hidden or behavior-based dependencies that are not expressed through data flow.
- B. Incorrect.
Incorrect. A local value does not create a new dependency by itself beyond whatever expressions it contains. Referencing a local that contains the security group rule ID would be artificial and not a good design if the instance does not actually need that value as an input. Locals help with reuse and readability, but they are not a substitute for expressing ordering requirements that are not part of normal attribute flow.
- C. Incorrect.
Incorrect. terraform refresh updates state to match real infrastructure, but it does not define or enforce dependency ordering in the graph for a future apply. The issue here is not stale state; it is that Terraform has no explicit graph edge from the instance to the security group rule. Refreshing does not solve hidden dependency requirements.
- D. Incorrect.
Incorrect. Provider blocks do not support depends_on to control ordering of managed resources in this way. Resource dependency management is handled in resource, module, output, and some other block contexts where Terraform supports explicit dependencies. Attempting to control all AWS resource ordering through the provider would not be valid Terraform configuration.