Terraform Associate Use and Apply the Terraform Workflow: 49 practice questions

12 of the 49 Use and Apply the Terraform Workflow questions in the Certsqill Terraform Associate bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Terraform Associate? Take the free 5-min readiness check →

1. Write -> Init -> Plan -> Apply: What is the correct order of the core Terraform workflow for provisioning new

1. Write (define config) -> Init (initialize) -> Plan (preview changes) -> Apply (execute changes) ✓

   Correct. The Terraform workflow is: write .tf files, run terraform init to initialize backend and providers, run terraform plan to preview, then terraform apply to execute changes.
2. Init (initialize) -> Write (define config) -> Apply (execute changes) -> Plan (preview changes)

   Incorrect. Configuration must be written before init, and plan always precedes apply. The correct order is Write, Init, Plan, Apply.
3. Write (define config) -> Apply (execute changes) -> Plan (preview changes) -> Init (initialize)

   Incorrect. Apply must always be preceded by a plan to review changes, and init must run before either plan or apply.
4. Plan (preview changes) -> Write (define config) -> Init (initialize) -> Apply (execute changes)

   Incorrect. Planning requires an initialized directory with written configuration; you cannot plan before writing config and running init.

Terraform's core workflow: Write config → terraform init → terraform plan (review) → terraform apply (execute). Plan before apply, always.

2. -auto-approve: Which flag allows apply to proceed without manual confirmation?

1. -skip-confirm

   Incorrect. `-skip-confirm` is not a real Terraform flag. The confirmation prompt is bypassed with `-auto-approve`.
2. -auto-approve ✓

   Correct. `terraform apply -auto-approve` skips the confirmation prompt and applies changes immediately, which is required for unattended CI/CD automation.
3. -force-approve

   Incorrect. There is no `-force-approve` flag; the old `-force` option was removed. Approval is skipped with `-auto-approve`.
4. -yes-approve

   Incorrect. `-yes-approve` is not a valid flag. Terraform uses `-auto-approve` to answer the apply prompt automatically.

terraform apply -auto-approve skips the 'yes' confirmation prompt — necessary for CI/CD pipelines that run unattended.

3. terraform destroy: Which command destroys all resources in the current state?

1. terraform apply -destroy-all (removes every tracked resource)

   Incorrect. The flag is `-destroy`, not `-destroy-all`. Use `terraform apply -destroy` or simply `terraform destroy` to remove all resources.
2. terraform state rm '*' (clears the entire resource state)

   Incorrect. `terraform state rm` only stops tracking resources in state and leaves the real infrastructure running. Use `terraform destroy` to actually delete resources.
3. terraform destroy (equivalent to terraform apply -destroy) ✓

   Correct. terraform destroy removes all resources tracked in state. It is equivalent to terraform apply -destroy; both generate a plan to destroy every resource and prompt for confirmation.
4. terraform teardown (destroys all managed infrastructure)

   Incorrect. There is no `terraform teardown` command. The command that destroys all managed infrastructure is `terraform destroy`.

terraform destroy removes all infrastructure tracked in state — equivalent to terraform apply -destroy, with a confirmation prompt before executing.

4. Use `terraform init -backend-config="bucket=my-bucket-name: How can the backend bucket name be provided at ini

1. Set the bucket name in terraform.tfvars and let Terraform read it into the backend block during backend initialization

   Incorrect. terraform.tfvars supplies values for input variables and is never read for backend configuration. Backend settings come from literal values or -backend-config.
2. Declare `variable "bucket"` and reference it in the backend block as `bucket = var.bucket` so it resolves at plan

   Incorrect. Backend blocks cannot reference Terraform variables; they must use literal values or -backend-config. Variable interpolation is not allowed in a backend block.
3. Export `TF_BACKEND_BUCKET=my-bucket-name` and Terraform maps that environment variable into the S3 backend config

   Incorrect. There is no `TF_BACKEND_BUCKET` environment variable. The bucket name is provided through a -backend-config flag or a separate backend config file.
4. Use `terraform init -backend-config="bucket=my-bucket-name"` to provide backend configuration at initialization time ✓

   Correct. Partial backend configuration lets you leave environment-specific settings out of the .tf file and supply them via -backend-config flags or a separate config file during init.

Partial backend configuration allows leaving values out of .tf files and providing them via `terraform init -backend-config=key=value` — variables cannot be used in backend blocks.

5. The resource will be destroyed and recreated due: What does this indicate?

1. The resource will be destroyed and recreated (replaced) due to a change to an immutable attribute ✓

   Correct. `-/+` in plan output means the resource requires replacement, so Terraform destroys the existing resource and creates a new one. The `~` symbol means an in-place update.
2. The resource will be updated in place with no downtime because only mutable attributes changed on it

   Incorrect. In-place updates are shown with `~`. The `-/+` symbol specifically indicates a destroy-and-recreate replacement, not a mutable-only update.
3. The resource is currently tainted and Terraform will simply clear the taint on the next apply

   Incorrect. Clearing a taint would remove the tainted marker, not show `-/+`. The `-/+` symbol always denotes a resource replacement operation.
4. The resource will be imported from pre-existing infrastructure into state without any changes

   Incorrect. Import operations do not appear as `-/+` in a plan. The `-/+` marker means Terraform will replace the resource, not import it.

Plan symbols: `+` = create, `-` = destroy, `~` = in-place update, `-/+` = replace (destroy + create), `<=` = data source read.

6. Use version control: What is the recommended workflow to prevent conflicts and ensure changes are reviewed?

1. Designate a single engineer to make every Terraform change so that concurrent edits and state-file conflicts simply cannot occur in practice

   Incorrect. A single-person bottleneck creates operational risk and does not scale. Remote state with locking is the technical solution that safely enables parallel work.
2. Use version control (Git), require pull request reviews before merging, and use remote state with locking (Terraform Cloud or S3+DynamoDB) ✓

   Correct. A VCS-based workflow ensures changes are peer-reviewed before applying, and remote state with locking prevents concurrent apply conflicts. This is the recommended team workflow.
3. Store the shared state file on a network drive and coordinate who is allowed to apply changes through email threads and a booking calendar

   Incorrect. Network drives provide no state locking, so concurrent access corrupts state, and manual email coordination has no enforcement or audit trail.
4. Give every engineer the same AWS credentials and let each of them run terraform apply directly from their own local workstation

   Incorrect. Without state locking or VCS review, concurrent local applies can corrupt state, and shared credentials leave no record of who made each change.

Team Terraform workflow: Git + PR reviews for code changes + remote state with locking for safe concurrent operations — this is the standard collaborative pattern.

7. The saved plan guarantees that exactly the reviewed: Why is `terraform apply tfplan` (applying a saved plan fi

1. Saved plan files execute roughly ten times faster because provider schemas and all network calls are fully pre-cached during the plan phase

   Incorrect. Saved plans do not meaningfully change execution speed; performance is not the reason to prefer them. Reproducibility is the actual benefit.
2. Saved plan files can be restored after a failed apply, giving the pipeline an automatic rollback path back to the previously known-good state

   Incorrect. Terraform provides no automatic rollback from a saved plan. A plan is a forward-looking change set, not a mechanism for reverting state.
3. The saved plan guarantees that exactly the reviewed changes are applied, with no risk of configuration drift between the plan and apply steps ✓

   Correct. With a saved plan, what was reviewed is exactly what gets applied, eliminating any chance that the configuration changed between the plan and apply steps in a pipeline.
4. Interactive apply is explicitly prohibited in production environments under the terms of HashiCorp's commercial licensing subscription agreement

   Incorrect. No licensing rule restricts interactive apply. Preferring saved plans is an architectural best practice, not a licensing requirement.

Saved plan files create a deterministic apply — the reviewed plan is exactly what gets executed, preventing any drift if config changes occur between plan and apply pipeline steps.

8. After adding a new provider or module source: When must they run `terraform init` again?

1. Only once ever, since after the first successful initialization no further init is needed

   Incorrect. init must be re-run whenever providers, modules, or backend configuration change; it is not a one-time-only operation.
2. After every git commit to the Terraform repository, to keep providers synced

   Incorrect. Git commits do not require re-initializing. Only changes to provider or module requirements or backend config trigger the need to run init again.
3. Before every terraform plan, to ensure provider plugins are freshly downloaded

   Incorrect. Running init before every plan is unnecessary overhead. init is only needed when providers, modules, or backend configuration change.
4. After adding a new provider or module source, or changing the backend configuration ✓

   Correct. terraform init must be re-run whenever new providers or modules are added or the backend configuration changes, because init downloads and configures those components.

Re-run terraform init when you add new providers or modules, change provider versions, or modify backend configuration — not needed for every plan/apply cycle.

9. terraform fmt -check: Which `terraform fmt` command achieves this?

1. terraform fmt -list=true — reports the files that need formatting to stdout but still rewrites them in place

   Incorrect. `-list=true` is the default behavior and shows files that would be formatted — but this does NOT make `fmt` non-modifying. Without `-check`, `terraform fmt` still modifies files.
2. terraform fmt -dry-run — prints all the proposed formatting changes as a preview without ever applying them to the files

   Incorrect. There is no `-dry-run` flag for `terraform fmt`. The correct non-modifying check flag is `-check`.
3. terraform fmt -check — exits with a non-zero code if formatting changes would be needed, without modifying files ✓

   Correct. `terraform fmt -check` scans all .tf files and exits with code 3 if any file would be reformatted, or code 0 if all files are already correctly formatted. It does not modify files, making it ideal for CI format gate checks.
4. terraform validate — checks configuration syntax and, in the same pass, verifies canonical formatting compliance too

   Incorrect. `terraform validate` checks HCL syntax and configuration validity — it does NOT check or enforce formatting style. Formatting is exclusively the domain of `terraform fmt`.

`terraform fmt -check` is a non-destructive format check — it exits non-zero if any file needs reformatting, without modifying any files. Perfect for CI gates.

10. Run `terraform plan -out=tfplan` to save the plan: How can they guarantee this?

1. Run `terraform plan` twice in a row and confirm that both of the printed outputs are byte-for-byte identical to each other before allowing the pipeline to proceed on to the apply step at all

   Incorrect. Running plan twice doesn't guarantee the apply will match either plan. Apply always generates a new plan unless given a saved plan file. The `-out` flag is the correct approach.
2. Run `terraform apply -auto-approve` immediately after `terraform plan` within the very same pipeline step, relying on the short time gap to keep the freshly generated plan accurate enough

   Incorrect. `terraform apply -auto-approve` without a plan file generates a NEW plan and applies it. Even running it immediately after terraform plan, a separate apply generates a fresh plan that might differ if infrastructure changed between the two commands.
3. Use `terraform apply -refresh=false` so that Terraform skips its state refresh and therefore cannot detect any new drift that may have appeared after the plan was originally reviewed

   Incorrect. `-refresh=false` skips state refresh but still generates a new plan. It doesn't apply the previously reviewed plan — it generates a new plan without refreshing, which may miss or introduce differences.
4. Run `terraform plan -out=tfplan` to save the plan, review the saved plan, then run `terraform apply tfplan` — applying that exact saved plan rather than generating a brand-new plan instead ✓

   Correct. `terraform plan -out=tfplan` saves the execution plan to a binary file. `terraform apply tfplan` applies exactly that saved plan without generating a new plan. This ensures the apply matches precisely what was reviewed, with no drift if infrastructure changed between plan and apply.

`terraform plan -out=tfplan` saves the plan; `terraform apply tfplan` applies exactly that saved plan — ensuring the apply matches the reviewed plan with no re-planning.

11. terraform plan -destroy: Which command shows the destroy plan without executing it?

1. terraform plan -destroy — shows the destruction plan without performing any deletions ✓

   Correct. `terraform plan -destroy` generates and displays the destroy plan (what would be deleted, in what order) without executing any deletions. It is equivalent to running `terraform destroy` but stopping before the apply phase.
2. terraform validate -destroy — checks whether the configuration can be safely destroyed

   Incorrect. `terraform validate` checks HCL syntax and configuration validity — there is no `-destroy` flag, and it cannot generate a destroy plan.
3. terraform destroy -dry-run — shows what would be destroyed without executing deletions

   Incorrect. There is no `-dry-run` flag for `terraform destroy`. The correct approach to preview a destroy is `terraform plan -destroy`.
4. terraform show -destroy — displays the current state formatted as a destroy plan

   Incorrect. `terraform show` displays the current state or a saved plan file — there is no `-destroy` flag. It doesn't show a destruction plan.

`terraform plan -destroy` generates and displays a complete destroy plan showing all resources that would be deleted, without executing any deletions.

12. Run `terraform apply -replace="aws_instance.web"` to force: Which is the CURRENT recommended approach?

1. Run `terraform taint aws_instance.web` then `terraform apply` to force recreation

   Incorrect. `terraform taint` is deprecated as of Terraform 0.15.2 — the recommended approach is `terraform apply -replace`. While taint still works in current versions, it is not the CURRENT recommended approach.
2. Run `terraform apply -replace="aws_instance.web"` to force replacement of that specific resource ✓

   Correct. `terraform apply -replace=<resource_address>` marks a specific resource for destruction and recreation in the current apply operation. This is the modern replacement for `terraform taint` (deprecated in Terraform 0.15.2+). It's more direct — no separate taint step needed.
3. Add `lifecycle { recreate = true }` to the resource block and run `terraform apply`

   Incorrect. There is no `recreate` argument in the `lifecycle` block. The lifecycle block supports `create_before_destroy`, `prevent_destroy`, `ignore_changes`, and `replace_triggered_by` — not a `recreate` flag.
4. Manually delete the EC2 instance in the AWS Console and then run `terraform apply` to recreate it

   Incorrect. Manual deletion causes state drift — Terraform's state still shows the instance as existing. While `terraform apply` would then recreate it, this approach is error-prone and not the clean Terraform-native way.

`terraform apply -replace=<address>` is the modern approach to force resource replacement — it supersedes the deprecated `terraform taint` command.

Other Terraform Associate domains

• Understand Terraform Basics — 197 questions →
• Implement and Maintain State — 77 questions →
• Interact with Terraform Modules — 50 questions →
• Understand Infrastructure as Code (IaC) Concepts — 45 questions →
• Understand Terraform's Purpose (vs Other IaC) — 40 questions →
• All 495 Terraform Associate questions →