TF-004 Practice Exam 3 — 20 Questions

Question 1

A team uses the backend configuration above. What is the primary benefit of storing state remotely in S3?

Accepted Answer

Enabling state sharing and locking across the team. Storing Terraform state remotely in S3 is the standard practice for team collaboration because it allows multiple team members to access and modify the same state file, preventing conflicts. Combined with DynamoDB for state locking, it ensures that only one person runs `terraform apply` at a time, avoiding race conditions and state corruption. This is the primary benefit over local state storage, which is single-user by design.

Answer

Automatic encryption of state files

Answer

Reducing the number of API calls to AWS

Answer

Faster Terraform execution times

Question 2

A Terraform configuration uses a module from the Terraform Registry. After updating the module version in the configuration, the operator runs 'terraform plan' but does not see the changes expected from the new version. What is the most likely cause?

Accepted Answer

The operator did not run 'terraform init' after changing the version.. When you change a module version in the configuration, Terraform must re-initialize the working directory to download the new version and update the dependency lock file (.terraform.lock.hcl). Running 'terraform plan' without first running 'terraform init' will use the previously cached module version, so the expected changes from the new version will not appear. 'terraform init' is the required command to fetch and lock the updated module source.

Answer

The operator did not run 'terraform get' to update modules.

Answer

The operator did not run 'terraform refresh' to update state.

Answer

The module version constraint is stored in the state file and must be updated.

Question 3

A developer is working on a Terraform configuration that manages a single resource. They want to import an existing AWS EC2 instance into state. Which command should they use?

Accepted Answer

terraform import. `terraform import` is the dedicated command for bringing an existing infrastructure resource (like an AWS EC2 instance) under Terraform management by attaching it to a resource block in the state file. It requires the resource address and the provider-specific ID (e.g., `aws_instance.my_instance i-1234567890abcdef0`) to map the real-world resource into the Terraform state without modifying the resource itself.

Answer

terraform apply

Answer

terraform refresh

Answer

terraform state mv

Question 4

Your team uses Terraform to manage a multi-region AWS deployment consisting of over 500 resources. The state file is stored in an S3 backend with DynamoDB locking. Recently, one of your colleagues accidentally deleted the state file from S3 while trying to clean up old backups. Fortunately, you have a backup from two days ago. However, after restoring the backup, you notice that several recent changes, including two new EC2 instances and a security group, are missing from the state. The actual resources still exist in AWS. You need to bring the state back in sync with the real-world infrastructure without recreating these resources. What should you do?

Accepted Answer

Use `terraform import` for each missing resource to add them to state. `terraform import` is the intended mechanism to bring existing infrastructure under Terraform management without recreating it. Since the missing EC2 instances and security group still exist in AWS but are absent from the state file, importing each resource by its AWS ID will add the corresponding state entries, allowing Terraform to manage them going forward. This avoids the downtime and potential configuration drift that would occur with `terraform apply` or manual state editing.

Answer

Run `terraform apply` to recreate the missing resources

Answer

Manually edit the state file to add the missing resource entries

Answer

Run `terraform refresh` to update the state with the missing resources

Question 5

You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. Each environment has its own state file stored in an S3 backend with DynamoDB locking. The team recently adopted a policy of running 'terraform plan' in CI/CD pipelines to review changes before applying. However, developers have reported that sometimes the plan output shows that Terraform wants to destroy and recreate resources that were not modified in their code changes. For example, a developer added a new tag to an S3 bucket in the staging environment, but the plan also showed that an unrelated EC2 instance would be replaced. Upon investigation, you notice that the state file for staging was last modified two days ago, but the developer's branch is based on a commit from one week ago. Which action is most likely to resolve the issue and ensure that plans only reflect changes from the current configuration changes?

Accepted Answer

Run 'terraform init -reconfigure' to ensure the local state is synchronized with the remote backend before planning.. `terraform init -reconfigure` forces Terraform to reinitialize the backend and re-download the latest state file from the remote S3 backend, discarding any stale local copy. The developer's local state was based on a week-old commit, while the actual remote state had been updated two days ago, causing Terraform to detect spurious differences (e.g., an unrelated EC2 instance) due to state drift. This command ensures the local state matches the remote state before planning, so the plan only reflects changes from the current configuration.

Answer

Set the 'skip_metadata_api_check' option in the provider to avoid changes.

Answer

Use 'terraform plan -target=aws_s3_bucket.bucket' to limit the plan to only the S3 bucket.

Answer

Run 'terraform plan -refresh=true' to refresh the state before planning.

Question 6

Which Terraform command is used to bring existing infrastructure that was created outside of Terraform under Terraform management?

Accepted Answer

terraform import. `terraform import` is the dedicated command to bring existing infrastructure that was created outside of Terraform under Terraform management. It maps the real-world resource ID to a Terraform resource address in state, allowing Terraform to track and manage that resource without recreating it.

Answer

terraform state push

Answer

terraform apply

Answer

terraform refresh

Question 7

Refer to the exhibit. The configuration fails with an error indicating that the module does not support the 'enable_vpn_gateway' argument. What is the most likely cause?

Accepted Answer

The module version '3.18.0' does not include the 'enable_vpn_gateway' variable; it was added in a later version.. The error message indicates that the module does not support the 'enable_vpn_gateway' argument. In Terraform, module arguments are defined by the module's published variables. The module version '3.18.0' predates the introduction of the 'enable_vpn_gateway' variable, which was added in a later version. Upgrading the module version to one that includes this variable resolves the error.

Answer

The argument name is misspelled; it should be 'enable_vpn' instead.

Answer

The module does not support VPN gateways at all.

Answer

The module source is incorrectly specified; it should use a git URL instead of the registry path.

Question 8

A developer wants to use the output of one Terraform configuration as input to another. Which Terraform feature should they use?

Accepted Answer

remote state data source. The remote state data source (terraform_remote_state) is the correct feature because it allows one Terraform configuration to read the output values from another configuration's state file, enabling cross-configuration data sharing without manual intervention. This is the idiomatic way to consume outputs from a separate Terraform root module, such as retrieving a VPC ID from a networking configuration to use in an application configuration.

Answer

local values

Answer

data sources

Answer

variables

Question 9

A module block references a module with version constraint '>= 2.0, < 3.0'. An older version 1.5 is already cached from a previous init. The team wants to ensure they use a newer version. After running terraform init -upgrade, what happens?

Accepted Answer

Terraform upgrades to the latest version in the range 2.x that is not yet cached.. `terraform init -upgrade` instructs Terraform to ignore any cached versions and re-check the registry for the newest available version that satisfies the version constraint `>= 2.0, < 3.0`. Since the constraint excludes 3.0, the latest version in the 2.x series will be selected and downloaded, overwriting the cached 1.5 version.

Answer

Terraform upgrades to version 3.0 because it is the latest.

Answer

Terraform returns an error because version 1.5 is incompatible with the constraint.

Answer

Terraform uses the cached version 1.5 because it is already present.

Question 10

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?

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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.