TF-003 Use the core Terraform workflow Practice Test 2 — 15 Questions

Question 1

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

Question 2

Match each Terraform workflow stage to its description.

Question 3

A user runs 'terraform plan' and the output includes a change that adds a new resource. However, the user expected the change to modify an existing resource. What is the most likely cause?

Accepted Answer

The resource name or type was changed in the configuration.. When a resource's name or type is changed in the configuration, Terraform interprets it as a request to destroy the old resource and create a new one, because Terraform maps each resource block to a state entry using its resource type and name (e.g., `aws_instance.web`). The plan output will show a `+` (create) for the new resource and a `-` (destroy) for the old one, rather than a `~` (update in-place). This matches the user's observation of a new resource being added instead of the expected modification.

Answer

The provider version was updated.

Answer

A required attribute was added to the resource block.

Answer

The state file was manually deleted.

Question 4

During 'terraform apply', a user receives an error: 'Error: Error creating resource: Resource already exists'. The resource does not appear in the Terraform state. What is the most likely cause?

Accepted Answer

The resource was manually created outside of Terraform before the apply.. Option D is correct because the error 'Resource already exists' indicates that the resource was created outside of Terraform's management (e.g., manually via the cloud console or CLI). Since the resource does not appear in the Terraform state, Terraform attempts to create it during 'terraform apply', but the underlying API rejects the request because the resource already exists in the cloud provider. This is a common state drift scenario where the real-world infrastructure is out of sync with the Terraform state.

Answer

The state file was migrated from a different backend and the resource is duplicated.

Answer

The resource was removed from the configuration but not from state.

Answer

The user forgot to run terraform refresh before apply.

Question 5

A team is using Terraform with multiple environments (dev, staging, prod) and wants to use separate state files. They are considering workspaces. A senior engineer suggests using separate directory structures instead of workspaces for prod. What is the strongest reason for this recommendation?

Accepted Answer

Workspaces share the same backend configuration, increasing the risk of accidental changes to production.. Workspaces share the same backend configuration, meaning all workspaces (including prod) use the same state storage location and access controls. This increases the risk of accidental changes to production because a single backend misconfiguration or a mistaken workspace switch can lead to unintended modifications to the production state file. Separate directory structures allow for independent backend configurations, enabling stricter access controls and isolation for production.

Answer

Workspaces cannot isolate state files.

Answer

Workspaces make it harder to refactor configurations.

Answer

Workspaces do not support state locking.

Question 6

After modifying a Terraform configuration file, a user runs 'terraform plan' and sees 'No changes. Infrastructure is up-to-date.' What is the most likely reason?

Accepted Answer

The configuration changes were made in a different directory.. Option D is correct because Terraform operates on the configuration files in the current working directory. If the user modified a Terraform configuration file in a different directory and then ran 'terraform plan' from the original directory, Terraform would compare the state against the unchanged configuration in the current directory, resulting in 'No changes. Infrastructure is up-to-date.'

Answer

The user forgot to run terraform init.

Answer

The configuration changes were not committed to version control.

Answer

The state is stored remotely and the user does not have access.

Question 7

A user runs 'terraform plan' and it shows 'No changes. Infrastructure is up-to-date.' However, the user knows they added a new resource block to the configuration. What could explain this?

Accepted Answer

The resource block has a count parameter set to 0.. When a resource block has `count = 0`, Terraform evaluates the count meta-argument and determines that zero instances of that resource should be created. As a result, the resource is effectively absent from the state, and `terraform plan` sees no changes because there is nothing to add, modify, or remove. This is a common cause of a 'No changes' result despite adding a new resource block.

Answer

The resource block is inside an output block.

Answer

The user ran terraform validate before plan.

Answer

The resource block was added after running terraform fmt.

Question 8

A team uses Terraform with remote state in an S3 backend and DynamoDB for state locking. A user runs 'terraform apply' and receives the error: 'Error acquiring the state lock'. The lock info shows a lock ID and caller. What is the best immediate course of action?

Accepted Answer

Check if another Terraform process is running; if not, use 'terraform force-unlock' with the lock ID.. Option A is correct because the error indicates a state lock is held, typically by another Terraform process or a stale lock. The best immediate course is to verify no other process is running (e.g., via 'ps' or task manager), then use 'terraform force-unlock -lock-id=<LOCK_ID>' to release the lock. This is the safe, documented procedure that preserves the state file and DynamoDB lock table integrity.

Answer

Delete the state file from S3 and re-run apply.

Answer

Manually delete the DynamoDB lock table item.

Answer

Wait for 15 minutes and re-run apply.

Question 9

What is the primary purpose of 'terraform init'?

Accepted Answer

To initialize the working directory, download providers, and set up the backend.. The 'terraform init' command is the first step in the core Terraform workflow. Its primary purpose is to initialize the working directory containing Terraform configuration files, download and install the required provider plugins (e.g., AWS, Azure, GCP), and configure the backend (e.g., local, S3, Terraform Cloud) for state storage. Without running 'terraform init', subsequent commands like 'terraform plan' or 'terraform apply' will fail because the providers and backend are not set up.

Answer

To format the Terraform configuration files.

Answer

To apply changes to the infrastructure.

Answer

To preview infrastructure changes before applying them.

Question 10

A user wants to import an existing AWS EC2 instance into Terraform state so it can be managed. After writing the resource block matching the instance, what is the correct next step?

Accepted Answer

Run 'terraform import' with the resource address and ID of the instance.. After writing the resource block that matches the existing EC2 instance, the correct next step is to run 'terraform import' with the resource address and the instance ID. This command maps the real-world infrastructure to the Terraform state, allowing Terraform to manage the resource without destroying or recreating it. Without this explicit import, Terraform has no knowledge of the existing instance in its state file.

Answer

Run 'terraform plan' to see if the import is necessary.

Answer

Run 'terraform refresh' to sync state with the existing resource.

Answer

Run 'terraform apply' directly; Terraform will detect the existing resource and import it.

Question 11

A company uses Terraform Cloud and wants to enforce policies that prevent creating resources with public IP addresses unless explicitly approved. What Terraform Cloud feature should they use?

Accepted Answer

Sentinel policies. Option C is correct because Sentinel is the policy-as-code framework in Terraform Cloud. Option A is wrong because workspaces are for state isolation, not policy. Option B is wrong because VCS integration is for triggering runs. Option D is wrong because run tasks allow custom validation but Sentinel is the built-in policy engine.

Answer

VCS integration

Answer

Workspaces

Answer

Run tasks

Question 12

Which TWO commands are part of the core Terraform workflow? (Choose two.)

Accepted Answer

terraform init. Option B, `terraform init`, is correct because it initializes a working directory containing Terraform configuration files, downloading and installing the required providers and modules. This is the first command in the core Terraform workflow, which follows the sequence: init, plan, apply. Without `init`, subsequent commands like `plan` or `apply` will fail due to missing provider plugins and backend configuration.

Answer

terraform fmt

Answer

terraform console

Answer

terraform get

Question 13

Which TWO scenarios could cause 'terraform plan' to show 'No changes' even though the configuration file was recently modified? (Choose two.)

Accepted Answer

The user ran 'terraform plan' from a different directory that does not contain the modified configuration.. Option A is correct because `terraform plan` operates on the configuration files in the current working directory. If the user runs the command from a different directory that does not contain the modified configuration, Terraform will compare the state against the unmodified files in that directory, resulting in 'No changes'. Option B is correct because a `lifecycle` block with `ignore_changes` tells Terraform to disregard changes to specified attributes when planning, so even if the configuration file modifies that attribute, Terraform will not detect a diff and will report 'No changes'.

Answer

The resource was manually updated in the cloud provider console.

Answer

A new resource block was added.

Answer

The provider version was changed in the required_providers block.

Question 14

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

Accepted Answer

Local state file. Option B is correct because 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.

Answer

terraform state push

Answer

terraform state mv

Question 15

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 provider plugins into a `.terraform` subdirectory of the current working directory. This is the standard location for the Terraform working directory's local cache.

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