Courseiva
Interact with Terraform modulesmediumDrag & DropObjective-mapped

TF-004 Interact with Terraform modules Practice Question

Drag and drop the steps to manage Terraform state locking with a backend in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Configure backend with locking, then run terraform init, then run terraform apply, then run terraform destroy.

Backend config must include locking mechanism; init sets up backend, apply uses lock.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Configure backend with locking, then run terraform init, then run terraform apply, then run terraform destroy.

    Why this is correct

    This is the correct order because the backend must be configured with a locking mechanism first, then initialized with terraform init to set up the backend, then terraform apply acquires the lock during infrastructure creation, and terraform destroy acquires the lock during teardown, ensuring no concurrent state modifications.

  • Run terraform init, then configure backend with locking, then run terraform apply, then run terraform destroy.

    Why it's wrong here

    Running "terraform init" prematurely, before the backend configuration with locking is defined in the HCL, will cause Terraform to initialize with a local state backend by default. This means the critical locking mechanism is completely absent from the initialized working directory. Subsequent backend configuration, even if added to the HCL, requires another "terraform init -reconfigure" to be recognized and applied, making the initial "init" ineffective for state locking.

  • Configure backend with locking, then run terraform apply, then run terraform init, then run terraform destroy.

    Why it's wrong here

    Executing "terraform apply" prior to "terraform init" will invariably result in an error because the Terraform working directory has not been properly prepared. "terraform init" is responsible for downloading necessary providers, configuring the remote backend, and setting up the local ".terraform" directory. Without this foundational initialization, "apply" cannot locate providers, manage state, or engage any backend-specific features like state locking, rendering the command inoperable.

  • Run terraform apply, then configure backend with locking, then run terraform init, then run terraform destroy.

    Why it's wrong here

    Attempting to run "terraform apply" as the very first step is fundamentally incorrect because Terraform requires a configured and initialized environment to operate. Without any backend configuration defined in the HCL and subsequently initialized via "terraform init", "apply" has no remote state to interact with, no providers to use, and no locking mechanism to enforce. This sequence would lead to immediate errors, preventing any infrastructure changes and completely bypassing state management and locking.

About these practice questions

One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.