HashiCorp Terraform Associate (004) Question 118
Single answer4f Define resource dependencies in configurationA team is provisioning AWS infrastructure with Terraform. In one module, an EC2 instance is created and configured by a provisioner that runs a bootstrap script over SSH. The script downloads files from an S3 bucket that is also managed in the same Terraform configuration. However, the EC2 resource does not reference any attributes from the S3 bucket resource, so Terraform sometimes starts the instance provisioning before the bucket has been created, causing the bootstrap step to fail. What is the best way to ensure Terraform creates the S3 bucket before the EC2 instance provisioning begins?
- A
Add a depends_on meta-argument to the EC2 instance resource referencing the S3 bucket resource.
- B
Add a lifecycle block with create_before_destroy = true to the S3 bucket resource.
- C
Use terraform refresh before terraform apply so Terraform detects the correct creation order.
- D
Add the S3 bucket name as a variable in the EC2 resource so Terraform infers the dependency automatically.
Show answer and explanation
Correct answer: A
Explanation
Terraform determines resource order primarily through its dependency graph. The preferred approach is to rely on implicit dependencies created by referencing one resource's attributes from another whenever possible. When a dependency exists in real operation but is not represented by an expression in the configuration, Terraform provides the depends_on meta-argument to declare an explicit dependency. This is especially relevant for cases involving provisioners, external side effects, or resources that must exist before another resource can be safely created even though no attribute reference is present. According to Terraform best practices and HashiCorp documentation, depends_on should be used only when Terraform cannot infer the dependency automatically. In this scenario, because the EC2 provisioner depends on the bucket but there is no attribute reference, depends_on is the correct and most direct solution.
- A. Correct.
Correct. Terraform automatically builds implicit dependencies when one resource references another resource's attributes. In this scenario, the EC2 resource does not reference the bucket, but there is still a real operational dependency because the provisioner requires the bucket to exist first. The appropriate solution is to use the depends_on meta-argument to declare an explicit dependency so Terraform waits until the bucket resource is created before creating and provisioning the EC2 instance.
- B. Incorrect.
Incorrect. The lifecycle argument create_before_destroy controls replacement behavior for a resource that must be recreated, not creation order between otherwise unrelated resources during an initial apply. It does not tell Terraform that the EC2 instance depends on the S3 bucket.
- C. Incorrect.
Incorrect. terraform refresh updates Terraform state with information from existing infrastructure, but it does not define dependency relationships in configuration or change the graph Terraform uses for planning and applying resources. Running refresh would not reliably solve this ordering problem.
- D. Incorrect.
Incorrect. Supplying the bucket name as a plain variable does not create a dependency unless the value is derived from the bucket resource itself. If the variable is just a string, Terraform has no reason to infer that the EC2 instance depends on the bucket resource. This is a common misconception: dependencies come from resource references or explicit depends_on declarations, not from semantically related names.