TF-004 Practice Exam 2 — 20 Questions

Question 1

Which THREE statements about module configuration are correct?

Accepted Answer

Module sources can be local paths or remote URLs.. Terraform module sources can be either local file paths (e.g., `./modules/network`) or remote URLs (e.g., `git::https://example.com/repo.git`, `registry.terraform.io/hashicorp/consul/aws`). The `source` argument supports multiple protocols including local, Git, HTTP, and the Terraform Registry, making it flexible for version control and distribution.

Answer

Version constraints can be specified for any module source.

Answer

The outputs of a module are available after apply only.

Question 2

Which Terraform feature allows managing multiple separate sets of infrastructure from the same configuration?

Accepted Answer

Workspaces. Workspaces allow you to manage multiple distinct sets of infrastructure resources from the same Terraform configuration by maintaining separate state files. Each workspace isolates its own state data, enabling you to deploy, modify, or destroy infrastructure for different environments (e.g., dev, staging, prod) without interfering with each other. This is the native Terraform feature designed specifically for managing multiple separate instances of infrastructure from a single configuration.

Answer

Count

Answer

Providers

Answer

For_each

Question 3

During a CI/CD pipeline run, terraform apply fails halfway through due to a network error. The state file is locked. The team wants to resume from the last successful apply. What should they do?

Accepted Answer

Re-run terraform apply after solving the network issue; Terraform will handle partial state.. Terraform's state file tracks all managed resources and their current status. When `terraform apply` fails mid-run, the state is locked to prevent corruption, but Terraform records any resources that were successfully created before the failure. After resolving the network issue, re-running `terraform apply` will use the existing state to detect already-created resources and continue from where it left off, creating only the remaining resources. This is the correct and intended workflow for handling partial state in Terraform.

Answer

Run terraform destroy and then reapply.

Answer

Force unlock the state and then reapply.

Answer

Manually delete the partially created resources in the cloud console and reapply.

Question 4

An operator wants to pass output values from one Terraform configuration to another as input variables. Which approach is recommended?

Accepted Answer

Use a remote state data source to read the outputs from the first configuration's state.. Terraform's remote state data source (e.g., `terraform_remote_state`) allows one configuration to securely read output values from another configuration's state file stored in a shared backend (like S3, Azure Storage, or Consul). This avoids duplication, manual errors, and ensures that the second configuration always uses the latest outputs from the first, without requiring direct file access or environment variables.

Answer

Hardcode the output values in a variables file for the second configuration.

Answer

Store outputs in a shared file and use 'file()' function to read them.

Answer

Use environment variables to pass the output values.

Question 5

You are a DevOps engineer managing a multi-environment Terraform setup using workspaces. Your team has three workspaces: dev, staging, and prod. All infrastructure is defined in a single root module with environment-specific variable values stored in separate .tfvars files. Recently, a colleague accidentally ran terraform destroy in the prod workspace, which deleted critical production resources. You need to implement a safety mechanism to prevent accidental destruction of production resources in the future. The solution should not require changes to the Terraform provider or backend configuration. Which approach should you take?

Accepted Answer

Add a lifecycle precondition block in a null_resource that checks if the current workspace is 'prod' and fails if terraform destroy is attempted.. A `lifecycle` precondition block in a `null_resource` can evaluate the current workspace at plan time using `terraform.workspace`. When `terraform destroy` is run, the precondition fails if the workspace is `prod`, preventing the destroy operation without altering the provider or backend configuration. This approach is native to Terraform, requires no external tools, and directly enforces the safety check within the configuration itself.

Answer

Create a wrapper script that checks the workspace before running terraform destroy and requires a manual confirmation for prod.

Answer

Use Terraform Sentinel policies with a mandatory policy that denies destroy on the prod workspace.

Answer

Configure a remote backend with state locking and force unlock only for non-prod workspaces.

Question 6

Which TWO statements are correct when refactoring a monolithic Terraform configuration into modules?

Accepted Answer

Module outputs are necessary to expose values to the root module.. Module outputs are the mechanism by which a root module accesses values from child modules. Without outputs, any resource attributes created inside a module remain encapsulated and inaccessible to the calling configuration, making it impossible to use those values for interpolation or to pass them to other resources or modules.

Answer

All modules must reside in a separate directory outside the root module.

Answer

A module should contain only one resource to keep it simple.

Answer

Variables are optional in modules if hardcoded values are acceptable.

Question 7

A team wants to ensure that all Terraform runs are recorded for audit purposes. Which practice should they implement?

Accepted Answer

Configure a remote backend that supports state versioning.. Configuring a remote backend that supports state versioning (e.g., Terraform Cloud, S3 with versioning enabled) automatically records every state change, providing a complete audit trail of all Terraform runs. This ensures that previous state snapshots are preserved and can be reviewed or restored if needed, meeting audit requirements without manual intervention.

Answer

Run 'terraform show' after every apply to capture state.

Answer

Add the state file to version control after each run.

Answer

Enable state locking in the backend configuration.

Question 8

A company uses Terraform with remote state stored in an S3 bucket. An operator accidentally runs 'terraform destroy' on a production workspace and wants to recover the state before the operation. What is the best course of action?

Accepted Answer

Restore the state file from the S3 bucket's versioning if enabled.. S3 bucket versioning, when enabled, automatically retains all versions of an object, including overwrites and deletions. By restoring the previous version of the state file (e.g., via the AWS console, CLI, or SDK), the operator can recover the exact state that existed before the 'terraform destroy' command was run, allowing Terraform to resume managing the infrastructure correctly.

Answer

Re-run 'terraform apply' to recreate resources.

Answer

Restore the state file from a DynamoDB backup.

Answer

Use 'terraform state pull' to retrieve the last known state.

Question 9

Refer to the exhibit. A terraform plan shows that the instance will be replaced. What will be the order of operations?

Accepted Answer

Destroy the old instance first, then create the new one.. By default, when Terraform replaces a resource (e.g., due to a forced-new change like `ami` or `instance_type`), it destroys the old instance first and then creates the new one. This 'destroy-before-create' behavior is the default because it ensures Terraform can cleanly remove the old resource before provisioning the replacement. To achieve zero-downtime deployments, you must explicitly set `lifecycle { create_before_destroy = true }`.

Answer

The instance will be updated in-place without replacement.

Answer

Both instances will be created and destroyed simultaneously.

Answer

Create the new instance first, then destroy the old one.

Question 10

A team has two resources: an AWS security group and an EC2 instance that uses it. Terraform does not automatically detect the dependency. Which argument should be added to the instance resource?

Accepted Answer

depends_on = [aws_security_group.sg]. Terraform requires explicit dependency declarations when it cannot infer them from resource references. The `depends_on` argument must be a list of resource references, and `[aws_security_group.sg]` correctly references the security group resource as a single-element list. This ensures Terraform creates the security group before the EC2 instance that depends on it.

Answer

depends_on = [aws_security_group.sg.*]

Answer

depends_on = aws_security_group.sg

Answer

depends_on = [aws_security_group.sg.id]

Question 11

An operator modifies a Terraform configuration to change the `ami` attribute of an `aws_instance` resource. When they run `terraform plan`, they see that the resource will be destroyed and recreated. They want to avoid the recreation and instead update the instance in-place. What is the best approach?

Accepted Answer

Accept the recreation; it is required for this attribute. Changing the `ami` attribute of an `aws_instance` resource is a force-new attribute in the AWS provider. Terraform cannot update the AMI of a running EC2 instance in-place; it must destroy the existing instance and create a new one with the new AMI. This is a fundamental constraint of the AWS API, not a Terraform limitation.

Answer

Add `create_before_destroy` lifecycle rule

Answer

Use `ignore_changes` in lifecycle to ignore AMI changes

Answer

Add `prevent_destroy` lifecycle rule

Question 12

A Terraform configuration uses a for_each expression to create multiple subnets. After applying, one subnet's configuration needs to be modified. The engineer updates the resource block's map key for that subnet. What will terraform plan show?

Accepted Answer

Destruction of the existing subnet and creation of a new one.. When a for_each expression is used, Terraform identifies each resource instance by its map key. Changing the map key for a subnet causes Terraform to treat the old key as a resource to be destroyed and the new key as a resource to be created, because the key is part of the resource's identity. Even if the configuration inside the block is identical, the change in key results in a destroy-and-create action, not an in-place update.

Answer

No changes because the subnet configuration is the same.

Answer

Only deletion of the old subnet.

Answer

An in-place update to the subnet.

Question 13

An organization uses Terraform Cloud with VCS-driven runs. They have two workspaces: network and application. They want a new run in the application workspace to automatically trigger whenever the network workspace completes a successful plan. What should they configure?

Accepted Answer

Run triggers in the application workspace pointing to the network workspace.. Run triggers in Terraform Cloud allow one workspace to automatically queue a run in another workspace after a successful plan. By configuring a run trigger in the application workspace that points to the network workspace, any successful plan in the network workspace will automatically initiate a new run in the application workspace, satisfying the requirement without external tools or manual steps.

Answer

A webhook from Terraform Cloud to an external CI system.

Answer

Use 'terraform apply' with '-target' to simulate dependency.

Answer

Run triggers in the network workspace pointing to the application workspace.

Question 14

A developer needs to retrieve the current state of an AWS EC2 instance that was created by Terraform but the configuration file is missing. Which command will output the attributes of the instance in a format suitable for generating a configuration?

Accepted Answer

terraform state show -json aws_instance.example. `terraform state show -json aws_instance.example` retrieves the current state of the specified resource from the Terraform state file and outputs it in JSON format, which can be directly used to reconstruct a configuration block. This command is specifically designed for inspecting a single resource's attributes when the original configuration is unavailable.

Answer

terraform output aws_instance

Answer

terraform state pull | grep aws_instance

Answer

terraform plan

Question 15

A development team is using a declarative IaC tool. They make a change to the configuration file to add a new security group rule. When they apply the configuration, the tool automatically modifies the existing security group to add the rule. What is this behavior called?

Accepted Answer

Desired state reconciliation. This behavior is called desired state reconciliation because declarative IaC tools like Terraform or AWS CloudFormation compare the current state of infrastructure against the desired state defined in the configuration file. When a new security group rule is added to the configuration, the tool automatically computes the necessary changes to reconcile the actual state with the desired state, creating, updating, or deleting resources as needed. This is a core principle of declarative IaC, where the user specifies the 'what' and the tool handles the 'how'.

Answer

Provisioning

Answer

Imperative execution

Answer

Resource drift

Question 16

A company uses Terraform workspaces to manage environments. They have a monorepo with separate configurations for each environment. They want to introduce a new team that will manage only the staging environment. The new team will run terraform commands only on the staging workspace. They are using a single S3 backend for all workspaces. The team is concerned about accidentally applying changes to other workspaces. What is the best way to restrict the team's access?

Accepted Answer

Use Terraform Cloud with team-based permissions.. Terraform Cloud provides native workspace-level permissions, allowing you to grant the new team access only to the staging workspace while preventing them from applying changes to other workspaces. This is the most secure and manageable approach, as it leverages Terraform Cloud's RBAC (Role-Based Access Control) to enforce separation of duties without modifying the backend configuration or relying on error-prone manual processes.

Answer

Create a separate S3 bucket for staging and configure a different backend.

Answer

Use terraform workspace select staging in the CI/CD pipeline and only allow that.

Answer

Use IAM policies to restrict access to the state files of other workspaces.

Question 17

You are managing a Terraform configuration that deploys resources across multiple AWS accounts using provider aliases. The configuration uses a single backend (S3) to store the state file. Recently, you discovered that the state file has become very large (over 100 MB) and is causing slow operations and timeouts. The team wants to improve performance without losing the ability to manage all resources with a single `terraform apply`. You need to propose a solution. Which approach should you take?

Accepted Answer

Switch the backend from S3 to Terraform Cloud to improve performance. Switching to Terraform Cloud can improve performance with large state files due to its optimized backend, remote state management, and built-in caching. It allows you to continue managing all resources with a single `terraform apply` command, as Terraform Cloud handles state operations efficiently. This approach does not require splitting the state file or using multiple workspaces, thus preserving the ability to apply all changes in one operation.

Answer

Use state encryption to compress the state file

Answer

Use Terraform workspaces to separate environments into different state files

Answer

Split the configuration into separate directories for each environment

Question 18

A developer runs terraform apply to create an AWS EC2 instance using an AMI sourced from the aws_ami data source with most_recent = true. Immediately after apply completes, the developer runs terraform plan again. The plan shows that Terraform intends to replace the EC2 instance. What is the most likely cause?

Accepted Answer

A new AMI was released after the apply, causing the data source to return a different AMI ID.. The `aws_ami` data source with `most_recent = true` dynamically queries AWS for the latest AMI matching the specified filters at plan time. If a new AMI is published between the first `apply` and the subsequent `plan`, the data source returns a different AMI ID, causing Terraform to detect a change in the AMI attribute of the EC2 instance. Since the AMI ID is a force-new attribute for `aws_instance`, Terraform plans to replace the instance.

Answer

The developer did not run terraform init before the second plan.

Answer

The instance type was changed in the configuration between apply and plan.

Answer

The Terraform state file was corrupted during the apply.

Question 19

A module defines an input variable with 'sensitive = true'. The root module tries to use that variable in an output block. What happens when running 'terraform apply'?

Accepted Answer

The output value is hidden in the CLI output but still available in the state.. When a variable is marked `sensitive = true`, Terraform prevents its value from being displayed in CLI output for any output that references it. However, the value is still stored in the state file and can be used within the module. Therefore, `terraform apply` succeeds, but the output value is hidden in the CLI output while remaining available in the state.

Answer

The apply fails with an error because sensitive variables cannot be used in outputs.

Answer

The output is displayed normally because outputs are always visible.

Answer

The output is removed from the plan entirely to protect the sensitive value.

Question 20

What is the correct way to resolve this provider version conflict?

Accepted Answer

Change the root module's required version to ~> 2.70.. The root module's required_providers version constraint must be compatible with the version constraints declared in any child modules. The error indicates the root module requires a provider version that conflicts with the consul module's constraint (e.g., ~> 2.70). Changing the root constraint to ~> 2.70 aligns it with the child module, satisfying Terraform's version resolution logic during `terraform init`.

Answer

Ignore the module's required_providers and force install the root version.

Answer

Remove the required_providers block from the root module.

Answer

Manually edit the .terraform/modules/consul/main.tf to change the version.