Terraform Associate · 27% of the exam

Core Workflow and State Management: free practice questions

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

1. A team is migrating Terraform state from a local backend to a new GCS (Google Cloud Storage) backend. They update the `terraform` block with the new backend configuration and run `terraform init`. During init, Terraform detects an existing local state file. Which of the following accurately describes what happens next and what the team should be aware of? (Select THREE)

A. Terraform will prompt the user to copy the existing local state to the new GCS backend✓ Correct
B. If the user declines the copy prompt, the existing local state file is permanently deleted
C. After a successful state migration, the team should verify the state was copied correctly before deleting the local state file✓ Correct
D. The `terraform init -migrate-state` flag can be used to automatically migrate state without an interactive prompt✓ Correct
E. Terraform automatically backs up the local state to a `.terraform/` subdirectory before migration
F. After migration, the local `terraform.tfstate` file is left intact and Terraform will continue reading from it unless manually removed

Explanation

A is correct: `terraform init` detects the existing local state and interactively asks the user whether to copy it to the new backend. C is correct: best practice is to verify the migrated state (e.g., via `terraform state list`) before removing the local file, since the local file is not automatically deleted. D is correct: `-migrate-state` is a valid flag that triggers state migration non-interactively (useful in CI pipelines). Option B is wrong: declining the copy prompt does NOT delete the local state; it simply leaves it in place and initializes the new backend with an empty state. Option E is wrong: Terraform does not back up local state to `.terraform/`; it may create a `terraform.tfstate.backup` file in the working directory during apply operations, but not specifically for backend migration. Option F is wrong: after successful migration, Terraform uses the new backend exclusively; it does not continue reading from the local file.

2. Review the following resource configuration: ```hcl resource "aws_db_instance" "primary" { # ... other config ... lifecycle { ignore_changes = [engine_version] } } ``` An automated minor version upgrade changes the `engine_version` on the RDS instance in AWS. What happens on the next `terraform plan`?

A. Terraform plans to downgrade the engine version back to the value in the configuration
B. Terraform ignores the difference in `engine_version` and reports no changes for this attribute✓ Correct
C. Terraform destroys and recreates the RDS instance to restore the configured engine version
D. Terraform throws a validation error because `ignore_changes` cannot be used with `engine_version` on managed database resources

Explanation

`ignore_changes` tells Terraform to ignore differences for the listed attributes when computing a plan. Even if the live value of `engine_version` differs from the configuration, Terraform will not plan any changes for that attribute. This is useful for attributes managed by external automation (like AWS auto minor version upgrades). Option A is wrong: with `ignore_changes`, Terraform will not attempt to revert the attribute. Option C is wrong: Terraform will not destroy/recreate; it ignores the drift entirely for the specified attributes. Option D is wrong: `ignore_changes` is a general lifecycle mechanism with no restrictions on which attributes it can target.

3. A Terraform configuration creates an `aws_autoscaling_group` (ASG) and an `aws_launch_template`. The team wants to update the launch template without any downtime. They add `create_before_destroy = true` to the launch template. What does this lifecycle setting change about Terraform's behavior?

A. Terraform creates the new launch template resource before destroying the old one during a replacement operation✓ Correct
B. Terraform prevents the launch template from being destroyed under any circumstances
C. Terraform automatically triggers a rolling update of the ASG instances when the launch template changes
D. Terraform ignores changes to the launch template and only replaces it when `terraform taint` is used

Explanation

`create_before_destroy = true` changes the default destroy-then-create replacement order to create-then-destroy. For the launch template, Terraform will provision the new version of the resource before removing the old one, which allows the ASG to reference the new template before the old one is deleted, reducing downtime risks. Option B is wrong: that describes `prevent_destroy`, a different lifecycle meta-argument. Option C is wrong: `create_before_destroy` has no awareness of ASG rolling updates; managing instance refresh is done through separate ASG configuration or `aws_autoscaling_group` attributes like `instance_refresh`. Option D is wrong: that behavior aligns with `ignore_changes` or `lifecycle { prevent_destroy = true }`, not `create_before_destroy`.

4. 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.

5. 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).

63 more questions in this domain

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

Start practicing free