Try 10 focused Terraform Associate (004) questions on Core Terraform Workflow, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try Terraform Associate (004) on Web View full Terraform Associate (004) practice page
| Field | Detail |
|---|---|
| Exam route | Terraform Associate (004) |
| Topic area | Core Terraform Workflow |
| Blueprint weight | 19% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Core Terraform Workflow for Terraform Associate (004). Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 19% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
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.
terraform apply alone creates a new plan, so it does not guarantee the reviewed actions are the ones executed.terraform plan -out=prod.tfplan again recalculates the plan instead of using the already approved one.terraform init prepares the working directory and providers, but it does not preserve or execute the reviewed change set.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.
terraform init, which is a separate command.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.
terraform validate checks correctness, not code formatting.terraform plan is for reviewing proposed infrastructure changes, not normalizing HCL style.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.
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:
The key distinction is that validation and planning use an already initialized directory; they do not replace initialization.
terraform validate checks configuration correctness but does not install a newly referenced module source.terraform plan expects initialization to have already prepared required dependencies.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.
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 directoryterraform validate checks configuration correctnessterraform plan previews proposed changesThe 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.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.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.
terraform apply is wrong because Terraform should be initialized and planned before changes are executed.validate and destroy is wrong because those commands do not represent the normal workflow for creating new infrastructure.import and state pull is wrong because those commands are for bringing existing resources under management or inspecting state, not the standard provisioning sequence.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:
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.
-upgrade flag can select newer allowed versions, which works against keeping the team’s existing provider selections.terraform plan evaluates proposed changes, but it assumes the directory has already been initialized.terraform validate checks configuration correctness; it does not initialize the backend or install modules and providers.Use the Terraform Associate (004) Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try Terraform Associate (004) on Web View Terraform Associate (004) Practice Test
Read the Terraform Associate (004) Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.