TF-003 Understand Terraform basics — Timed 10 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.