TF-004 Practice Test 25 — 15 Questions

Question 1

A company uses Terraform Cloud and wants to enforce policy checks before any apply. They have a set of Sentinel policies. Where should they configure these policies to run automatically on all runs?

Accepted Answer

Create a Policy Set in Terraform Cloud and attach to workspaces.. Terraform Cloud uses Policy Sets to group Sentinel policies and enforce them automatically on all runs for attached workspaces. When a Policy Set is associated with one or more workspaces, the policies are evaluated during the plan phase before any apply, blocking the run if any policy fails. This is the native mechanism in Terraform Cloud for automated policy enforcement without manual intervention.

Answer

In the terraform apply command with -policy flag.

Answer

Configure a webhook in the VCS to run policy checks.

Answer

Deploy a Terraform Enterprise instance with custom policy.

Question 2

A Terraform configuration uses a module from the public registry. After a provider update, the module's resources fail to create. What is the most probable cause?

Accepted Answer

The module is incompatible with the new provider version. C is correct because modules from the public registry often declare a `required_providers` block with version constraints. When the provider is updated outside those constraints (e.g., from v3.x to v4.x), the module may rely on deprecated attributes or changed resource schemas, causing resource creation to fail. Terraform will not automatically adjust module code to match provider API changes.

Answer

The provider binary is corrupted

Answer

The state file is corrupted

Answer

The backend configuration is incorrect

Question 3

A team uses Terraform with multiple workspaces and wants to automatically trigger a plan when a pull request is opened in their Git repository. They use Terraform Cloud. Which feature enables this?

Accepted Answer

VCS-driven workflow. The VCS-driven workflow in Terraform Cloud automatically triggers a plan when a pull request is opened in a connected Git repository. This is configured by linking a VCS provider (e.g., GitHub, GitLab) to a workspace and enabling speculative plans on pull requests, which allows Terraform Cloud to run a plan without applying changes.

Answer

API-driven workflow

Answer

CLI-driven workflow

Answer

Registry-driven workflow

Question 4

An organization wants to use Terraform to manage resources across multiple accounts and regions, with different team members responsible for different environments. Which Terraform feature helps separate state and configuration for each environment?

Accepted Answer

Workspaces. Workspaces in Terraform allow you to manage multiple distinct sets of infrastructure resources (state files) within the same configuration. By using separate workspaces for each environment (e.g., dev, staging, prod), you can isolate state and configuration without duplicating code, making it the correct feature for this multi-environment scenario.

Answer

Providers

Answer

Modules

Answer

Backends

Question 5

Which TWO statements are correct about Terraform state when using the S3 backend with DynamoDB for state locking?

Accepted Answer

The DynamoDB table must exist before running terraform init. The DynamoDB table must exist before running `terraform init`, because the table is required for state locking and Terraform does not create it automatically. Option B is correct: enabling S3 bucket versioning provides consistency checks and allows recovery from accidental state deletion or corruption. Option C is incorrect: the `key` argument in the backend configuration is mandatory to specify the path for the state file in the S3 bucket. Option D is incorrect: by default, the S3 backend does not encrypt state at rest; encryption must be explicitly enabled using the `encrypt` argument or an environment variable. Option E is incorrect: state locking prevents concurrent writes but does not block read operations; reading the state file is still allowed while it is locked.

Answer

State can be stored without specifying a key in the backend configuration

Answer

State is encrypted at rest by default using SSE

Answer

State locking prevents any read operations on the state file

Question 6

Given the following Terraform configuration:

resource "aws_instance" "example" {
      ami           = "ami-0c55b159cbfafe1f0"
      instance_type = "t2.micro"
    }

If you change the instance_type to "t2.small" and run terraform apply, what will happen?

Accepted Answer

The instance will be modified in-place, potentially causing a reboot.. Modifying an instance's type is an in-place update in Terraform (shown as a tilde ~ in the plan). This update typically requires a stop and start of the instance, which causes a reboot but not a full destroy and recreate. Option A is incorrect because the question does not indicate any missing variables; the configuration is assumed to be valid. Option B is incorrect because a destroy and recreate would be shown as a -/+ in the plan, whereas an instance type change is an in-place update. Option D is incorrect because changing the instance type usually requires a reboot, causing downtime, so there is no 'no downtime' guarantee.

Answer

The plan will fail due to missing variables.

Answer

The instance will be destroyed and recreated.

Answer

The instance type will be changed without downtime.

Question 7

Refer to the exhibit. A user encounters this error while running 'terraform plan'. What is the best course of action?

Accepted Answer

Run 'terraform force-unlock' with the lock ID after verifying no other process holds the lock. The error indicates that the state file is locked, which prevents concurrent operations to avoid corruption. Running 'terraform force-unlock' with the lock ID is the correct recovery step, but only after verifying that no other Terraform process is actively using the state. This command releases the lock from the backend (e.g., S3, Consul, or Terraform Cloud), allowing subsequent plans or applies to proceed.

Answer

Change the backend to local and run plan again

Answer

Delete the state file and run terraform init

Answer

Wait for 5 minutes and retry

Question 8

Which TWO statements about Terraform modules are correct?

Accepted Answer

A module can be called multiple times in the same configuration with different input variables.. Terraform modules can be called multiple times with different input variables, enabling reuse. Option E is correct because module sources can be Git repository URLs with a specific commit SHA (e.g., using `?ref=`). Option A is incorrect because the `count` meta-argument is supported on module blocks in Terraform 0.13 and later. Option B is incorrect because module outputs are not automatically available; they must be referenced explicitly as `module..`. Option C is incorrect because version constraints are optional for reproducibility; they are recommended but not mandatory.

Answer

The count meta-argument is not supported on module blocks.

Answer

Module outputs are automatically available as inputs to other modules in the same configuration.

Answer

Module sources must include a version constraint to ensure reproducibility.

Question 9

A configuration uses variables defined in a 'variables.tf' file. The operator wants to override these variables for a specific run without modifying the file. Which method should they use?

Accepted Answer

Use the '-var' flag with 'terraform plan' or 'terraform apply'.. The `-var` flag on `terraform plan` or `terraform apply` allows operators to override variable values for a single run without modifying any files. This is the correct method because it provides a temporary override that does not persist across runs, unlike file-based or environment variable approaches.

Answer

Edit the state file directly.

Answer

Set environment variables with the same name as the variables.

Answer

Create a 'terraform.tfvars' file.

Question 10

A team is adopting Terraform to manage infrastructure. One requirement is that all configuration changes must be reviewed and approved before being applied. The team wants to ensure that the Terraform state file reflects the actual deployed infrastructure at all times. Which practice should they implement to meet these requirements?

Accepted Answer

Store state remotely and use a version control system with pull requests to review changes before applying.. Storing state remotely (e.g., in S3, Azure Storage, or Terraform Cloud) enables state locking and versioning, which is essential for team collaboration. Using a version control system with pull requests ensures that all configuration changes are reviewed and approved before being applied, meeting the requirement for change control. This combination also ensures the state file accurately reflects deployed infrastructure by preventing concurrent modifications and providing an audit trail.

Answer

Store state locally and use a manual approval process outside of Terraform.

Answer

Store state locally and use a shared network drive for team access.

Answer

Have each team member run terraform apply from their local machine after informal discussion.

Question 11

A user accidentally ran `terraform state rm` on a critical resource, removing it from state but not destroying the actual infrastructure. Later, they need to re-import the resource. Which sequence of commands correctly accomplishes this?

Accepted Answer

`terraform import` using the resource address and ID of the resource. After removal, the resource is unmanaged. `terraform import` re-associates it with state. Option D is the correct sequence.

Answer

`terraform state push` with the original state file

Answer

`terraform plan` and then `terraform apply`

Answer

`terraform refresh` and then `terraform plan`

Question 12

Refer to the exhibit. An engineer runs 'terraform apply' and receives the lock error. After forcing an unlock, what is the most important next step?

Accepted Answer

Check if the previous apply process is still running, and if not, proceed with the new apply.. Force-unlocking should be used with caution. The engineer must verify that the previous operation (the one holding the lock) is no longer running or has completed, otherwise unlocking could cause state corruption. The most important next step is to ensure the previous process is not active.

Answer

Delete the state file and re-import resources.

Answer

Run 'terraform apply' again immediately.

Answer

Modify the backend configuration to disable locking.

Question 13

Which two statements accurately describe the difference between declarative and imperative IaC approaches? (Choose two.)

Accepted Answer

Declarative focuses on the desired outcome, while imperative specifies step-by-step commands. Declarative IaC, as used in Terraform with HCL, allows you to define the desired end state of infrastructure (e.g., 'I want an AWS EC2 instance with AMI ami-0c55b159cbfafe1f0 and instance type t2.micro'), and the tool automatically determines the necessary steps to achieve that state. In contrast, imperative IaC, such as using AWS CLI commands or Ansible playbooks with explicit 'command' modules, requires you to specify each step (e.g., 'run aws ec2 run-instances, then wait, then tag'). This fundamental difference in approach is a core concept in the TF-003 exam.

Answer

Imperative is only used for scripting, not IaC

Answer

Declarative tools are always faster than imperative tools

Answer

Declarative eliminates the need for idempotency

Question 14

A company uses Terraform to manage infrastructure across multiple AWS accounts. They want to use a single S3 bucket to store state files for all accounts, but ensure that state files are isolated per account. What is the best approach?

Accepted Answer

Use separate state files with unique S3 key prefixes per account. Using separate state files with unique S3 key prefixes per account ensures that each AWS account's Terraform state is stored in the same S3 bucket but logically isolated. This approach leverages S3's hierarchical key structure to prevent cross-account state contamination, while still allowing centralized management. Terraform's backend configuration supports dynamic key prefixes (e.g., `key = "account-${var.account_id}/terraform.tfstate"`), enabling per-account isolation without requiring separate buckets or workspaces.

Answer

Use Terraform workspaces with a single state file

Answer

Store all state in the same S3 key

Answer

Use a DynamoDB table with different lock IDs per account

Question 15

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