Free Terraform Associate (004) Practice Questions: Core Terraform Workflow

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official HashiCorp questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

Topic: Core Terraform Workflow

A teammate ran Terraform locally and shared this output for review:

$ terraform plan -out=prod.tfplan
Plan: 0 to add, 1 to change, 0 to destroy.

Saved the plan to: prod.tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "prod.tfplan"

The team approved this exact change set. What is the best next step to ensure Terraform executes only the reviewed changes?

Options:

• A. Run terraform plan -out=prod.tfplan again, then apply

• B. Run terraform init again before applying

• C. Run terraform apply prod.tfplan

• D. Run terraform apply

Best answer: C

Explanation: A saved plan file is used when the team wants the exact reviewed Terraform actions applied. Running terraform apply with that plan file applies the non-speculative plan directly instead of generating a fresh plan first.

The key concept is the difference between applying a saved plan and letting Terraform recalculate a new one. terraform plan -out=prod.tfplan creates a saved plan file that captures the reviewed set of actions. If the approval was for that exact change set, the correct next step is to run terraform apply prod.tfplan.

Running terraform apply without a plan file tells Terraform to create a new execution plan first, which could differ if configuration, input values, or infrastructure changed since review. Re-running plan also creates a new artifact to review rather than using the approved one. The safest way to execute exactly what was reviewed is to apply the saved plan file.

• Fresh recalculation Running terraform apply alone creates a new plan, so it does not guarantee the reviewed actions are the ones executed.
• New approval artifact Running terraform plan -out=prod.tfplan again recalculates the plan instead of using the already approved one.
• Wrong workflow step Running terraform init prepares the working directory and providers, but it does not preserve or execute the reviewed change set.

Question 2

Topic: Core Terraform Workflow

A teammate saved this Terraform plan and now wants to run terraform apply tfplan.

$ terraform plan -out=tfplan

Terraform will perform the following actions:

  # local_file.notice will be created
  + resource "local_file" "notice" {
      + content  = "ready"
      + filename = "notice.txt"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

What is the best interpretation of terraform apply tfplan?

Options:

• A. Reinitialize providers and the backend before using the saved plan.

• B. Record the planned add in state, but wait to create the file later.

• C. Recalculate the plan only, without changing infrastructure or state.

• D. Create local_file.notice and record the resulting state for later runs.

Best answer: D

Explanation: A saved plan describes intended changes, but it does not modify infrastructure by itself. When terraform apply tfplan runs, Terraform performs those approved changes and then records the resulting state so later runs know what now exists.

The core workflow point is that terraform apply is the step that actually changes infrastructure. In this example, the saved plan says one local_file resource will be added, so applying tfplan creates that resource and then updates Terraform state with the result. That state is what future plan and apply operations use to compare configuration, known resources, and any later drift.

• terraform init prepares the working directory.
• terraform plan -out=tfplan previews and saves the proposed actions.
• terraform apply tfplan executes that approved plan and records the resulting state.

The closest misconception is treating the saved plan as if it already changed state, but state reflects what was actually applied, not just what was proposed.

• Plan vs. state The option claiming Terraform writes the planned add to state first is wrong because proposed changes are not recorded as real state until apply completes.
• Plan-only behavior The option saying Terraform only recalculates a diff describes planning behavior, not the apply step.
• Initialization step The option focused on provider and backend setup describes terraform init, which is a separate command.

Question 3

Topic: Core Terraform Workflow

A team stores Terraform code in Git and uses pull requests for review. An engineer updated a root module and several local child modules, and the code should be normalized to a consistent style across all directories before review. The team will check configuration correctness separately. What is the best next action?

Options:

• A. Run terraform validate

• B. Enable HCP Terraform speculative plans

• C. Run terraform fmt -recursive

• D. Run terraform plan

Best answer: C

Explanation: The goal is code style normalization, not correctness checking. terraform fmt -recursive standardizes Terraform file formatting across the root module and child module directories, which supports consistent pull request review.

Terraform separates formatting from validation. terraform fmt is used to rewrite configuration files into Terraform’s canonical style, such as spacing and indentation. Adding -recursive applies that formatting through the directory tree, which is useful when a change touched multiple local modules.

terraform validate checks whether a configuration is syntactically valid and internally consistent, but it does not normalize style. terraform plan compares configuration with state and proposed infrastructure changes, which is a later workflow step. HCP Terraform speculative plans help with collaborative review of proposed changes, but they do not reformat source files. The key distinction is that formatting makes code consistent, while validation checks correctness.

• Validation vs. style: terraform validate checks correctness, not code formatting.
• Wrong workflow stage: terraform plan is for reviewing proposed infrastructure changes, not normalizing HCL style.
• Remote review feature: speculative plans support collaboration, but they do not rewrite files into standard format.

Question 4

Topic: Core Terraform Workflow

Your team reuses the same Terraform configuration in dev and prod, stores state in a remote backend, and relies on the lock file for version consistency. A teammate changed the backend settings and updated a child module source. When you run terraform plan to review the change before apply, you see:

Error: Backend initialization required
Error: Module not installed

What is the best next step?

Options:

• A. Run terraform validate

• B. Run terraform init -upgrade

• C. Run terraform init

• D. Create a new HCP Terraform workspace

Best answer: C

Explanation: When Terraform reports that backend settings, modules, or providers are not initialized, the next workflow step is to rerun terraform init. That prepares the working directory so terraform plan can safely continue while preserving the current version selections from the lock file.

terraform init is the initialization step for a Terraform working directory. If Terraform reports that the backend must be initialized or a module is not installed, you must rerun terraform init before plan or apply can work correctly.

In this scenario, the team cares about remote state safety and version consistency across environments. Plain terraform init is the safest default because it configures the backend and installs required modules and providers while honoring the dependency lock file. After initialization completes, the next normal step is terraform plan for change review.

The closest distractor is using -upgrade, but that can change selected dependency versions when simple reinitialization is all that is required.

• Unneeded upgrade adds version changes that can reduce cross-environment consistency when the issue is only missing initialization.
• Syntax check only verifies configuration validity, but it does not install modules or initialize the backend.
• Wrong workflow shift changes execution location and collaboration model without fixing the uninitialized local directory.

Question 5

Topic: Core Terraform Workflow

A cloud engineer already ran terraform init in this working directory last week, when the network module used source = "./modules/network". Today they changed it to the following:

module "network" {
  source  = "hashicorp/consul/aws"
  version = "0.11.0"
}

What is the best next step before running terraform plan?

Options:

• A. Run terraform apply because init was already completed.

• B. Run terraform init to reinitialize module dependencies.

• C. Run terraform validate to reload the module source.

• D. Run terraform plan to install the new module automatically.

Best answer: B

Explanation: terraform init is required not only for a brand-new working directory, but also when module, provider, or backend dependencies change materially. Changing a module source from a local path to a registry source means Terraform must download and configure that dependency again before planning.

terraform init prepares a working directory by installing modules, installing providers, and configuring backend settings. Terraform stores that initialization context in the working directory, so a material dependency change means you should run initialization again.

In this scenario, the module source changed from a local path to a registry module, which is an init-sensitive change. Re-running terraform init lets Terraform download the new module into the working directory before terraform plan evaluates the configuration.

Common times to rerun terraform init include:

• first use of a working directory
• provider dependency changes
• backend configuration changes
• module source changes

The key distinction is that validation and planning use an already initialized directory; they do not replace initialization.

• Validate first fails because terraform validate checks configuration correctness but does not install a newly referenced module source.
• Plan installs modules fails because terraform plan expects initialization to have already prepared required dependencies.
• Init only once fails because initialization must be repeated after material backend, provider, or module changes.

Question 6

Topic: Core Terraform Workflow

Which statement best describes terraform destroy?

Options:

• A. It rolls back only the most recent terraform apply.

• B. It deletes the state file but leaves infrastructure unchanged.

• C. It refreshes state to match manually changed infrastructure.

• D. It plans and removes Terraform-managed infrastructure in the current state.

Best answer: D

Explanation: terraform destroy is an intentional lifecycle action for tearing down Terraform-managed resources. Because it can remove active infrastructure, its plan should be reviewed carefully before confirmation.

The core concept is that terraform destroy is used to intentionally deprovision infrastructure managed by Terraform. Terraform compares the current state with the configuration context and produces a destroy plan showing which tracked resources will be deleted; after approval, it performs those deletions. That is why destroy is treated as a high-impact workflow step and should be reviewed carefully, especially in environments with live resources.

It does not merely edit metadata or undo a single prior run. It targets the resources Terraform is managing in the current working context and state, making it different from commands that format files, validate configuration, refresh information, or manipulate state only.

A common confusion is mixing destroy with state-only operations, but destroy affects real infrastructure.

• State-only confusion: The option about deleting state without touching infrastructure describes a state-management action, not destroy behavior.
• Refresh confusion: The option about updating state to reflect manual changes matches refresh-style behavior, not resource deletion.
• Rollback misconception: The option about reversing only the last apply is incorrect because Terraform does not provide a simple last-change rollback command.

Question 7

Topic: Core Terraform Workflow

After the working directory has already been initialized, which Terraform command is intended to catch configuration errors early in local development or CI before you create an execution plan?

Options:

• A. terraform fmt

• B. terraform init

• C. terraform plan

• D. terraform validate

Best answer: D

Explanation: terraform validate is the dedicated early check for Terraform configuration correctness. It verifies syntax and internal consistency in an initialized working directory, making it a common step in local development and CI before later workflow commands.

The key concept is command purpose. terraform validate is used to verify that Terraform configuration files are syntactically valid and internally consistent, such as correct block structure, valid references, and acceptable argument placement. It is designed as a fast quality check before planning or applying changes, so it fits naturally into local development and CI pipelines.

In a typical workflow:

• terraform init prepares the directory
• terraform validate checks configuration correctness
• terraform plan previews proposed changes

The closest distractor is terraform plan, because it can reveal problems, but its main job is to generate an execution plan rather than serve as the primary early validation step.

• terraform fmt is for code formatting, not for checking whether the configuration is logically valid.
• terraform plan can surface issues, but it is primarily for previewing infrastructure changes.
• terraform init prepares the working directory by installing providers and modules; it does not validate configuration correctness.

Question 8

Topic: Core Terraform Workflow

After a team runs terraform init, terraform validate, and terraform plan, which command actually attempts to change the managed infrastructure?

Options:

• A. terraform validate

• B. terraform plan

• C. terraform init

• D. terraform apply

Best answer: D

Explanation: terraform apply is the only command listed that acts on managed infrastructure. It executes the planned changes through the providers and records the resulting resource state for Terraform to track.

In the core Terraform workflow, terraform init prepares the working directory by downloading providers and setting up the backend, terraform validate checks that the configuration is syntactically and internally valid, and terraform plan shows what Terraform intends to do. Only terraform apply actually calls the provider APIs to create, update, or destroy resources and then writes the results to state. That makes it the command that changes managed infrastructure. The closest distractor is terraform plan, because it calculates proposed actions, but it does not execute them.

• terraform init prepares Terraform to run, but it does not modify managed resources.
• terraform validate checks configuration correctness, not infrastructure changes.
• terraform plan previews intended actions, but it stops before making any changes.

Question 9

Topic: Core Terraform Workflow

A cloud engineer has finished writing Terraform configuration for a new project in an empty working directory. Which sequence best matches the core Terraform workflow to create infrastructure safely?

Options:

• A. Run terraform import, then terraform state pull, then terraform apply

• B. Run terraform init, then terraform plan, review the proposed changes, then run terraform apply

• C. Run terraform validate, then terraform destroy, then terraform apply

• D. Run terraform apply, review the changes, then run terraform init

Best answer: B

Explanation: The core Terraform workflow is to write configuration, initialize the working directory with terraform init, create an execution plan with terraform plan, review the proposed changes, and then apply them with terraform apply. This sequence reduces mistakes by showing expected changes before any infrastructure is modified.

Terraform’s basic workflow follows a predictable order. After writing configuration, terraform init prepares the working directory by installing required providers and setting up backend-related components. Next, terraform plan compares the configuration with the current state and real infrastructure to produce an execution plan. You review that plan to confirm Terraform will make the intended changes. Only then do you run terraform apply to create, update, or destroy resources according to the approved plan.

Commands like terraform validate and terraform fmt can be useful checks, but they are not the core create workflow described here. Likewise, destroy, import, and state commands serve different maintenance or migration purposes rather than the normal plan-and-apply path.

• The option starting with terraform apply is wrong because Terraform should be initialized and planned before changes are executed.
• The option using validate and destroy is wrong because those commands do not represent the normal workflow for creating new infrastructure.
• The option using import and state pull is wrong because those commands are for bringing existing resources under management or inspecting state, not the standard provisioning sequence.

Question 10

Topic: Core Terraform Workflow

A cloud engineer clones a Terraform repository for the staging environment. The repo includes a remote backend, a registry module, and a .terraform.lock.hcl file. Before reviewing changes, they need downloaded module code, the configured shared state backend, and the same provider selections as the rest of the team. What is the best next action?

Options:

• A. Run terraform validate.

• B. Run terraform init.

• C. Run terraform plan.

• D. Run terraform init -upgrade.

Best answer: B

Explanation: terraform init is the command that prepares a Terraform working directory. In this scenario, it initializes the configured backend, downloads the registry module, and installs the provider selections recorded for the team so a later terraform plan can safely review changes.

terraform init is the first workflow step after cloning a Terraform configuration or after adding backend, module, or provider requirements. It prepares the working directory so Terraform can work consistently and safely. Here, initialization connects the directory to the configured remote backend for shared state, downloads the referenced module, and installs the required provider plugins using the configuration and existing lock file.

A simple way to remember init is:

• initialize the backend
• fetch child modules
• install provider plugins

Only after that preparation should you run terraform plan to review proposed changes. The closest distractor is using -upgrade, which changes version-selection behavior when the goal is consistency with the rest of the team.

• Unneeded upgrade The -upgrade flag can select newer allowed versions, which works against keeping the team’s existing provider selections.
• Wrong stage terraform plan evaluates proposed changes, but it assumes the directory has already been initialized.
• Scope mismatch terraform validate checks configuration correctness; it does not initialize the backend or install modules and providers.

Continue in the web app

Use IT Mastery for interactive Terraform Associate (004) practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Terraform Associate (004) on Web

Related focused pages

• Free Terraform Associate (004) Full-Length Practice Exam
• IaC with Terraform
• Terraform Fundamentals
• Terraform Configuration
• Terraform Modules
• Terraform State Management
• Terraform Maintenance
• HCP Terraform