TF-004 Practice Test 22 — 15 Questions

Question 1

Match each Terraform command to its primary function.

Accepted Answer

terraform init: Initializes a working directory containing Terraform configuration files. The correct matches are: init initializes the workspace, plan creates an execution plan, apply executes changes, destroy tears down resources. Common mistakes include confusing init with apply or plan with destroy.

Answer

terraform init: Applies changes to infrastructure

Answer

terraform plan: Destroys all resources

Question 2

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 3

Which TWO module source types are supported by Terraform natively?

Accepted Answer

Terraform Registry (e.g., hashicorp/consul/aws). Terraform natively supports the Terraform Registry as a module source, so option A (e.g., hashicorp/consul/aws) is correct because the registry is the canonical public/private module source addressed with the // syntax. Option C (local file paths such as ./modules/vpc) is also correct because Terraform accepts relative or absolute filesystem paths as module sources, including the ./ and ../ prefixes. The other options do not belong: Docker Hub repositories (B) are container image registries, not Terraform module sources; Jenkins plugin repositories (D) distribute Jenkins plugins; and npm packages (E) are Node.js packages, none of which Terraform resolves as module sources.

Answer

Docker Hub repositories

Answer

Jenkins plugin repository

Answer

npm packages

Question 4

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 5

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

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 9

You are a DevOps engineer at a large e-commerce company. The infrastructure team uses Terraform to manage AWS resources across multiple accounts. Recently, they introduced a new module that creates an S3 bucket with a bucket policy. The module is used in several environments (dev, staging, prod). After merging a pull request that updates the bucket policy to grant cross-account access to a new partner account, the 'terraform apply' in the dev environment fails with: 'Error: Error putting S3 policy: AccessDenied: Access Denied'. The team is using a remote backend (S3) with DynamoDB locking. The CI/CD pipeline runs as an IAM role with permissions to manage infrastructure. The module uses 'aws_iam_policy_document' data source to construct the policy. The error occurs only in dev, not staging or prod. What is the most likely cause and the correct course of action?

Accepted Answer

Check the IAM permissions associated with the dev environment's role to ensure it has 's3:PutBucketPolicy' on the bucket.. The error 'AccessDenied' when calling 's3:PutBucketPolicy' indicates the IAM role used by the CI/CD pipeline in the dev environment lacks the necessary permission to apply the bucket policy. The module uses 'aws_iam_policy_document' to construct the policy, which is validated at plan time, so syntax errors would surface earlier. The fact that the error occurs only in dev, not staging or prod, points to an environment-specific IAM permissions issue rather than a policy syntax or state locking problem.

Answer

Verify that DynamoDB state locking is not causing the error.

Answer

Run 'terraform validate' to check the policy document syntax.

Answer

Check the bucket policy for syntax errors by comparing with staging and prod.

Question 10

Which TWO actions are part of the core Terraform workflow? (Select TWO.)

Accepted Answer

Write Terraform configuration files. The core Terraform workflow consists of three main steps: Write, Plan, and Apply. Option B (Write Terraform configuration files) is correct because authoring HCL configuration that defines the desired infrastructure is the foundational first step of the workflow. Option C (Review the execution plan) is correct because running terraform plan and reviewing the proposed changes is the second core step, allowing you to verify what Terraform will create, modify, or destroy before applying. Option A is incorrect because Terraform is a declarative IaC tool; manually creating resources in a cloud console bypasses Terraform's state and workflow entirely. Option D is incorrect because committing to version control, while a best practice, is not a defined step of the core Terraform workflow itself. Option E is incorrect because running unit tests on configuration is a supplementary validation practice, not one of the core workflow stages of write, plan, and apply.

Answer

Create infrastructure manually via cloud console

Answer

Commit changes to version control

Answer

Run unit tests on the configuration

Question 11

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 12

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

Question 13

What is the purpose of the 'terraform validate' command?

Accepted Answer

To check syntax and internal consistency of configuration files.. The 'terraform validate' command checks the syntax and internal consistency of Terraform configuration files, ensuring that the code is syntactically valid and that references between resources, data sources, and variables are correctly formed. It does not interact with providers or cloud APIs, so it cannot verify credentials or run tests.

Answer

To check the validity of provider credentials.

Answer

To format Terraform configuration files.

Answer

To run unit tests on Terraform modules.

Question 14

Drag and drop the steps to upgrade Terraform providers in a configuration in the correct order.

Accepted Answer

Check current provider versions, then update version constraints, then run terraform init to upgrade, then run terraform plan to validate.. The correct sequence for upgrading Terraform providers is: first check current provider versions to establish a baseline, then update version constraints in the configuration to target the desired versions, then run terraform init to download and install those versions, and finally run terraform plan to verify that the upgrade does not introduce unexpected changes. This order ensures a controlled and validated upgrade process.

Answer

Check current provider versions, then run terraform init to upgrade, then update version constraints, then run terraform plan to validate.

Answer

Update version constraints, then check current provider versions, then run terraform init to upgrade, then run terraform plan to validate.

Answer

Check current provider versions, then update version constraints, then run terraform plan to validate, then run terraform init to upgrade.

Question 15

A Terraform state file is stored in an S3 bucket with versioning enabled. During a deployment, the state file becomes corrupted due to a network error. What is the best way to recover?

Accepted Answer

Restore the previous version of the state file from S3 versioning.. S3 versioning preserves previous versions of objects, including Terraform state files. When the current state file becomes corrupted, you can restore a prior, uncorrupted version directly from the S3 bucket without data loss or manual re-creation of resources. This is the safest and most efficient recovery method.

Answer

Use `terraform state pull` to overwrite the corrupted state.

Answer

Run `terraform import` to import all resources.

Answer

Delete the state file and run `terraform apply` to recreate all resources.