TF-004 Practice Test 10 — 10 Questions

Question 1

What file extension is commonly used for Terraform configuration files?

Accepted Answer

.tf. Terraform uses HashiCorp Configuration Language (HCL) for its configuration files, and the standard file extension for these files is `.tf`. Terraform automatically loads all files ending in `.tf` in a directory as part of its configuration, making `.tf` the primary and required extension for Terraform configuration.

Answer

.json

Answer

.hcl

Answer

.tfstate

Answer

.yaml

Question 2

Which TWO are benefits of using Terraform modules?

Accepted Answer

Encapsulation of complexity, providing a clean interface.. Terraform modules encapsulate complex infrastructure logic into a single, reusable abstraction. By defining input variables and output values, modules provide a clean interface that hides internal resource configurations, making configurations easier to manage and maintain.

Answer

Faster execution of terraform plan and apply.

Answer

Reduction in state file size.

Answer

Enhanced security by automatically encrypting state files.

Question 3

A company uses Terraform with a backend configured to store state in Azure Blob Storage. They want to view the current state of resources without performing a plan or apply. Which command should be used?

Accepted Answer

terraform state list. (terraform state list) is correct because it directly queries the Terraform state file stored in Azure Blob Storage and lists all resources tracked in that state without triggering a plan or apply. This command is part of the 'terraform state' family, designed specifically for inspecting state outside the core workflow, and it requires no infrastructure changes or API calls to cloud providers.

Answer

terraform output

Answer

terraform show

Answer

terraform plan

Question 4

After modifying a Terraform configuration file, a user runs 'terraform plan' and sees 'No changes. Infrastructure is up-to-date.' What is the most likely reason?

Accepted Answer

The configuration changes were made in a different directory.. Terraform operates on the configuration files in the current working directory. If the user modified a Terraform configuration file in a different directory and then ran 'terraform plan' from the original directory, Terraform would compare the state against the unchanged configuration in the current directory, resulting in 'No changes. Infrastructure is up-to-date.'

Answer

The user forgot to run terraform init.

Answer

The configuration changes were not committed to version control.

Answer

The state is stored remotely and the user does not have access.

Question 5

Refer to the exhibit. A team member receives this error when running terraform apply. What is the most likely cause?

Accepted Answer

A previous Terraform process was terminated abruptly, leaving a stale lock.. The lock info shows an operation type "OperationTypeInvalid", which typically occurs when a previous Terraform process was terminated abruptly (e.g., Ctrl+C, crash), leaving the lock in place.

Answer

The state file is corrupted and needs to be restored from backup.

Answer

Another user is currently running terraform apply on the same state.

Answer

The S3 bucket containing the state has been deleted.

Question 6

An organization uses Terraform workspaces to manage multiple environments (dev, staging, prod). They notice that terraform plan in the prod workspace unexpectedly shows changes to a resource that should be identical across workspaces. The resource uses a backend that stores state in an S3 bucket. What is the most likely cause?

Accepted Answer

The terraform.workspace variable is used in the resource configuration.. If the `terraform.workspace` variable is used directly in a resource configuration (e.g., in a name, tag, or identifier), the resource definition will differ between workspaces. Since the prod workspace has a different workspace name than dev, the plan will show changes to resources that are otherwise identical, as Terraform detects the difference in the interpolated value.

Answer

The prod workspace was created by copying the dev workspace state.

Answer

The S3 bucket does not support versioning.

Answer

The provider version differs between workspaces.

Question 7

Which two of the following are correct statements about Terraform providers?

Accepted Answer

Providers are plugins that Terraform uses to manage resources.. Terraform providers are plugins that enable Terraform to manage resources for a specific cloud or service (e.g., AWS, Azure). They can be sourced from the Terraform Registry or other locations. The correct statements are B and C. A is incorrect because a provider is not required in every configuration; some configurations may use only data sources or child modules that already have providers defined. D is incorrect because multiple providers can be used in a single configuration to manage resources across different platforms. E is incorrect because providers are installed by `terraform init`, not `terraform plan`.

Answer

A provider must be defined in every Terraform configuration.

Answer

Only one provider can be used per configuration.

Answer

Providers are automatically installed by terraform plan.

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

Question 10

Refer to the exhibit. What does the output indicate?

Accepted Answer

The state file tracks three resources. The `terraform state list` command lists all resources currently tracked in the state file. Here it shows three resources: a VPC, a subnet, and an EC2 instance.

Answer

The Terraform configuration defines three resources

Answer

Three providers are configured

Answer

Three workspaces are in use

Answer

The plan will create three resources