TF-004 Use the core Terraform workflow Practice Test 1 — 15 Questions

Question 1

During a 'terraform plan', you see the following output: 'Plan: 1 to add, 2 to change, 0 to destroy.' However, after running 'terraform apply', the actual number of resources changed is different. What is the most likely reason?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The configuration was modified after the plan was generated.. The plan is generated based on the configuration and state at the time of 'terraform plan'. If the configuration is modified after the plan is generated, 'terraform apply' will use the current configuration, which may differ from what was planned. This can cause the actual number of resources added, changed, or destroyed to differ from the plan. Option C correctly identifies this as the most likely reason. Option A is incorrect because state locking prevents concurrent operations but does not cause a discrepancy if the plan is still valid. Option B is incorrect because a corrupted state file would typically cause errors, not a difference in resource counts. Option D is incorrect as stated. When 'terraform apply' is run without a saved plan file (i.e., 'terraform apply' instead of 'terraform apply <planfile>'), it performs an implicit refresh to detect drift and then generates a new plan based on the current configuration and refreshed state. If drift is detected, this new plan could indeed differ from a previously generated plan. However, modifying the configuration (Option C) is generally a more direct and common reason for a significant discrepancy in resource counts between a 'plan' and a subsequent 'apply'.

Answer

Terraform state locking prevented the apply from executing correctly.

Answer

The state file was corrupted during the apply.

Answer

The 'terraform apply' command includes an implicit refresh that changes the plan.

Question 2

Which TWO of the following are valid steps in the core Terraform workflow?

Accepted Answer

Run terraform init to initialize the working directory and download providers. `terraform init` is the first step in the core Terraform workflow, which initializes the working directory, downloads the required provider plugins, and sets up the backend configuration. Without this step, subsequent commands like `terraform plan` or `terraform apply` cannot function, as the providers and state backend are not yet configured. `terraform apply` is the final step in the core workflow, executing the changes outlined in the plan to create or update infrastructure to match the desired state defined in the configuration files.

Answer

Run terraform import to bring existing resources under management

Answer

Run terraform output to retrieve output values

Answer

Run terraform destroy to remove resources

Question 3

A team is adopting Terraform for infrastructure deployment. They want to ensure that the core workflow (write, plan, apply) is followed effectively. Which two practices should they adopt? (Choose two.)

Accepted Answer

Store Terraform configurations in a version control system like Git.. Storing Terraform configurations in a version control system like Git ensures that the 'write' phase is collaborative, auditable, and repeatable. It enables teams to track changes, roll back to previous versions, and enforce code review before applying infrastructure changes, which is a core DevOps practice for the Terraform workflow. Using a remote backend with state locking enabled is crucial for the 'plan' and 'apply' phases in a team environment. It prevents concurrent operations from corrupting the state file, ensures consistency across team members, and provides a centralized, reliable source of truth for the infrastructure's current state.

Answer

Require manual confirmation for every terraform plan execution.

Answer

Store state files locally on the engineer's machine.

Answer

Always run terraform apply directly without terraform plan to save time.

Question 4

What is the most likely cause of this error?

Accepted Answer

The AWS credentials used do not have permission to launch EC2 instances.. The provided explanation correctly describes why insufficient permissions would lead to an authorization error (e.g., `ec2:RunInstances` permission missing). However, without the specific error message in the STEM, it's impossible to confirm that the question is indeed about an authorization error. If the error message were, for example, a syntax error or a resource validation error, a different option would be correct. The explanation should directly address the *specific* error presented in the STEM.

Answer

The Terraform configuration has a syntax error.

Answer

The instance type 't2.micro' is not available in the region.

Answer

The AMI ID is invalid or does not exist in the region.

Question 5

Which of the following statements about the core Terraform workflow (Write, Plan, Apply) are correct? (Choose all that apply. There are four correct answers.)

Accepted Answer

Running `terraform plan` is strictly optional before `terraform apply` because apply will automatically generate and execute a plan if none is provided.. The core Terraform workflow consists of three phases: Write, Plan, and Apply. During the Write phase, you define your desired infrastructure in `.tf` configuration files, which can include variables, data sources, and modules. The `terraform plan` command creates an execution plan that shows what actions Terraform will take to reach that desired state. The `terraform apply` command can use a saved plan from `terraform plan -out` without additional flags, or if no plan is provided, it will automatically generate and execute a new plan. This workflow ensures that changes are reviewed before being applied, reducing the risk of unintended modifications.

Answer

The `terraform apply` command can be used to destroy infrastructure by passing a plan that includes only destroy operations, but the more common approach is to use `terraform destroy`.

Answer

If a `terraform plan` shows that a resource will be destroyed and recreated, the state file is immediately updated to reflect this planned change before apply.

Question 6

Drag and drop the steps to import existing infrastructure into Terraform state in the correct order.

Accepted Answer

1. Write the resource configuration block in a .tf file. 2. Run terraform import with the resource address and ID. 3. Run terraform plan to verify configuration matches the real-world resource.. First, write the resource configuration block (step 1) to define how Terraform should manage the resource. Then, run `terraform import` (step 2) to bring the existing resource into the Terraform state, linking it to the configuration. Finally, run `terraform plan` (step 3) to verify that the written configuration accurately reflects the imported resource and to detect any drift.

Answer

1. Run terraform import with the resource address and ID. 2. Write the resource configuration block in a .tf file. 3. Run terraform plan to verify configuration matches the real-world resource.

Answer

1. Run terraform plan. 2. Write the resource configuration block in a .tf file. 3. Run terraform import with the resource address and ID.

Answer

1. Write the resource configuration block in a .tf file. 2. Run terraform plan. 3. Run terraform import with the resource address and ID.

Question 7

Match each Terraform workflow stage to its description.

Accepted Answer

terraform init: Initializes a working directory containing Terraform configuration files.. The content of options A, B, C, D correctly describes the respective Terraform commands, and options E, F are correctly identified as wrong. The overall explanation is also accurate. However, the question's structure is inconsistent. A true 'matching' question would provide two sets of items for the student to pair. As currently structured, it functions more like a 'select all correct statements' question, where the student would identify A, B, C, and D as correct.

Answer

terraform init: Creates an execution plan to reach the desired state.

Answer

terraform plan: Executes the actions proposed in a plan.

Question 8

A developer runs `terraform init` in a directory containing Terraform configuration files. After initialization, they notice that a provider plugin was installed. Where are provider plugins stored locally by default?

Accepted Answer

In a `.terraform` subdirectory of the current working directory. By default, `terraform init` downloads and installs provider plugins into a `.terraform` subdirectory within the current working directory. This local directory acts as the plugin cache for the specific configuration, ensuring that each Terraform project has its own isolated set of provider binaries. The `.terraform` directory is created automatically during initialization and is managed by Terraform to store plugins, modules, and state data.

Answer

In the system-wide plugin directory `/usr/share/terraform/plugins`

Answer

In the user's home directory under `~/.terraform.d/plugins`

Answer

In a temporary directory that is deleted after `terraform init` completes

Question 9

When running `terraform plan`, an engineer sees that Terraform proposes to destroy an existing resource even though the resource still exists in the cloud provider. What is the most likely cause?

Accepted Answer

The resource's `count` or `for_each` meta-argument was removed from the configuration. The explanation accurately describes why removing 'count' or 'for_each' leads to a destroy plan due to changes in the resource's logical address. This part is correct.

Answer

Another user ran `terraform destroy` without the engineer's knowledge

Answer

The state file was corrupted and lost the resource

Answer

The resource was manually deleted from the cloud provider console

Question 10

An engineer accidentally destroys a critical resource by running `terraform apply` after an incorrect `terraform plan`. They want to recover the resource quickly. What should they do?

Accepted Answer

Restore the previous version of the configuration and run `terraform apply` again. When a resource is accidentally destroyed by `terraform apply` (e.g., because it was removed from the configuration), it is also removed from the Terraform state. The most straightforward recovery is to revert the configuration to a previous version where the resource was defined. Running `terraform apply` with this restored configuration will cause Terraform to detect the resource definition in the configuration that is missing from the current state, and it will then plan to create the resource.

Answer

Modify the configuration to match the destroyed resource and run `terraform import`

Answer

Use `terraform force-unlock` to unlock the state and then run `terraform plan`

Answer

Run `terraform state rm` to remove the destroyed resource from state and then re-import it

Question 11

Which TWO statements accurately describe the `terraform plan` command? (Select TWO.)

Accepted Answer

It automatically refreshes the state before creating the plan. Option D is correct because `terraform plan` performs a refresh of the state by default before generating the execution plan, reconciling the recorded state with real infrastructure unless `-refresh=false` is specified. Option E is correct because the `-out` option saves the generated plan to a file (e.g., `terraform plan -out=tfplan`), which can later be applied with `terraform apply tfplan` for a consistent, reviewed execution. Option A is incorrect because destroying infrastructure is done via `terraform destroy` (or `terraform apply -destroy`), not by `terraform plan -destroy`, which only previews a destroy plan. Option B is incorrect because `terraform plan` is read-only and never applies changes; `terraform apply` performs the actual modifications. Option C is incorrect because `terraform plan` requires Terraform configuration files in the working directory to determine the desired state.

Answer

It can be used to destroy infrastructure if the `-destroy` flag is set

Answer

It applies changes to infrastructure

Answer

It requires no configuration files in the directory

Question 12

Which THREE are valid uses of the `terraform state` command? (Select THREE.)

Accepted Answer

Move a resource from one state file to another. Option B is correct because `terraform state mv` moves a resource from one state file to another (or renames it within a state), which is exactly the cross-state move use case. Option C is correct because `terraform state rm` removes a resource from the state file without destroying the actual infrastructure, leaving it unmanaged. Option D is correct because `terraform state list` lists all resources tracked in the current state. Option A is not a `terraform state` subcommand: state locking is released with `terraform force-unlock <LOCK_ID>`. Option E is not a `terraform state` subcommand either: importing existing resources is done with `terraform import`, not `terraform state`.

Answer

Force unlock the state lock

Answer

Import an existing resource into state

Question 13

Which THREE of the following are valid flags for the terraform apply command? (Choose three.)

Accepted Answer

-lock-timeout. The question asks for valid flags of `terraform apply`, and options A, B, C, and D are all legitimate flags for that command. `-lock-timeout` (A) sets how long Terraform waits to acquire the state lock before failing, e.g. `-lock-timeout=5m`. `-target` (B) restricts the operation to specific resources, e.g. `-target=aws_instance.example`. `-var-file` (C) supplies a file of input variable values, e.g. `-var-file=prod.tfvars`. `-auto-approve` (D) skips the interactive approval prompt, which is valid for `apply`. Option E, `-refresh=false`, is not a valid `apply` flag; refresh behavior is controlled with `-refresh-only` or `-refresh=false` on `plan`, not as a standalone `apply` flag.

Answer

-refresh=false

Question 14

A team is running terraform in a CI/CD pipeline that executes multiple jobs in parallel for different modules. They notice that terraform init takes a long time in each job because it downloads provider plugins repeatedly. They want to speed up the init process by caching providers. What should they do?

Accepted Answer

Use the plugin_cache_dir setting in the CLI configuration file.. The `plugin_cache_dir` setting in the Terraform CLI configuration file instructs Terraform to store downloaded provider plugins in a shared cache directory. Once a plugin is cached, subsequent `terraform init` commands in parallel jobs can reuse the cached plugin instead of downloading it again, significantly reducing init time. This setting is defined in the `.terraformrc` or `terraform.rc` file and is the recommended approach for CI/CD pipelines.

Answer

Set the environment variable TF_PLUGIN_CACHE_DIR to a shared path.

Answer

Copy the .terraform folder from a previous job.

Answer

Use terraform providers lock to freeze versions.

Question 15

A platform team wants to enforce a policy that all Terraform runs in their CI pipeline must be reviewed before changes are applied. They decide to use a saved plan file. Which TWO statements about using a saved plan file with terraform apply are correct? (Choose two.)

Accepted Answer

Using a saved plan file ensures that the applied changes match exactly what was reviewed during the plan phase.. A saved plan file is created with terraform plan -out and later applied with terraform apply <planfile>. It ensures the applied changes match the reviewed plan exactly, and it does not require an additional confirmation prompt. The file is binary and cannot be edited, and terraform init is still necessary before applying.

Answer

When applying a saved plan file, Terraform will still prompt for confirmation unless -auto-approve is also specified.

Answer

The saved plan file is human-readable and can be edited to remove specific resource changes before applying.

Answer

Applying a saved plan file bypasses the need to run terraform init as long as the backend configuration has not changed.