TF-004 Timed Hard Questions — 25 Difficult Questions

Question 1

A large enterprise uses Terraform Cloud with remote execution mode to manage infrastructure across multiple AWS accounts. Each environment (dev, staging, prod) has a separate workspace. The security team requires that all changes to production must be approved by a senior engineer before applying. Additionally, developers should be able to plan changes in production to preview the impact, but not apply them. The current setup uses the same Terraform Cloud team membership for all workspaces. When a developer runs a plan in production, the plan succeeds but they are unable to apply. However, the security team notices that the developer can accidentally apply if they quickly approve their own plan via the UI because the workspace is configured with 'Auto Apply' enabled. The security team wants to enforce the approval process without removing the developer's ability to plan. Which combination of changes should be made? (Select only one option.)

15 minute time limit — choose an answer to begin.

Accepted Answer

Disable 'Auto Apply' on the production workspace and configure team permissions so that developers have 'plan' role and the infrastructure lead has 'write' role.. Disabling 'Auto Apply' on the production workspace ensures that no apply occurs without explicit approval. Configuring team permissions so that developers have the 'plan' role (which allows running plans but not applying) and the infrastructure lead has the 'write' role (which allows applying) enforces the required approval process while preserving the developer's ability to preview changes via plan.

Answer

Keep 'Auto Apply' enabled but restrict the production workspace to only the infrastructure lead's Terraform Cloud account.

Answer

Use run triggers to promote runs from dev to staging to production, and only the lead can promote to production.

Answer

Use VCS branch restrictions to only allow applies from the 'main' branch, and have developers plan from feature branches.

Question 2

A large organization uses Terraform to manage infrastructure across multiple AWS accounts. They have a shared module for VPC stored in a private Git repository (git::https://github.com/org/terraform-aws-vpc.git?ref=v1.0.0). After updating the module source to ref=v1.2.0, they run terraform init and then terraform plan. The plan still shows the old module's resources and behavior. They confirm the new tag exists and the module code has changed. The root module source line is correct. What is the most likely cause?

Accepted Answer

Terraform cached the previous module version and did not download the new one.. Terraform caches modules in the `.terraform/modules` directory after `terraform init`. When the module source version is updated (e.g., from `ref=v1.0.0` to `ref=v1.2.0`), Terraform does not automatically re-download the module unless the lock file changes or `terraform init -upgrade` is used. Running `terraform init` without the `-upgrade` flag will not overwrite the cached module, so the plan still reflects the old version's resources and behavior.

Answer

They forgot to run terraform get.

Answer

The module source URL is incorrect.

Answer

The module's outputs changed and they need to update the root module.

Question 3

Refer to the exhibit. A developer runs terraform plan and receives this error. What should the developer do to resolve the error?

Accepted Answer

Run terraform init -migrate-state to migrate the state to the new region.. The error indicates that the Terraform state is stored in a backend configuration that references a region that no longer exists or is inaccessible. Running `terraform init -migrate-state` allows Terraform to copy the existing state to a new backend configuration (including a new region) while preserving the state data, resolving the mismatch.

Answer

Run terraform plan again; the error will self-resolve after a few minutes.

Answer

Update the backend configuration in the Terraform code to match the previous region.

Answer

Run terraform state rm to remove the state file and start fresh.

Question 4

Refer to the exhibit. What is the purpose of the data source?

Accepted Answer

To fetch an existing AMI ID. In Terraform, a data source allows you to fetch or compute information from external sources that is not defined within the current configuration. The correct answer is B because the data source in the exhibit (e.g., `aws_ami`) is used to query and retrieve the ID of an existing AMI that matches specified filters, such as name, owner, or tag, without creating a new AMI. This enables dynamic referencing of pre-existing resources in your infrastructure.

Answer

To create a new AMI

Answer

To define a variable

Answer

To output the AMI name

Question 5

A team uses Terraform with remote state in Azure Storage. They have a CI/CD pipeline that runs terraform plan and apply. Recently, a team member ran terraform apply manually from their local machine and the process crashed due to a network interruption. Now, the pipeline's next run fails with an error: "Error: Error acquiring the state lock". The team is unsure who holds the lock. They need to proceed with the pipeline as soon as possible. What should they do?

Accepted Answer

Use terraform force-unlock with the lock ID to break the lock.. The correct action is to use `terraform force-unlock` with the lock ID to break the stale lock. When a Terraform process crashes while holding a state lock (stored in Azure Blob Storage via the `azurerm` backend), the lock remains in place, blocking all subsequent operations. The `force-unlock` command is the designed mechanism to manually release such locks, and the lock ID can be obtained from the error message or by querying the Azure Storage blob's lease state.

Answer

Wait for the lock to expire automatically.

Answer

Re-run terraform apply with -lock=false to skip locking.

Answer

Delete the .terraform folder and reinitialize.

Question 6

An organization manages multiple environments (dev, staging, prod) using Terraform. They want to minimize code duplication while allowing environment-specific variable values. Which approach best achieves this goal?

Accepted Answer

Organize the repository with a shared modules directory and separate subdirectories for each environment that call the same modules with environment-specific .tfvars files.. It leverages Terraform's module system to define reusable infrastructure components in a shared directory, while each environment (dev, staging, prod) has its own subdirectory with a root configuration that calls those modules and passes environment-specific `.tfvars` files. This minimizes code duplication by keeping the module logic in one place, and allows per-environment variable values without mixing concerns. It follows the recommended pattern for multi-environment management in Terraform, avoiding the pitfalls of branches, workspaces, or conditional logic that can lead to complexity or state corruption.

Answer

Use a separate Git branch for each environment, each with its own Terraform configuration.

Answer

Write a single Terraform configuration that uses count and conditional expressions to create resources based on environment variable.

Answer

Use Terraform workspaces with a single configuration and define all variable values in one .tfvars file.

Question 7

In Terraform, the `terraform plan` command compares the current state with the configuration. This is an example of which IaC principle?

Accepted Answer

Desired state enforcement. The `terraform plan` command compares the current state (what is deployed) with the configuration (what is declared) and computes the changes needed to align the real-world infrastructure with the declared configuration. This is the essence of desired state enforcement: the tool continuously reconciles the actual state toward the user-defined desired state, rather than executing imperative steps. Option D is correct because Terraform's core loop—plan, apply, refresh—is built around this declarative, state-driven model.

Answer

Version control integration

Answer

Continuous delivery

Answer

Modular architecture

Question 8

An organization uses Terraform with remote state stored in S3 and DynamoDB for state locking. During a plan, they receive the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. What is the most likely cause?

Accepted Answer

Another Terraform process is currently running and holds the state lock.. The error 'ConditionalCheckFailedException' occurs when DynamoDB's conditional put operation fails, which happens when a lock item already exists in the DynamoDB table. This indicates another Terraform process currently holds the state lock, preventing concurrent operations. Terraform uses DynamoDB's conditional writes to ensure only one process can acquire the lock at a time.

Answer

The state file in S3 is corrupted.

Answer

The DynamoDB table is not configured with a primary key named LockID.

Answer

The S3 bucket does not have versioning enabled.

Question 9

Refer to the exhibit. A team is troubleshooting a Terraform deployment. What information can be inferred from this state file?

Accepted Answer

There is one EC2 instance of type t2.micro with a dependency on a security group.. The state file explicitly shows a resource of type `aws_instance` with `instance_type = "t2.micro"` and a `depends_on` meta-argument referencing `aws_security_group.example`. This indicates that Terraform recorded the EC2 instance as created with a t2.micro type and that it has a formal dependency on a security group resource, ensuring the security group is created before the instance during apply.

Answer

The Terraform version is outdated and must be upgraded.

Answer

The instance ID is invalid and needs to be recreated.

Answer

The security group dependency was not applied.

Question 10

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.. 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 11

Which THREE statements about module configuration are correct?

Accepted Answer

Module sources can be local paths or remote URLs.. Terraform module sources can be either local file paths (e.g., `./modules/network`) or remote URLs (e.g., `git::https://example.com/repo.git`, `registry.terraform.io/hashicorp/consul/aws`). The `source` argument supports multiple protocols including local, Git, HTTP, and the Terraform Registry, making it flexible for version control and distribution.

Answer

Version constraints can be specified for any module source.

Answer

The outputs of a module are available after apply only.

Question 12

Which Terraform feature allows managing multiple separate sets of infrastructure from the same configuration?

Accepted Answer

Workspaces. Workspaces allow you to manage multiple distinct sets of infrastructure resources from the same Terraform configuration by maintaining separate state files. Each workspace isolates its own state data, enabling you to deploy, modify, or destroy infrastructure for different environments (e.g., dev, staging, prod) without interfering with each other. This is the native Terraform feature designed specifically for managing multiple separate instances of infrastructure from a single configuration.

Answer

Count

Answer

Providers

Answer

For_each

Question 13

During a CI/CD pipeline run, terraform apply fails halfway through due to a network error. The state file is locked. The team wants to resume from the last successful apply. What should they do?

Accepted Answer

Re-run terraform apply after solving the network issue; Terraform will handle partial state.. Terraform's state file tracks all managed resources and their current status. When `terraform apply` fails mid-run, the state is locked to prevent corruption, but Terraform records any resources that were successfully created before the failure. After resolving the network issue, re-running `terraform apply` will use the existing state to detect already-created resources and continue from where it left off, creating only the remaining resources. This is the correct and intended workflow for handling partial state in Terraform.

Answer

Run terraform destroy and then reapply.

Answer

Force unlock the state and then reapply.

Answer

Manually delete the partially created resources in the cloud console and reapply.

Question 14

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 15

A Terraform configuration uses a for_each expression to create multiple subnets. After applying, one subnet's configuration needs to be modified. The engineer updates the resource block's map key for that subnet. What will terraform plan show?

Accepted Answer

Destruction of the existing subnet and creation of a new one.. When a for_each expression is used, Terraform identifies each resource instance by its map key. Changing the map key for a subnet causes Terraform to treat the old key as a resource to be destroyed and the new key as a resource to be created, because the key is part of the resource's identity. Even if the configuration inside the block is identical, the change in key results in a destroy-and-create action, not an in-place update.

Answer

No changes because the subnet configuration is the same.

Answer

Only deletion of the old subnet.

Answer

An in-place update to the subnet.

Question 16

An organization uses Terraform Cloud with VCS-driven runs. They have two workspaces: network and application. They want a new run in the application workspace to automatically trigger whenever the network workspace completes a successful plan. What should they configure?

Accepted Answer

Run triggers in the application workspace pointing to the network workspace.. Run triggers in Terraform Cloud allow one workspace to automatically queue a run in another workspace after a successful plan. By configuring a run trigger in the application workspace that points to the network workspace, any successful plan in the network workspace will automatically initiate a new run in the application workspace, satisfying the requirement without external tools or manual steps.

Answer

A webhook from Terraform Cloud to an external CI system.

Answer

Use 'terraform apply' with '-target' to simulate dependency.

Answer

Run triggers in the network workspace pointing to the application workspace.

Question 17

A company uses Terraform workspaces to manage environments. They have a monorepo with separate configurations for each environment. They want to introduce a new team that will manage only the staging environment. The new team will run terraform commands only on the staging workspace. They are using a single S3 backend for all workspaces. The team is concerned about accidentally applying changes to other workspaces. What is the best way to restrict the team's access?

Accepted Answer

Use Terraform Cloud with team-based permissions.. Terraform Cloud provides native workspace-level permissions, allowing you to grant the new team access only to the staging workspace while preventing them from applying changes to other workspaces. This is the most secure and manageable approach, as it leverages Terraform Cloud's RBAC (Role-Based Access Control) to enforce separation of duties without modifying the backend configuration or relying on error-prone manual processes.

Answer

Create a separate S3 bucket for staging and configure a different backend.

Answer

Use terraform workspace select staging in the CI/CD pipeline and only allow that.

Answer

Use IAM policies to restrict access to the state files of other workspaces.

Question 18

A module defines an input variable with 'sensitive = true'. The root module tries to use that variable in an output block. What happens when running 'terraform apply'?

Accepted Answer

The output value is hidden in the CLI output but still available in the state.. When a variable is marked `sensitive = true`, Terraform prevents its value from being displayed in CLI output for any output that references it. However, the value is still stored in the state file and can be used within the module. Therefore, `terraform apply` succeeds, but the output value is hidden in the CLI output while remaining available in the state.

Answer

The apply fails with an error because sensitive variables cannot be used in outputs.

Answer

The output is displayed normally because outputs are always visible.

Answer

The output is removed from the plan entirely to protect the sensitive value.

Question 19

Which module source type does NOT support version constraints?

Accepted Answer

Local path. Local path module sources (e.g., `./modules/foo`) and HTTP URL sources (e.g., `https://example.com/module.tar.gz`) do not support version constraints because there is no remote registry or repository to resolve a version from. Terraform uses the local filesystem path or downloads the HTTP URL directly, so the `version` argument in a `module` block is ignored for these source types. In contrast, Git repositories and the Terraform Registry both support version constraints via their respective resolution mechanisms.

Answer

Git repository

Answer

Terraform Registry

Question 20

What is the correct way to resolve this provider version conflict?

Accepted Answer

Change the root module's required version to ~> 2.70.. The root module's required_providers version constraint must be compatible with the version constraints declared in any child modules. The error indicates the root module requires a provider version that conflicts with the consul module's constraint (e.g., ~> 2.70). Changing the root constraint to ~> 2.70 aligns it with the child module, satisfying Terraform's version resolution logic during `terraform init`.

Answer

Ignore the module's required_providers and force install the root version.

Answer

Remove the required_providers block from the root module.

Answer

Manually edit the .terraform/modules/consul/main.tf to change the version.