TF-004 Use the core Terraform workflow — 10 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

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 6

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 7

Which THREE are valid methods to manage Terraform state files? (Choose three.)

Accepted Answer

Local state file. Terraform can manage state using a local file (terraform.tfstate) stored on the machine where Terraform is run. This is the default behavior and is valid for single-user or test scenarios, though it lacks locking and remote collaboration features.

For collaborative and production environments, Terraform supports remote backends. These backends store the state file in a shared, persistent storage location, often providing features like state locking to prevent concurrent modifications and versioning. Examples include Amazon S3, Azure Blob Storage (AzureRM), Google Cloud Storage (GCS), and HashiCorp Consul.

Terraform Cloud also provides a managed remote backend for state storage, offering advanced features like remote operations, private module registry, and policy as code (Sentinel), making it a comprehensive solution for managing Terraform state and workflows.

Answer

terraform state push

Answer

terraform state mv

Question 8

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 9

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 10

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

Accepted Answer

It automatically refreshes the state before creating the plan. `terraform plan` automatically performs a state refresh by default before creating the execution plan. This refresh updates the state file to match real-world infrastructure, ensuring the plan is based on the current state of resources. Without this refresh, the plan could be built on stale state data, leading to incorrect or failed operations. Furthermore, the `-out` option allows saving the generated plan to a specified file, which can then be used with `terraform apply` to ensure that only the changes outlined in that specific plan are executed.

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