TF-003 Practice Test 37 — 15 Questions

Question 1

Your organization uses Terraform Cloud with a remote execution mode. There are two workspaces: `app-prod` and `app-staging`. The state for `app-prod` is stored in the `prod` workspace, and `app-staging` in the `staging` workspace. Recently, a new developer joined the team and tried to run `terraform plan` locally for the `app-staging` workspace. They received an error: "S3Backend bucket 'my-company-tf-state' does not exist." The developer is not using Terraform Cloud locally. The team uses a remote backend configuration with Terraform Cloud. What is the most likely cause?

Accepted Answer

The developer is running Terraform locally without having the correct backend configuration; they should run `terraform init -reconfigure` to reinitialize backend settings for local execution. If the developer is running Terraform locally without Terraform Cloud, they need to reconfigure the backend to local state or use the remote backend properly. Option D correctly identifies that the developer should use `terraform init -reconfigure` to set up the remote backend locally.

Answer

The developer forgot to run `terraform workspace select staging`

Answer

The Terraform Cloud workspace `app-staging` is not set to use remote state

Answer

The developer lacks AWS credentials to access the S3 bucket

Question 2

A company manages multiple microservices across AWS accounts. Each service has its own Terraform configuration and state file stored in a shared S3 bucket. The team uses `terraform_remote_state` data sources to read outputs from other services' state files. A service team recently changed the output structure in their state, breaking the `terraform_remote_state` calls from other services. The affected services now show errors during plan. What is the best practice to avoid such cross-service dependency issues?

Accepted Answer

Publish service outputs to a dedicated data store (e.g., AWS SSM Parameter Store or Consul) and have other services consume those values instead of reading state directly. Cloud-native integration patterns with explicit contracts (like SSM Parameter Store) are more robust than raw state reading. Option D is correct.

Answer

Use versioning on the S3 bucket and revert to a previous state version

Answer

Lock the state files and require approval for any changes

Answer

Store outputs in a configuration management database and read from there

Question 3

A team manages a multi-tier application consisting of web servers, application servers, and databases deployed across AWS and Azure. Historically, they have provisioned infrastructure manually using cloud consoles and ad-hoc scripts. To improve consistency and reduce errors, they decide to adopt Terraform for Infrastructure as Code. After initial rollout, they encounter problems: some team members still make direct changes via the cloud console to quickly fix issues, causing configuration drift between the Terraform state and actual resources. They also need to manage three distinct environments (development, staging, production) with different configurations (e.g., instance sizes, database settings). The team consists of five people with a limited budget for additional tools. Which course of action best addresses these challenges while adhering to IaC principles?

Accepted Answer

Implement a CI/CD pipeline that runs terraform plan and apply automatically on merges to the main branch, and use Terraform Cloud's Sentinel policies to prevent drift.. Option C is correct because implementing CI/CD with automated plan/apply and using Sentinel policies to prevent drift directly addresses both issues: drift from manual changes and environment management. Option A helps with environment separation but doesn't prevent drift; IAM policies can restrict console changes but are not part of IaC best practices. Option B improves state management but local applies can still lead to drift. Option D uses provider aliases which are not designed for environment separation, and manual planning does not prevent drift.

Answer

Store Terraform state in a shared S3 bucket with DynamoDB locking, and have each team member apply their own changes locally after review.

Answer

Use Terraform workspaces to manage environments and enforce that all changes go through version-controlled Terraform configs, disabling direct console changes via IAM policies.

Answer

Assign each environment to a different Terraform provider alias and use manual planning to ensure correctness.

Question 4

A company uses Terraform to manage infrastructure across dev, staging, and production environments. They use Terraform workspaces to separate state files. The backend is configured with an S3 bucket for state storage and a DynamoDB table for state locking. Recently, the team has grown from 2 to 10 developers, and they frequently encounter the error: 'Error acquiring the state lock' when running terraform apply in quick succession. The error message includes: 'Lock Info: ID: ... Operation: Apply. Who: user@company.com. Version: 1.0.0. Created: ...' The error occurs intermittently, especially during peak deployment times. The DynamoDB table is configured with 5 read and 5 write capacity units. The team's current workflow involves multiple developers running apply on different workspaces simultaneously. Which course of action should the team take to minimize state locking errors?

Accepted Answer

Increase the DynamoDB table's write capacity units to a higher value.. Increasing DynamoDB write capacity reduces contention and lock acquisition failures during concurrent applies. Option B (implementing a pre-apply hook) is not standard and could add complexity. Options A and D disable locking, which is dangerous.

Answer

Disable state locking to eliminate the error.

Answer

Use a different backend that does not support locking, such as local state.

Answer

Implement a pre-apply hook that checks if the state is already locked and waits.

Question 5

A DevOps engineer is managing a multi-cloud infrastructure using Terraform. The team relies on a module sourced from the Terraform Registry to deploy a standard web application. This module defines an input variable called 'instance_count' with a default value of 2. For the production environment, the engineer wants to deploy 3 instances. They create a root module configuration that references the module. In the root module's main.tf, they write a block that sets instance_count = 3. However, when they run terraform plan, the output indicates that the module will still use instance_count = 2. The engineer double-checks the configuration: the root module's main.tf is syntactically correct, the module source points to the correct registry module and version, and they have run terraform init and terraform validate without errors. What is the most likely reason the variable override is not taking effect?

Accepted Answer

The root module defines instance_count as a local value rather than passing it as an argument to the module block.. Option B is correct because the most common mistake is defining the variable as a local value rather than passing it as an argument to the module block. Option A is incorrect because the variable exists in the module (it has a default). Option C is incorrect because terraform init is not required for variable changes; terraform validate passed, so syntax is fine. Option D is incorrect because module version does not affect variable overrides.

Answer

The module version specified does not support variable overrides; the engineer must use a different module.

Answer

The variable 'instance_count' is not declared as an input variable in the child module's variables.tf.

Answer

The engineer forgot to run terraform init after modifying the root module's configuration.

Question 6

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

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

A developer is reviewing a terraform plan output and sees that a resource of type "aws_instance" with name "web" will be updated. The developer expected no changes because the configuration hasn't been modified. The instance was manually resized in the AWS console by another team. The developer wants to reconcile the state without destroying the instance. What should they do?

Accepted Answer

Run terraform apply -refresh-only to update the state to match reality.. Option A is correct because `terraform apply -refresh-only` updates the Terraform state to match the actual infrastructure without making any configuration changes. This command reads the current state of the `aws_instance.web` resource from AWS and writes it to the state file, reconciling the drift caused by the manual resize. It does not destroy or recreate the instance, preserving the existing resource.

Answer

Run terraform state rm aws_instance.web and then terraform import.

Answer

Manually edit the state file to match the instance attributes.

Answer

Run terraform apply with -target=aws_instance.web to update only that resource.

Question 8

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 9

You are a platform engineer at a large e-commerce company that uses Terraform Enterprise to manage thousands of infrastructure resources across multiple teams. The company has a central 'networking' workspace that provisions shared VPCs and subnets, and several application workspaces that consume these networking resources via remote state data sources. Recently, the networking team changed the CIDR block of a shared subnet from '10.0.1.0/24' to '10.0.2.0/24' and applied the change successfully. However, the application teams are now reporting that their Terraform runs are failing with errors indicating that the subnet ID they reference does not exist. The application workspaces use the following configuration to consume the subnet:

```hcl
data "terraform_remote_state" "networking" {
  backend = "remote"
  config = {
    organization = "mycompany"
    workspaces = {
      name = "networking"
    }
  }
}

resource "aws_instance" "app" {
  subnet_id = data.terraform_remote_state.networking.outputs.subnet_id
  ...
}
```

The application workspaces have not been modified recently. The networking workspace output 'subnet_id' now contains the ID of the updated subnet. What is the most likely cause of the failures?

Accepted Answer

The application workspaces are using a cached version of the remote state outputs and need to run 'terraform plan' to refresh.. Option C is correct because Terraform caches remote state data during the planning phase, and the `terraform_remote_state` data source only fetches the latest state when `terraform plan` or `terraform apply` is executed. Since the application workspaces have not been modified or re-planned, they are using a stale cached version of the networking workspace's outputs, which still contains the old subnet ID. Running `terraform plan` forces a refresh of the remote state data, retrieving the updated `subnet_id` and resolving the error.

Answer

The application workspaces do not have permission to read the networking workspace's state.

Answer

The networking workspace output variable 'subnet_id' was removed or renamed.

Answer

The application workspaces need to update the remote state data source to reference the new subnet ID.

Question 10

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

A company manages a microservices application across multiple AWS accounts using Terraform. They have a dedicated 'infrastructure' repository with Terraform configurations for each account. The team recently migrated their Terraform state to a centralized S3 backend with DynamoDB locking. After the migration, they notice that when two developers run `terraform apply` simultaneously in the same workspace, one of them receives a lock error, but the other proceeds normally. The team wants to ensure that only one apply runs at a time across all workspaces. However, they also need to allow concurrent operations on different workspaces. The current backend configuration uses a single DynamoDB table for all workspaces. What should the team do to achieve their goals?

Accepted Answer

Use a separate DynamoDB table for each workspace to isolate locks. The problem is that using a single DynamoDB table with a single lock key means all workspaces share the same lock, preventing concurrent applies on different workspaces. Option D is correct: Use a separate DynamoDB table for each workspace, which isolates locks per workspace. Option A is dangerous. Option B does not solve the cross-workspace contention because the lock key is shared. Option C loses centralized state.

Answer

Use a single DynamoDB table but increase the lock timeout

Answer

Remove the backend configuration and use local state with manual locking

Answer

Disable locking to allow parallel operations

Question 12

A company manages multiple AWS accounts using Terraform. They have a central repository where all Terraform configurations are stored. Recently, a developer accidentally ran terraform destroy on a production workspace and deleted critical resources. The team wants to implement safeguards to prevent such incidents while still allowing developers to test changes in non-production environments. They currently use Terraform Cloud for remote state management and runs. Which course of action should the team take to minimize risk?

Accepted Answer

Implement run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production'.. Option A is correct because Terraform Cloud run tasks can enforce approval workflows for destroy operations on production workspaces. Option B is wrong because removing API access entirely is too restrictive and hinders legitimate operations. Option C is wrong because storing state locally goes against best practices and is insecure. Option D is wrong because prevent_destroy is a meta-argument that blocks all destroy operations, not just accidental ones, and is not a flexible safeguard.

Answer

Store the production Terraform state file locally and restrict access to it.

Answer

Use Terraform's built-in lifecycle prevent_destroy on all production resources.

Answer

Remove all developers' access to the Terraform Cloud API and only allow operations via pull requests.

Question 13

Your company manages infrastructure for multiple environments (dev, staging, prod) using Terraform. You have a shared networking module stored in a private Git repository. The module is used by several root configurations. The current workflow requires developers to manually update the module version in each root module's source attribute when a new version is tagged. This has led to configuration drift and occasional use of incompatible module versions. You want to implement a more reliable approach that ensures all environments use the same consistent version of the module, while still allowing controlled upgrades. Which approach best addresses this concern?

Accepted Answer

Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready.. Option D is correct because it uses a version constraint (e.g., `~> 1.2`) to allow automatic patch-level updates while preventing major or minor breaking changes, and it enforces a coordinated workflow where all root modules update the constraint simultaneously. This eliminates configuration drift and ensures consistent module versions across environments, while still enabling controlled upgrades. The approach leverages Terraform's built-in version constraint syntax to balance consistency with flexibility.

Answer

Publish the module to the public Terraform Registry and use a version constraint in each root module.

Answer

Pin each root module to a specific Git tag (e.g., ref=v1.2.3) and manually update each root module when a new tag is created.

Answer

Remove the version constraint from the module source so that Terraform always fetches the latest commit from the default branch.

Question 14

You are a platform engineer at a large enterprise that uses Terraform Cloud with a VCS-backed workflow for all infrastructure. Your team manages a configuration that provisions AWS EC2 instances for a critical application. Recently, a junior team member accidentally committed a change that removed a required tag from the EC2 instance resource. The change passed the plan stage but was blocked by a Sentinel policy during the apply, preventing the infrastructure from being updated. The team needs to fix the configuration and apply the change. However, the repository is configured to automatically trigger runs on every push to the main branch. The team wants to avoid triggering an unwanted run while they work on the fix. What should the team do?

Accepted Answer

Create a feature branch, fix the configuration, and merge via pull request. Option C is correct because using a feature branch and pull request allows the team to fix the configuration without triggering a run on the main branch, since Terraform Cloud’s VCS integration only auto-triggers runs on pushes to the configured branch (typically main). Once the fix is merged via pull request, the change will be applied through the normal VCS-backed workflow, maintaining audit trails and policy enforcement. This approach avoids disrupting the VCS connection or bypassing Terraform Cloud’s governance.

Answer

Temporarily disable the VCS connection in Terraform Cloud to prevent runs

Answer

Run terraform apply locally with the fixed configuration to bypass Terraform Cloud

Answer

Amend the commit on main and force push to overwrite history

Question 15

You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. The team has created a reusable module for deploying an AWS ECS Fargate service. The module accepts variables for environment name, container image tag, and desired count. The module is stored in a private Git repository. The root configurations for each environment are stored in separate directories, each with its own backend configuration. Recently, a developer added a new feature to the module that requires a new variable 'enable_xray' (boolean, default false). After updating the module source to point to the new commit, the developer runs 'terraform init' and 'terraform plan' in the dev environment. The plan shows that the ECS service will be updated, but the output does not show any changes related to X-Ray. The developer expected that setting 'enable_xray = true' in the dev root module would enable X-Ray tracing. However, the plan shows no changes to the task definition. What is the most likely cause?

Accepted Answer

The module does not reference the 'enable_xray' variable in any resource, so setting it has no effect.. Option D is correct because the `enable_xray` variable, even when set to `true` in the root module, will not cause any changes in the plan unless the module's resources actually reference that variable. In Terraform, a variable declared in a module has no effect on infrastructure unless it is used in a resource argument. The developer saw no changes to the task definition because the module's code likely does not include a condition or argument that uses `enable_xray` to enable X-Ray tracing on the ECS task definition.

Answer

The module source was not updated correctly; it still points to the old commit.

Answer

The developer forgot to run 'terraform init' after changing the module source.

Answer

The variable 'enable_xray' is not declared in the module's variables.tf file.