Terraform Associate · 13% of the exam

Core Terraform workflow: free practice questions

5 sample questions from our 6-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real HashiCorp exam.

1. A Terraform engineer is troubleshooting a situation where two resources have a dependency that cannot be expressed through attribute references. The configuration manages an AWS Lambda function and an S3 bucket policy. The Lambda reads from the bucket, but the bucket policy ARN is not directly referenced in the Lambda configuration. The engineer adds `depends_on` to the Lambda resource pointing to the bucket policy. What is a known side effect of using `depends_on` on a resource (as opposed to expressing the dependency through a reference)?

  • A. Terraform will validate that the `depends_on` target exists in the real infrastructure before proceeding with the plan.
  • B. Any `output` value that references the resource with `depends_on` will also inherit the dependency, potentially causing outputs to be unknown during planning.
  • C. Terraform will replace the resource with `depends_on` on every plan, regardless of whether any attributes changed.
  • D. When `depends_on` is used on a resource, Terraform treats all attributes of that resource as unknown during planning if the dependency has any pending changes, which can cause a more conservative and less informative plan.✓ Correct
Explanation

Option D is correct. When `depends_on` is applied to a resource (or module), Terraform cannot use its normal fine-grained dependency analysis. If the `depends_on` target has any pending changes, Terraform must treat the dependent resource's attributes as unknown during planning — because any side effect could theoretically change what values are produced. This results in a less informative plan where values show as `(known after apply)` even when they could otherwise be known. Option A is wrong — `depends_on` is purely a planning-time directive; Terraform does not pre-validate the existence of the target in real infrastructure. Option B is partially related but is specifically a behavior of `depends_on` on *modules*, not resources, and the mechanism described is not quite accurate. Option C is wrong — `depends_on` does not cause unconditional replacement; it only affects ordering and planning granularity.

2. A team's Terraform configuration has the following two resources. The `aws_security_group` is referenced by the `aws_instance` via its ID attribute: ```hcl resource "aws_security_group" "web" { ... } resource "aws_instance" "web" { security_groups = [aws_security_group.web.id] ... } ``` A senior engineer suggests also adding an explicit `depends_on = [aws_security_group.web]` to the `aws_instance`. What is the impact of adding this explicit dependency?

  • A. It is required because attribute references alone do not create ordering dependencies in Terraform
  • B. It is redundant because Terraform already infers the dependency from the attribute reference; adding `depends_on` has no functional effect but may cause Terraform to be more conservative in planning✓ Correct
  • C. It causes Terraform to destroy and recreate both resources on the next apply, because `depends_on` triggers replacement
  • D. It prevents Terraform from applying both resources in parallel, which will significantly slow down the deployment
Explanation

Option B is correct: attribute references (e.g., `aws_security_group.web.id`) implicitly create dependency ordering in Terraform's graph. Adding `depends_on` on top of an already-implied dependency is redundant. However, Terraform's documentation notes that `depends_on` can cause Terraform to be more conservative—when `depends_on` is present, Terraform may replace resources more aggressively if the dependency changes, which is why it is recommended to use `depends_on` only when necessary. Option A is incorrect: attribute references do create implicit ordering. Option C is incorrect: `depends_on` does not trigger replacement; it only affects ordering. Option D is a partial truth—Terraform does serialize work when dependencies exist, but adding an already-implied `depends_on` does not newly prevent parallelism that was not already prevented by the reference.

3. A senior engineer is reviewing a Terraform configuration and notices the following: ```hcl resource "aws_security_group" "allow_http" { name = "allow-http" } resource "aws_instance" "app" { ami = "ami-12345678" instance_type = "t3.small" security_groups = [aws_security_group.allow_http.name] } ``` A junior engineer suggests adding `depends_on = [aws_security_group.allow_http]` to the `aws_instance` resource for clarity. What is the correct assessment?

  • A. Adding `depends_on` is required; Terraform does not automatically infer dependencies from attribute references.
  • B. Adding `depends_on` is unnecessary because Terraform already infers an implicit dependency from the `aws_security_group.allow_http.name` reference in the `security_groups` argument.✓ Correct
  • C. Adding `depends_on` would cause a circular dependency error.
  • D. Adding `depends_on` is best practice for all resources to make the dependency graph explicit and improve plan performance.
Explanation

Option B is correct. Terraform automatically builds an implicit dependency graph from attribute references in the configuration. Because `aws_instance.app` references `aws_security_group.allow_http.name`, Terraform already knows to create the security group first. Adding `depends_on` is redundant in this case. Option A is wrong — Terraform *does* automatically infer dependencies from references; `depends_on` is reserved for cases where a dependency cannot be expressed through a reference (e.g., a hidden side effect). Option C is wrong — adding a non-circular `depends_on` does not cause errors. Option D is wrong — adding redundant `depends_on` is not a best practice; it can actually have negative side effects (such as causing unnecessary resource replacements when modules are involved).

4. Review the following Terraform configuration: ```hcl resource "aws_iam_role" "deployer" { name = "deployer-role" } resource "aws_iam_role_policy_attachment" "attach" { role = aws_iam_role.deployer.name policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess" } ``` There is NO explicit `depends_on` between these resources. How does Terraform determine the correct creation order?

  • A. Terraform creates resources in the order they appear in the configuration file
  • B. Terraform infers a dependency because `aws_iam_role_policy_attachment.attach` references an attribute (`aws_iam_role.deployer.name`) of the IAM role, creating an implicit dependency✓ Correct
  • C. Terraform creates both resources in parallel since there is no `depends_on` specified
  • D. Terraform requires `depends_on` to be set whenever two resources share the same AWS service; without it, the behavior is undefined
Explanation

Option B is correct. Terraform builds a dependency graph by analyzing resource attribute references in the configuration. Because `aws_iam_role_policy_attachment.attach` uses `aws_iam_role.deployer.name` (an interpolation reference), Terraform automatically understands that the IAM role must be created first. This is called an implicit dependency. Option A is incorrect — Terraform does NOT execute resources based on file order; it uses the dependency graph, which may result in parallel execution or a different order than written. Option C is incorrect — while Terraform does parallelize independent resources, these two are NOT independent; the reference creates a dependency that Terraform respects. Option D is incorrect — `depends_on` is only needed for hidden dependencies that Terraform cannot detect through attribute references (e.g., when a resource depends on a side effect of another resource that is not expressed as an attribute reference).

5. A Terraform configuration defines an `aws_security_group` and an `aws_instance` that references the security group. No explicit `depends_on` is set. How does Terraform determine the correct creation order?

  • A. Terraform always creates resources in the order they appear in the .tf files, top to bottom
  • B. Terraform infers an implicit dependency from the reference `aws_security_group.example.id` in the instance block, and creates the security group first✓ Correct
  • C. Terraform creates all resources in parallel by default; the engineer must add `depends_on` to enforce ordering
  • D. The engineer must use `terraform graph` to manually specify the dependency before running `terraform apply`
Explanation

When a resource attribute references another resource (e.g., `security_groups = [aws_security_group.example.id]`), Terraform automatically creates an implicit dependency. It builds a dependency graph and ensures the security group is created before the instance. Option A is wrong: Terraform does not use file order for sequencing; it uses the dependency graph. Option C is wrong: Terraform does create independent resources in parallel, but it correctly sequences resources that reference each other — `depends_on` is only needed for hidden dependencies that cannot be expressed through references. Option D is wrong: `terraform graph` is a read-only visualization tool; it does not configure dependencies.

1 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free