TF-004 Practice Test 31 — 15 Questions

Question 1

A DevOps team manages infrastructure for a large e-commerce platform using Terraform with a remote backend in an S3 bucket with DynamoDB state locking. Recently, a team member ran `terraform apply` from their local machine but the command failed with the error: 'Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed'. The state file is not locked according to the DynamoDB table. After investigation, the team finds that the DynamoDB table has a TTL attribute enabled on the 'LockID' field, and old lock records are automatically deleted after a few minutes. The team suspects that another engineer's `terraform plan` process from a CI/CD pipeline might have created a lock that was subsequently deleted by TTL before it was released, causing the conflict. Which action should the team take to prevent this issue from recurring?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Disable the TTL attribute on the DynamoDB table that stores lock information.. The error occurs because the DynamoDB table has a TTL attribute that automatically deletes lock records before the lock is released. Disabling TTL on the DynamoDB table ensures lock records persist until the lock is intentionally released, preventing false lock conflicts. Option A is incorrect because local state eliminates locking and central management. Option C is incorrect because increasing TTL only delays deletion but does not guarantee the lock won't be deleted during a long-running operation. Option D is incorrect because force-unlock is a manual recovery step, not a preventive measure.

Answer

Switch to using local state files to avoid the locking issue entirely.

Answer

Increase the TTL value to 24 hours to ensure locks are not deleted during normal operations.

Answer

Use `terraform force-unlock` before each `terraform apply` to clear any stale locks.

Question 2

You are a DevOps engineer at a growing startup. The infrastructure currently consists of a single AWS EC2 instance running a web application, manually configured. The company plans to scale to multiple instances and environments (development, staging, production). They want to adopt Infrastructure as Code using Terraform. The team has limited experience with Terraform and wants to start small, then gradually adopt more advanced features. The current manual infrastructure must be imported into Terraform. The team also wants to ensure that code changes are reviewed via pull requests before being applied. Which of the following is the best course of action to meet these requirements?

Accepted Answer

Create a Git repository with a main branch. Write a minimal Terraform configuration that describes the existing EC2 instance. Use terraform import to bring the instance under Terraform management. Store the state file remotely in S3 with DynamoDB locking. Set up a CI pipeline that runs terraform plan on pull requests and requires approval before merging.. It follows the best practices for adopting Infrastructure as Code with Terraform in a team setting. It starts by writing a minimal configuration that matches the existing EC2 instance, uses `terraform import` to bring it under management without downtime, stores state remotely in S3 with DynamoDB locking for collaboration and consistency, and sets up a CI pipeline to run `terraform plan` on pull requests with approval gates, ensuring code review before changes are applied.

Answer

Install Terraform on the existing instance, run terraform init and apply directly to manage it, and store state locally. Have team members share the state file via a shared folder.

Answer

Write Terraform configuration from scratch to match the existing instance, but do not import; instead, destroy the old instance and recreate it with Terraform.

Answer

Create separate Git branches for each environment (dev, staging, prod) and have each team member work independently on their branch, merging occasionally.

Question 3

A Terraform plan shows that an AWS EC2 instance will be destroyed and recreated. The team wants to ensure zero downtime during the update. Which lifecycle attribute should be added?

Accepted Answer

create_before_destroy. `create_before_destroy` is a lifecycle attribute that instructs Terraform to create the replacement resource first, then destroy the old one. This ensures that the new EC2 instance is fully operational before the original is terminated, achieving zero downtime during the update.

Answer

depends_on

Answer

ignore_changes

Answer

prevent_destroy

Question 4

A company uses Terraform to deploy virtual machines. They want to ensure that the same exact operating system and software versions are used every time. Which practice supports this?

Accepted Answer

Using a golden image and referencing it in the configuration. Using a golden image—a pre-configured virtual machine template containing the exact operating system and software versions—ensures consistency across deployments. Terraform can reference this image via the `source_image` or `image_id` argument in a resource like `azurerm_virtual_machine` or `aws_instance`, guaranteeing that every provisioned VM starts from the same immutable baseline.

Answer

Manually installing software

Answer

Using inline userdata scripts

Answer

Running configuration management after provisioning

Question 5

Which Terraform command is used to validate the syntax of configuration files without accessing any cloud provider?

Accepted Answer

terraform validate. `terraform validate` checks syntax and internal consistency of configuration files. `init` initializes backends and providers, `plan` accesses remote state, `fmt` formats code.

Answer

terraform fmt

Answer

terraform plan

Answer

terraform init

Question 6

A team is using a module from the Terraform Registry and wants to ensure they always get the latest patch version of the 3.2.x series. Which version constraint should they use?

Accepted Answer

~> 3.2.0. The `~>` (pessimistic constraint) operator in Terraform allows only the rightmost version component to increment. For `~> 3.2.0`, this means any version >= 3.2.0 and < 3.3.0, which precisely matches the requirement for the latest patch within the 3.2.x series. Option C is correct because it locks the major and minor versions while permitting patch-level updates.

Answer

~> 3.2

Answer

3.2.*

Answer

>= 3.2, < 4.0

Question 7

A company has a Terraform configuration that creates many AWS resources. They want to check the estimated cost of the plan before applying. Which approach should they use?

Accepted Answer

Enable cost estimation in Terraform Cloud.. Terraform Cloud provides a built-in cost estimation feature that analyzes the resources in a plan against current cloud provider pricing APIs to estimate monthly costs. This is the recommended approach because it is integrated directly into the Terraform workflow and does not require manual parsing or external scripts. Option C is correct because it leverages Terraform Cloud's native capability to estimate costs before applying.

Answer

Use 'terraform plan -cost' command.

Answer

Manually use 'terraform show -json' and parse pricing.

Answer

Use 'terraform validate' with a custom script.

Question 8

A team wants to import an existing AWS S3 bucket named 'my-bucket' into Terraform state. The resource block is defined as 'aws_s3_bucket.my_bucket'. Which command should be used?

Accepted Answer

terraform import aws_s3_bucket.my_bucket my-bucket. The correct syntax for `terraform import` is `terraform import `, where the resource address is the Terraform resource block identifier (e.g., `aws_s3_bucket.my_bucket`) and the ID is the actual AWS resource identifier (e.g., the bucket name `my-bucket`). Option C follows this exact order: `terraform import aws_s3_bucket.my_bucket my-bucket`, making it the correct command to import the existing S3 bucket into Terraform state.

Answer

terraform import my-bucket aws_s3_bucket.my_bucket

Answer

terraform import 'aws_s3_bucket.my_bucket' 'my-bucket'

Answer

terraform import aws_s3_bucket.my-bucket my-bucket

Question 9

A team uses a remote backend (S3) with state locking via DynamoDB. One team member runs terraform apply and it fails mid-way. Another team member immediately tries to run terraform plan. What is likely to happen?

Accepted Answer

The plan will fail with an error indicating the state is locked.. Terraform's remote backend with DynamoDB state locking acquires a lock at the start of `terraform apply` and does not release it until the operation completes or is explicitly unlocked. If the apply fails mid-way, the lock remains held (it is not automatically released on failure). Therefore, when another team member immediately runs `terraform plan`, the plan command will attempt to acquire the lock, fail, and return an error indicating the state is locked.

Answer

The plan will run successfully because the lock is automatically released after failure.

Answer

The plan will run but the state file will be corrupted.

Answer

The plan will run successfully and show any partial changes.

Question 10

An organization uses Terraform Cloud for team collaboration. They have a workspace that manages production infrastructure. Due to a security policy, they must ensure that all changes go through a peer review process before they are applied. How can they enforce this requirement?

Accepted Answer

Enable 'apply on merge' and set the workspace to require approval before applying.. Enabling 'apply on merge' combined with requiring approval before applying enforces a peer review process: changes must be merged via a VCS pull request (triggering the plan), and then a separate approval step is needed before Terraform Cloud applies the changes. This ensures that no change is applied without explicit human approval after the plan is reviewed.

Answer

Require all changes to be submitted via a VCS pull request.

Answer

Use run triggers to automatically apply after a successful plan in another workspace.

Answer

Lock the workspace and only unlock it for approved changes.

Question 11

A junior DevOps engineer is asked to explain the primary purpose of Terraform. Which statement best describes Terraform's purpose?

Accepted Answer

Terraform is an infrastructure provisioning tool that manages cloud and on-premises resources using declarative configuration.. Terraform is an infrastructure provisioning tool that uses declarative configuration (HashiCorp Configuration Language, HCL) to define and manage both cloud and on-premises resources. Its primary purpose is to provision infrastructure—such as virtual machines, networks, and storage—across multiple providers (e.g., AWS, Azure, GCP) by maintaining a desired state and applying changes via execution plans. Unlike configuration management or scripting tools, Terraform focuses on the lifecycle of infrastructure resources, not on configuring software within those resources.

Answer

Terraform is a monitoring tool that tracks infrastructure changes.

Answer

Terraform is a scripting tool for automating manual tasks in cloud environments.

Answer

Terraform is a configuration management tool that installs and configures software on servers.

Question 12

A company wants to use Terraform to manage resources across AWS and Azure. They need a single workflow that can apply changes to both providers. What is the best practice?

Accepted Answer

Define both providers in a single configuration. Terraform allows multiple providers to be defined in a single configuration, enabling a unified workflow to manage resources across AWS and Azure. By declaring both providers in the same root module, a single `terraform apply` can create, update, or destroy resources from both clouds in the correct order, leveraging Terraform's dependency graph to handle cross-provider dependencies. This is the recommended best practice for multi-cloud management with a single workflow.

Answer

Use separate Terraform configurations for each provider

Answer

Use Terraform Cloud workspaces with different providers

Answer

Use Terraform workspaces to separate providers

Question 13

Refer to the exhibit. A user has this backend configuration. The user then runs `terraform init` and receives an error: 'NoSuchBucket: The specified bucket does not exist'. What is the most likely cause?

Accepted Answer

The bucket does not exist and needs to be created.. The error 'NoSuchBucket: The specified bucket does not exist' directly indicates that the S3 bucket referenced in the backend configuration does not exist in the AWS account. Terraform requires the S3 bucket to already exist before running `terraform init` because it needs to store the state file; it does not create the bucket automatically. Therefore, the most likely cause is that the bucket has not been created yet.

Answer

The AWS region is wrong.

Answer

The DynamoDB table is missing.

Answer

The credentials lack S3 permissions.

Question 14

Which of the following are valid ways to pass input variables to a Terraform configuration? (Select all that apply.)

Accepted Answer

Use the '-var' flag on the command line to set a single variable.. Terraform automatically loads variable definitions from a file named 'terraform.tfvars' (or 'terraform.tfvars.json') in the current directory when you run a plan or apply. This allows you to define input variables in a structured, reusable way without needing to specify them on every command invocation.

Question 15

After running 'terraform apply', the user sees that the 'aws_s3_bucket_object' is created successfully, but the bucket name is not as expected. What is the most likely reason?

Accepted Answer

The output 'bucket_name' in the module is set to 'aws_s3_bucket.this.id', which is the bucket name, so the bucket name should be as expected.. The module output 'bucket_name' is defined as 'aws_s3_bucket.this.id', and in Terraform, the 'id' attribute of an 'aws_s3_bucket' resource is exactly the bucket name (not a generated ID). Since the user sees the object created successfully, the module is being called and the output is correctly referencing the bucket name, so the bucket name should be as expected. The question implies the user's expectation is wrong or the bucket name is actually correct, making D the only statement that aligns with Terraform's behavior.

Answer

The module variable 'bucket_name' is not consumed by the resource; the resource uses a hardcoded name.

Answer

The module output is incorrectly defined; it should use 'bucket' attribute instead of 'id'.

Answer

The module does not have an output for the bucket name, so the reference fails silently.