TF-003 Understand Terraform basics — 20 Questions

Question 1

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`. Option C is correct because `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 2

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 3

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. Option C is correct because 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 4

An organization uses Terraform Cloud for remote state management. They have a workspace that uses the CLI-driven run workflow. A developer runs `terraform plan` locally and sees that the plan succeeds. However, when they push the same configuration to the version control system (VCS) connected to the workspace, the plan fails with a state lock error. What is the most likely reason?

Accepted Answer

The local `terraform plan` left the state locked in Terraform Cloud. The local `terraform plan` command acquires a state lock in Terraform Cloud to prevent concurrent modifications. When the developer runs `terraform plan` locally but does not follow it with `terraform apply` or explicitly release the lock (e.g., via `terraform force-unlock`), the lock persists. When the VCS pipeline triggers a new run, it attempts to acquire the same lock, which is still held by the local session, causing the plan to fail with a state lock error.

Answer

The Terraform version in the VCS pipeline is different

Answer

The VCS branch is not configured as the workspace's working branch

Answer

The VCS pipeline does not have access to the Terraform Cloud workspace

Question 5

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

Accepted Answer

`module.vpc.vpc_id`. Option D is correct because `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 6

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. Option A is correct because 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 7

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. Option D is correct because 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 8

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. Option C is correct because 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 9

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

Accepted Answer

State can be used to improve performance by caching resource attributes.. Option B is correct because Terraform state acts as a cache for resource attributes, allowing Terraform to avoid re-querying the provider for every attribute during planning and applying. This improves performance, especially when dealing with large infrastructures or APIs with rate limits, as the state file stores the last-known values of resource attributes.

Answer

State never contains sensitive data, so it can be stored in version control.

Answer

State does not store resource IDs; it only stores metadata.

Answer

State should be stored locally by default for team collaboration.

Question 10

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.. Option D is correct because 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 11

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

Accepted Answer

It shows what actions Terraform will take to reach the desired state.. 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 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.

Answer

It automatically applies changes to infrastructure without user confirmation.

Question 12

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 13

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

Question 14

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

Question 15

Match each Terraform feature to its description.

Question 16

Match each Terraform provisioner to its typical use case.

Question 17

A developer runs terraform apply to create an AWS EC2 instance using an AMI sourced from the aws_ami data source with most_recent = true. Immediately after apply completes, the developer runs terraform plan again. The plan shows that Terraform intends to replace the EC2 instance. What is the most likely cause?

Accepted Answer

A new AMI was released after the apply, causing the data source to return a different AMI ID.. The data source with most_recent = true fetches the latest AMI each time plan runs. If a new AMI is released after the apply, the AMI ID changes, forcing replacement of the EC2 instance because the AMI change requires resource replacement.

Answer

The developer did not run terraform init before the second plan.

Answer

The instance type was changed in the configuration between apply and plan.

Answer

The Terraform state file was corrupted during the apply.

Question 18

A team is using Terraform to manage infrastructure across multiple environments (dev, test, prod). They want to reuse the same configuration but vary resource configurations like instance size and number of instances. Which Terraform feature should they use?

Accepted Answer

Terraform modules with variables. Terraform modules with variables allow you to define reusable infrastructure and pass environment-specific variable values. This is the recommended approach for code reuse across environments.

Answer

Separate directories with symlinks

Answer

Remote backends with different state files

Answer

Terraform workspaces

Question 19

A company has a monolithic Terraform configuration that manages all infrastructure. As the infrastructure grows, plan and apply times become very long. They want to break the configuration into smaller, independent units to improve performance and reduce blast radius. Which approach should they take?

Accepted Answer

Split the configuration into separate root modules, each with its own state file, and use data sources to share outputs. Splitting into separate root modules, each with its own state file, and using data sources to share outputs, is the recommended approach for reducing blast radius and improving performance. This allows independent plan/apply cycles and smaller state files.

Answer

Refactor into multiple Terraform modules and use a single root module

Answer

Use Terraform workspaces to separate environments

Answer

Use terraform state mv to reorganize resources into different state files

Question 20

A developer is new to Terraform and wants to understand the purpose of the terraform init command. Which statement correctly describes its primary function?

Accepted Answer

It initializes the local environment by downloading the required provider plugins and modules.. terraform init initializes the working directory by downloading the required provider plugins, modules, and setting up the backend. It is the first command run after writing or cloning a Terraform configuration.

Answer

It checks the syntax of all configuration files.

Answer

It compares the state file with real infrastructure.

Answer

It creates the initial configuration for a new Terraform project.