TF-004 Understand Terraform basics Practice Test 2 — 15 Questions

Question 1

A platform team manages a large Terraform codebase with hundreds of resources across multiple environments (dev, staging, prod). They use terraform workspaces to manage environment-specific state files. Recently, an engineer made changes to the production workspace but forgot to switch from the dev workspace before applying. The apply was successful, but now the production resources are in an inconsistent state. The team wants to recover the production state to match the actual infrastructure. The previous state file for production was backed up in an S3 bucket before the accidental apply. What is the best course of action?

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

Accepted Answer

Use terraform state push with the backup state file to overwrite the current state. `terraform state push` directly overwrites the current state file in the workspace with a provided state file. Since the team has a backup of the production state file taken before the accidental apply, pushing that backup restores the state to exactly match the actual infrastructure, assuming no other changes occurred. This is the fastest and most reliable method to recover from an incorrect state overwrite, as it bypasses any reconciliation logic and replaces the state wholesale.

Answer

Use terraform state mv to correct the state entries by mapping resources from the backup to the current state

Answer

Use terraform import to manually import each production resource based on the backup state

Answer

Use terraform workspace select prod then terraform apply with the backup state file

Question 2

Which TWO of the following statements about Terraform state are correct? (Choose two.)

Accepted Answer

Terraform state can be stored remotely using backends like S3 or Azure Storage.. Terraform state is stored locally by default in terraform.tfstate, and can be shared via remote backends like S3. State is not encrypted by default and may contain sensitive data.

Answer

Terraform state can be shared across team members using a local file.

Answer

Terraform state is always encrypted at rest by default.

Question 3

Refer to the exhibit. The engineer runs terraform plan and gets:

Error: Reference to undeclared data source
  on main.tf line 6, in resource "aws_security_group" "example":
   6:   vpc_id = data.aws_vpc.selected.id

A data source "aws_vpc" "selected" is declared but not yet read. What is the most likely cause?

Accepted Answer

The provider is not configured, so Terraform cannot query the VPC.. The explanation incorrectly states that 'Without a valid provider configuration, Terraform cannot read the data source, and as a result, it treats the reference as if the data source does not exist.' In actual Terraform behavior, if a data source block is declared but its provider is not configured, Terraform typically produces an error like 'Error: No provider for data.aws_vpc.selected', not 'Error: Reference to undeclared data source'. The 'Reference to undeclared data source' error specifically indicates that the data source block itself is missing, misspelled, or commented out, which directly contradicts the stem's assertion that the data source is 'declared'. Therefore, the explanation does not accurately justify option B given the specific error message provided in the stem.

Answer

The data source must be defined after the resource that uses it.

Answer

The 'default = true' argument is invalid for aws_vpc data source.

Answer

The data source name 'selected' conflicts with a reserved keyword.

Question 4

A DevOps engineer is writing a Terraform configuration to provision an AWS EC2 instance. They want to ensure that the instance is replaced if the AMI ID changes, but not if the instance type changes. Which lifecycle meta-argument should be used?

Accepted Answer

Set `create_before_destroy = true` and add `instance_type` to `ignore_changes`. `create_before_destroy = true` ensures the new instance is created before the old one is destroyed, which is a best practice for zero-downtime deployments when the AMI changes. Adding `instance_type` to `ignore_changes` tells Terraform to ignore changes to the instance type attribute during plan/apply, so the instance is not replaced when only the instance type changes. This combination precisely meets the requirement: replacement on AMI change, no replacement on instance type change.

Answer

Set `prevent_destroy = true`

Answer

Set `ignore_changes = all`

Answer

Set `create_before_destroy = true` only

Question 5

A team is using Terraform to manage infrastructure across multiple environments (dev, staging, prod). They want to reuse the same root module configuration but with different variable values. Which approach is the most efficient?

Accepted Answer

Use Terraform workspaces. Terraform workspaces allow you to manage multiple distinct sets of infrastructure resources (e.g., dev, staging, prod) from the same root module configuration by maintaining separate state files for each workspace. This avoids duplicating code or manually managing state file switching, making it the most efficient approach for reusing configuration with different variable values across environments.

Answer

Use environment variables to switch between configurations

Answer

Use a single state file that includes all environments

Answer

Copy the entire configuration into separate directories for each environment

Question 6

A Terraform configuration includes a module from the Terraform Registry. After running `terraform init`, the module is downloaded. However, a subsequent `terraform plan` fails with an error that a required provider is not installed, even though it is declared in the module. What is the most likely cause?

Accepted Answer

The `required_providers` block is not declared in the root module. In Terraform, the `required_providers` block must be declared in the root module to ensure all providers are installed during `terraform init`. When a module from the Registry declares a provider but the root module does not, `terraform init` may not automatically install that provider, leading to a 'required provider not installed' error during `terraform plan`. The root module acts as the top-level configuration that aggregates all provider requirements.

Answer

The module uses a different Terraform version

Answer

The provider version constraint is incompatible

Answer

The module source URL is incorrect

Question 7

Which TWO of the following are valid ways to reference a resource attribute in Terraform?

Accepted Answer

`module.vpc.vpc_id`. `module.vpc.vpc_id` directly references an output attribute from a module. In Terraform, module outputs are accessed using the syntax `module..`, and `vpc_id` is a common output from VPC modules that exposes the ID of the created VPC resource.

Answer

`module.vpc.output`

Answer

`data.aws_ami.ubuntu.id`

Answer

`var.instance_type`

Question 8

Refer to the exhibit. A developer runs `terraform apply` and the operation succeeds. Later, they manually terminate the EC2 instance through the AWS console. What will happen when the developer runs `terraform apply` again?

Accepted Answer

Terraform will recreate the EC2 instance and reassociate the Elastic IP. Terraform maintains the Elastic IP (EIP) association in its state file. When the EC2 instance is manually terminated outside of Terraform, the state still records the EIP as associated with that instance ID. On the next `terraform apply`, Terraform detects that the instance is missing (drift) and plans to recreate it, then reassociates the EIP to the new instance as defined in the configuration, ensuring the public IP remains attached.

Answer

The Elastic IP will be disassociated and the instance will be recreated

Answer

Terraform will only recreate the EC2 instance without reassociating the Elastic IP

Answer

The apply will fail because the Elastic IP is still attached to the terminated instance

Question 9

You are a platform engineer at a fintech company. Your team manages a multi-region application on AWS using Terraform. The infrastructure includes VPCs, subnets, EC2 instances, and an Application Load Balancer (ALB). The configuration uses modules from the Terraform Registry and remote state in S3 with DynamoDB locking.

Recently, after a colleague ran `terraform apply` in the us-east-1 region, the application experienced downtime because the ALB's target group was accidentally updated to point to instances in us-west-2 instead of us-east-1. The root cause was that the Terraform configuration for the ALB used a variable `target_region` which was hardcoded to us-west-2 in a `terraform.tfvars` file that was not intended for that workspace.

Your team wants to prevent such misconfigurations in the future. Which course of action would most effectively reduce the risk of using incorrect variable values across workspaces?

Accepted Answer

Create separate Terraform configurations for each region, each with its own backend configuration and variable files, and use directory structure to enforce separation. Creating separate Terraform configurations for each region enforces strict isolation at the directory and backend level, preventing accidental cross-region variable injection. This approach ensures that each region's configuration has its own dedicated variable files and state, eliminating the risk of a `terraform.tfvars` file from one workspace affecting another. It aligns with infrastructure-as-code best practices for multi-region deployments where environment boundaries must be explicit.

Answer

Implement a CI/CD pipeline that runs `terraform plan` for every workspace and requires manual approval before apply

Answer

Use the same S3 backend for all regions but with different state file keys, and enforce naming conventions

Answer

Store all variables in a single `terraform.tfvars` file and use conditionals with `terraform.workspace` to select values

Question 10

A developer is new to Terraform and wants to understand the core workflow. Which sequence of commands correctly represents the basic Terraform workflow?

Accepted Answer

terraform init, terraform plan, terraform apply. The basic Terraform workflow follows a strict three-step sequence: `terraform init` to initialize the working directory and download required providers/modules, `terraform plan` to preview the changes Terraform will make against the current state, and `terraform apply` to execute the planned changes. Skipping `init` or `plan` would either fail due to missing providers or apply changes without a reviewable execution plan, violating the standard workflow.

Answer

terraform init, terraform apply

Answer

terraform plan, terraform init, terraform apply

Answer

terraform validate, terraform plan, terraform destroy

Question 11

You are a DevOps engineer managing a multi-environment Terraform setup using workspaces. Your team has three workspaces: dev, staging, and prod. All infrastructure is defined in a single root module with environment-specific variable values stored in separate .tfvars files. Recently, a colleague accidentally ran terraform destroy in the prod workspace, which deleted critical production resources. You need to implement a safety mechanism to prevent accidental destruction of production resources in the future. The solution should not require changes to the Terraform provider or backend configuration. Which approach should you take?

Accepted Answer

Add a lifecycle precondition block in a null_resource that checks if the current workspace is 'prod' and fails if terraform destroy is attempted.. A `lifecycle` precondition block in a `null_resource` can evaluate the current workspace at plan time using `terraform.workspace`. When `terraform destroy` is run, the precondition fails if the workspace is `prod`, preventing the destroy operation without altering the provider or backend configuration. This approach is native to Terraform, requires no external tools, and directly enforces the safety check within the configuration itself.

Answer

Create a wrapper script that checks the workspace before running terraform destroy and requires a manual confirmation for prod.

Answer

Use Terraform Sentinel policies with a mandatory policy that denies destroy on the prod workspace.

Answer

Configure a remote backend with state locking and force unlock only for non-prod workspaces.

Question 12

Which three of the following are core characteristics of Terraform's execution plan? (Choose three.)

Accepted Answer

It is generated by the `terraform plan` command.. The `terraform plan` command generates an execution plan that shows exactly what actions Terraform will take to reach the desired state defined in the configuration. This plan can be saved to a file and later applied using `terraform apply` with that file, ensuring the exact same changes are executed. These three characteristics are fundamental to Terraform's workflow, providing a safe and predictable way to manage infrastructure changes.

Answer

It automatically applies changes to infrastructure without user confirmation.

Answer

It is a read-only view of the current state file with no indication of future actions.

Answer

It only shows changes for resources that were manually modified outside Terraform.

Question 13

Which of the following are core concepts or behaviors of Terraform's execution model and state management? (Choose four.)

Accepted Answer

Terraform uses a desired state model, where configuration defines the target state and Terraform determines the actions needed to reach it.. Terraform's execution model is fundamentally a desired state model: the configuration declares the target state, and Terraform computes the actions needed to reach it. The state file is the critical mapping between configuration and real-world resources, tracking metadata like dependencies and attributes. The plan phase produces a dry-run execution plan without making changes, while apply executes those changes and can be run directly without a saved plan file. These four behaviors—desired state, state file mapping, plan as dry-run, and apply as execution—are core to how Terraform operates.

Answer

Terraform destroy removes all resources defined in the configuration from the state file only, without affecting the actual infrastructure.

Answer

Terraform refresh automatically updates the state file to match real-world infrastructure by modifying resources if differences are found.

Question 14

Drag and drop the steps to create and apply a Terraform plan in the correct order.

Accepted Answer

1. Terraform init, 2. Terraform plan, 3. Terraform apply. The correct sequence is: Terraform init (initialize the working directory and download providers/modules), Terraform plan (review the changes Terraform will make), and Terraform apply (execute the planned changes). This order ensures the environment is ready, changes are reviewed, and then safely applied.

Answer

1. Terraform plan, 2. Terraform init, 3. Terraform apply

Answer

1. Terraform init, 2. Terraform apply, 3. Terraform plan

Answer

1. Terraform plan, 2. Terraform apply, 3. Terraform init

Question 15

Drag and drop the steps to set up remote state with Terraform Cloud in the correct order.

Accepted Answer

Create a workspace in Terraform Cloud, then add the cloud block to your configuration, then run terraform init.. The correct order is to first create the workspace in Terraform Cloud, then add the cloud block to your Terraform configuration referencing that workspace, and finally run terraform init which detects the cloud block and migrates the state from local to the remote workspace. Other orders fail because the workspace must exist before the cloud block is configured or init is run without proper backend configuration.

Answer

Add the cloud block to your configuration, then create a workspace in Terraform Cloud, then run terraform init.

Answer

Run terraform init, then add the cloud block to your configuration, then create a workspace in Terraform Cloud.

Answer

Create a workspace in Terraform Cloud, then run terraform init, then add the cloud block to your configuration.