TF-004 Practice Questions 2 — 50 Questions

Question 1

A developer creates a directory structure with a module located at './modules/networking'. The root configuration references it with source = './modules/networking'. What is the behavior when running terraform init from the root directory?

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

Accepted Answer

Terraform uses the module directly from the local filesystem.. When a module source is a relative path like './modules/networking', Terraform interprets it as a local filesystem path. During `terraform init`, Terraform reads the module directly from the specified directory without any network access, downloading, or registry interaction. This is the standard behavior for local module references in Terraform.

Answer

Terraform requires a network connection to verify the module.

Answer

Terraform attempts to download the module from the public registry.

Answer

Terraform returns an error because the module path is not absolute.

Question 2

After running terraform apply, you see the error: 'Error: Error loading state: state snapshot was created by Terraform v0.12.0, but this is Terraform v1.2.0'. What should you do to resolve this?

Accepted Answer

Run terraform apply with no changes to upgrade the state format. Running `terraform apply` with no changes triggers Terraform to automatically upgrade the state file format to the version compatible with the current Terraform binary (v1.2.0). Terraform state files are versioned internally, and when a newer version of Terraform reads an older state format, it performs an in-place upgrade during the next state write operation, such as an apply that results in no changes. This avoids manual intervention or data loss.

Answer

Run terraform state upgrade

Answer

Delete the state file and reimport resources

Answer

Downgrade Terraform to v0.12.0

Question 3

A team is using Terraform workspaces to manage multiple environments with a single configuration. They store state in an S3 backend. Which statement about Terraform workspaces is true?

Accepted Answer

The default workspace is named "default" and cannot be deleted. The default workspace in Terraform is always named 'default' and cannot be deleted. This workspace is created automatically when you initialize a configuration, and it serves as the baseline workspace for state management. The S3 backend fully supports workspaces, and each workspace stores its state under a separate path in the S3 bucket, enabling environment isolation without changing the configuration.

Answer

There is a limit of 10 workspaces per configuration

Answer

Workspaces can only be used with the local backend

Answer

Workspaces automatically isolate variable values and provider configurations

Question 4

A DevOps engineer is writing a Terraform configuration to provision an AWS EC2 instance. They want to ensure that the instance is replaced if the AMI ID changes, but not if the instance type changes. Which lifecycle meta-argument should be used?

Accepted Answer

Set `create_before_destroy = true` and add `instance_type` to `ignore_changes`. `create_before_destroy = true` ensures the new instance is created before the old one is destroyed, which is a best practice for zero-downtime deployments when the AMI changes. Adding `instance_type` to `ignore_changes` tells Terraform to ignore changes to the instance type attribute during plan/apply, so the instance is not replaced when only the instance type changes. This combination precisely meets the requirement: replacement on AMI change, no replacement on instance type change.

Answer

Set `prevent_destroy = true`

Answer

Set `ignore_changes = all`

Answer

Set `create_before_destroy = true` only

Question 5

An organization uses Terraform Cloud for remote state management. A user runs `terraform apply` locally but receives an error that the state is locked. What is the most likely cause?

Accepted Answer

Another user or process is currently running a Terraform operation that modifies the same state.. Terraform Cloud uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When a user runs `terraform apply` locally, the command first attempts to acquire a lock on the remote state. If another user or process (e.g., a Terraform Cloud run, a CI/CD pipeline, or another local apply) is already holding that lock, the new operation will fail with a 'state is locked' error. This is a fundamental safety feature to ensure state consistency.

Answer

The Terraform configuration has a syntax error.

Answer

The user does not have access to the remote state backend.

Answer

The remote backend is temporarily unavailable.

Question 6

Refer to the exhibit. An engineer runs 'terraform plan' and receives an error: 'Error refreshing state: state data in S3 does not have the expected content.' The state file exists and is not corrupted. What is the most likely cause?

Accepted Answer

The state file was written by a different backend configuration (e.g., different key or workspace).. The error 'state data in S3 does not have the expected content' indicates a mismatch between the state file's content and what Terraform expects based on the current backend configuration. This typically occurs when the state file was written using a different backend key, workspace, or bucket path, causing Terraform to read a state that does not match the expected serial or lineage. The state file itself is not corrupted, but the backend configuration (e.g., different `key` or `workspace_key_prefix`) points to a different state object in S3.

Answer

The state file is locked by another process.

Answer

The DynamoDB table does not exist.

Answer

The S3 bucket is in a different region.

Question 7

An operator runs terraform apply and receives the exhibit error. The instance was created but Terraform reports a failure. What is the most likely cause?

Accepted Answer

A provisioner block is configured to wait for SSH, but the instance is not reachable. The error indicates that the instance was created successfully but Terraform reports a failure during the apply phase. This typically occurs when a provisioner block (e.g., file or remote-exec) is configured to wait for SSH connectivity, but the instance is not reachable within the timeout period. Terraform marks the resource as 'tainted' and reports a failure, even though the cloud resource itself was provisioned.

Answer

The state file is locked and cannot be updated

Answer

The AMI ID is incorrect and the instance failed to boot

Answer

The AWS API returned an error during instance creation

Question 8

An organization stores their Terraform modules in a private Git repository. They need to reference a module that resides in a subdirectory called 'modules/rds' within the repository 'infra-modules' on the main branch. Which source argument should be used?

Accepted Answer

source = "git::https://github.com/org/infra-modules.git//modules/rds". Terraform's module source syntax for Git repositories uses a double slash (`//`) to specify a subdirectory within the repository. The format `git::https://github.com/org/infra-modules.git//modules/rds` tells Terraform to clone the repository at the main branch and then use the module located in the `modules/rds` subdirectory. This is the standard way to reference a module in a subdirectory of a Git repository.

Answer

source = "git::https://github.com/org/infra-modules.git"

Answer

source = "git::https://github.com/org/infra-modules.git:modules/rds"

Answer

source = "git::https://github.com/org/infra-modules.git//rds"

Question 9

Drag and drop the steps to initialize a Terraform working directory in the correct order.

Accepted Answer

Write Terraform configuration files, then run terraform init, then run terraform validate.. Initialization begins after writing configs; terraform init downloads providers/modules, creates .terraform directory, and validate checks syntax.

Answer

Run terraform init, then write Terraform configuration files, then run terraform validate.

Answer

Write Terraform configuration files, then run terraform validate, then run terraform init.

Answer

Run terraform validate, then write Terraform configuration files, then run terraform init.

Question 10

A DevOps team is using Terraform Cloud to manage infrastructure. They want to integrate Terraform into their CI/CD pipeline by triggering runs programmatically. Which approach should they use to invoke a Terraform run from an external system?

Accepted Answer

Use the Terraform Cloud API to trigger a run.. The Terraform Cloud API provides a programmatic endpoint to trigger runs, allowing external CI/CD systems to initiate Terraform operations without manual intervention. This is the correct approach because it directly invokes a run with full control over variables, configuration versions, and apply strategies, aligning with the requirement to integrate Terraform into a CI/CD pipeline programmatically.

Answer

Set up a webhook from the VCS provider to trigger runs.

Answer

Configure a remote backend to automatically run apply.

Answer

Execute 'terraform apply -auto-approve' in the CI pipeline.

Question 11

A team is using Terraform with multiple environments (dev, staging, prod) and wants to use separate state files. They are considering workspaces. A senior engineer suggests using separate directory structures instead of workspaces for prod. What is the strongest reason for this recommendation?

Accepted Answer

Workspaces share the same backend configuration, increasing the risk of accidental changes to production.. Workspaces share the same backend configuration, meaning all workspaces (including prod) use the same state storage location and access controls. This increases the risk of accidental changes to production because a single backend misconfiguration or a mistaken workspace switch can lead to unintended modifications to the production state file. Separate directory structures allow for independent backend configurations, enabling stricter access controls and isolation for production.

Answer

Workspaces cannot isolate state files.

Answer

Workspaces make it harder to refactor configurations.

Answer

Workspaces do not support state locking.

Question 12

During a deployment, a user runs `terraform apply` but the command fails because the state lock cannot be acquired. They suspect the lock was released after the previous `apply` but is still held. What command can they use to force unlock the state?

Accepted Answer

`terraform force-unlock <lock_id>`. When Terraform cannot acquire a state lock because it was not properly released (e.g., after a crash or interrupted apply), the `force-unlock` command is the only built-in way to manually break the lock. You must provide the lock ID (obtained from the error message or backend) to override the lock, which is stored in the backend (e.g., DynamoDB, Consul) and prevents concurrent modifications. This command is designed for recovery scenarios where the lock holder is known to be dead.

Answer

`terraform init -force-copy`

Answer

`terraform state unlock`

Answer

`terraform break-lock`

Question 13

A company wants to manage its infrastructure as code using Terraform. The team has a mix of on-premises servers and cloud resources in AWS and Azure. Which of the following best describes Terraform's purpose in this scenario?

Accepted Answer

Terraform is an infrastructure-as-code tool for provisioning and managing any infrastructure across multiple providers.. Terraform is explicitly designed as an infrastructure-as-code tool that uses declarative configuration files to provision and manage resources across multiple providers, including on-premises servers (via providers like vSphere or Hyper-V) and cloud platforms like AWS and Azure. Its provider model allows it to abstract away the underlying APIs, making it provider-agnostic and suitable for hybrid environments.

Answer

Terraform is a configuration management tool for installing software on existing servers.

Answer

Terraform is a cloud-specific orchestration tool that only works with AWS.

Answer

Terraform is a monitoring and logging tool for cloud resources.

Question 14

A DevOps engineer runs terraform plan and sees that a resource will be destroyed and recreated, but they expected an in-place update. The resource is an AWS EC2 instance with a specific AMI. Which attribute change is most likely causing the destruction?

Accepted Answer

The AMI ID was changed.. Changing the AMI ID of an AWS EC2 instance is a force-new attribute in Terraform. Because the AMI defines the root block device and operating system, Terraform cannot perform an in-place update; it must destroy the existing instance and create a new one with the new AMI. This behavior is hardcoded in the Terraform AWS provider for the `aws_instance` resource.

Answer

The security group list was modified.

Answer

The tags were updated.

Answer

The instance type was reduced from large to micro.

Question 15

Which version of the module was downloaded and why?

Accepted Answer

3.19.0, because it is the latest version matching the constraint ~> 3.0, which allows any 3.x version.. The constraint `~> 3.0` in Terraform's version constraint syntax allows only the rightmost element to increment. Since `3.0` is a two-part version, the constraint permits any version in the `3.x` range (i.e., `3.0.0` up to but not including `4.0.0`). Therefore, the latest version matching that constraint is `3.19.0`, which is the highest available 3.x version.

Answer

3.0.0, because ~> 3.0 only allows the exact version 3.0.0.

Answer

3.19.0, because it is the latest version and version constraints are ignored.

Answer

3.0.0, because ~> 3.0 is limited to patch updates within 3.0.x.

Question 16

Drag and drop the steps to use Terraform modules from the registry in the correct order.

Accepted Answer

Write the module block in main.tf, then run terraform init, then set input variables in terraform.tfvars, then run terraform plan and terraform apply.. Registry modules are sourced; init downloads, variables configure, plan/apply deploy.

Answer

Run terraform init, then write the module block, then set input variables, then run terraform plan and apply.

Answer

Write the module block, then set input variables, then run terraform init, then run terraform plan and apply.

Answer

Write the module block, then run terraform plan and apply, then run terraform init, then set input variables.

Question 17

A team wants to use Terraform to manage their AWS infrastructure. They have existing resources created manually. What is the recommended approach to bring these resources under Terraform management?

Accepted Answer

Use terraform import to bring each resource into state.. `terraform import` is the recommended approach to bring existing manually created resources under Terraform management. It maps the real-world resource ID into your Terraform state file, allowing Terraform to track and manage it without deleting or recreating it. This preserves the existing infrastructure while enabling future updates via configuration.

Answer

Delete the existing resources and recreate them using Terraform configuration.

Answer

Use terraform plan to detect existing resources and automatically adopt them.

Answer

Write Terraform configuration that matches existing resources and run terraform apply.

Question 18

A Terraform configuration includes a resource block with a 'lifecycle' block that has 'create_before_destroy = true'. During an apply, the create step succeeds but the destroy step fails. What is the resulting state?

Accepted Answer

Both the old and new resources are in state.. When `create_before_destroy = true` is set, Terraform creates the new resource first, then destroys the old one. If the destroy step fails after the new resource is created, both resources exist in the state file because Terraform does not remove the old resource from state until the destroy operation completes successfully. The state retains both resource instances at the same address, which is why option D is correct.

Answer

Only the new resource remains in state, old resource is destroyed.

Answer

The state is empty for that resource address.

Answer

Only the old resource remains in state.

Question 19

A company uses Terraform Cloud and wants to ensure that only approved modules from the private registry are used in configurations. How can they enforce this?

Accepted Answer

Use Sentinel policies to check module sources. Sentinel is HashiCorp's policy-as-code framework that can enforce governance rules on Terraform Cloud runs. By writing a Sentinel policy that inspects the `module` block's `source` attribute, you can restrict configurations to only use modules from the approved private registry, rejecting any run that references external or unapproved sources.

Answer

Restrict module sources in VCS

Answer

Configure workspace variables to limit module paths

Answer

Use run tasks to scan for module types

Question 20

A DevOps engineer needs to generate multiple similar AWS EC2 instances from a single resource block. They want each instance to have a unique name tag based on an index. Which approach should they use?

Accepted Answer

Use `count` and reference `count.index` for the name tag. The `count` meta-argument creates multiple resources from a single resource block, and `count.index` provides a zero-based index for each instance. This index can be used directly in the name tag, such as `"instance-${count.index}"`, to generate unique names. `count` is the simplest and most appropriate mechanism when you need a fixed number of similar resources differentiated by an index.

Answer

Use a `locals` block to define multiple resources

Answer

Use `for_each` and reference `each.key` for the name tag

Answer

Use a `terraform_data` resource to loop