TF-004 Practice Test 29 — 15 Questions

Question 1

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 2

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 3

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

Accepted Answer

Providers are plugins that Terraform uses to manage resources.. Option B is correct because Terraform providers are plugins that implement the API interactions needed to create, read, update, and delete resources for a given platform or service, such as AWS, Azure, or Kubernetes. Option C is correct because providers are distributed and can be sourced from the Terraform Registry, which is the primary public repository for provider plugins and modules, and they are declared in the required_providers block with a source address. Option A is incorrect because a provider does not need to be explicitly defined in every configuration; Terraform can infer and use a default provider for a resource type, and the required_providers block is only needed when specifying a non-default source or version constraint. Option D is incorrect because a single Terraform configuration can use multiple providers simultaneously, and even multiple instances of the same provider via aliases. Option E is incorrect because providers are not automatically installed by terraform plan; installation occurs during terraform init, which downloads and installs the required provider plugins into the .terraform directory.

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 4

A company manages multiple AWS accounts using Terraform. They have a central repository where all Terraform configurations are stored. Recently, a developer accidentally ran terraform destroy on a production workspace and deleted critical resources. The team wants to implement safeguards to prevent such incidents while still allowing developers to test changes in non-production environments. They currently use Terraform Cloud for remote state management and runs. Which course of action should the team take to minimize risk?

Accepted Answer

Implement run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production'.. Implementing run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production' adds a safeguard that prevents accidental destruction while still allowing developers to test changes in non-production environments. This approach uses Terraform Cloud's native capabilities to enforce manual approval for destructive actions on production workspaces, minimizing risk without hindering development workflows.

Answer

Store the production Terraform state file locally and restrict access to it.

Answer

Use Terraform's built-in lifecycle prevent_destroy on all production resources.

Answer

Remove all developers' access to the Terraform Cloud API and only allow operations via pull requests.

Question 5

Match each Terraform meta-argument to its purpose.

Accepted Answer

depends_on: Specifies hidden dependencies on other resources. Terraform meta-arguments are available across all resource types. depends_on declares hidden dependencies, count creates N copies, for_each creates copies from a collection, and lifecycle controls behavior like create_before_destroy. Common confusions include mixing the purposes of count and depends_on, or associating lifecycle with instance creation.

Answer

count: Specifies hidden dependencies on other resources

Answer

lifecycle: Creates multiple resource instances based on a count

Question 6

Drag and drop the steps to set up remote state with Terraform Cloud in the correct order.

Accepted Answer

Create a workspace in Terraform Cloud, then add the cloud block to your configuration, then run terraform init.. The correct order is to first create the workspace in Terraform Cloud, then add the cloud block to your Terraform configuration referencing that workspace, and finally run terraform init which detects the cloud block and migrates the state from local to the remote workspace. Other orders fail because the workspace must exist before the cloud block is configured or init is run without proper backend configuration.

Answer

Add the cloud block to your configuration, then create a workspace in Terraform Cloud, then run terraform init.

Answer

Run terraform init, then add the cloud block to your configuration, then create a workspace in Terraform Cloud.

Answer

Create a workspace in Terraform Cloud, then run terraform init, then add the cloud block to your configuration.

Question 7

A platform team currently provisions servers by filing tickets that an operations group fulfills manually over several days. Leadership wants developers to describe the desired end state of that infrastructure in version-controlled files so the tooling itself figures out which resources to create, modify, or remove. Which characteristic of Terraform directly supports this goal?

Accepted Answer

Terraform is declarative, so you define the desired end state and it computes the actions needed to reach it.. The team needs files that describe the intended end state of infrastructure rather than a manual sequence of provisioning steps. A declarative configuration language fits that need because Terraform compares desired state with recorded state, builds a dependency graph, and produces an execution plan of create, update, and destroy actions. Procedural scripting, embedded credentials, and host-installed agents do not deliver that outcome.

Answer

Terraform stores credentials in the configuration so provisioning runs unattended.

Answer

Terraform applies changes through a configuration management agent installed on each managed host.

Answer

Terraform is procedural, so engineers write ordered scripts that call each provider API in sequence.

Question 8

An engineer has been managing a production environment with Terraform using a local state file. The team now requires that state be stored remotely in an AWS S3 bucket so multiple engineers can collaborate. The engineer adds a backend block to the existing configuration and runs `terraform init`. Terraform reports that it has detected a pre-existing local state and asks whether to copy it to the new backend. Which action should the engineer take to preserve the existing resource tracking?

Accepted Answer

Answer yes, allowing Terraform to migrate the local state to the S3 backend.. When a backend block is added to a configuration that previously used local state, `terraform init` detects the existing state and offers to migrate it. Accepting the prompt copies the local state data into the new remote backend, preserving resource tracking. Declining leaves the local state in place, and no other command performs this migration automatically. Manual copying or forcing a state push are unsupported or dangerous alternatives that can leave the backend uninitialized or overwrite newer data.

Answer

Answer no, then run `terraform refresh` to push the local state to S3.

Answer

Answer no, then manually copy terraform.tfstate into the S3 bucket using the AWS CLI.

Answer

Answer yes, then immediately run `terraform state push` to overwrite the S3 state with the local file.

Question 9

A DevOps engineer manages infrastructure with Terraform using an S3 backend with DynamoDB locking. During a `terraform apply`, the engineer's network connection drops. After reconnecting, they run `terraform plan` and get an error: "Error acquiring the state lock." The lock is from the previous session. The engineer has verified that no other operations are running. What is the appropriate next step to proceed?

Accepted Answer

Use `terraform force-unlock <lock_id>` to remove the stale lock. `terraform force-unlock` is the intended mechanism to manually remove a stale lock from the DynamoDB table when the process that held the lock has terminated abnormally. The engineer has confirmed no other operations are running, so the lock is orphaned and safe to remove. This command requires the specific lock ID, which is provided in the error message.

Answer

Delete the DynamoDB table and recreate it

Answer

Wait 15 minutes for the lock to expire automatically

Answer

Run `terraform init` to reset the backend connection

Question 10

A platform team stores Terraform state in an S3 bucket and uses a DynamoDB table for state locking. An engineer's `terraform apply` was interrupted by a workstation crash, and the lock entry remains in DynamoDB. Other engineers now receive 'Error acquiring the state lock' when they run plans. The team wants to safely clear the lock without risking state corruption. Which sequence of actions is most appropriate?

Accepted Answer

Run `terraform force-unlock` with the lock ID, after verifying no other Terraform process is actively running against the same state.. A stale lock after an interrupted apply is best cleared with `terraform force-unlock`, which removes the specific lock entry identified by the lock ID. Before doing so, the team must confirm no other Terraform process is running against the same state, because force-unlock provides no coordination. Manually deleting the DynamoDB item, disabling locking, or pushing state all bypass Terraform's safety mechanisms and can cause concurrent writes or leave the backend inconsistent.

Answer

Delete the lock item directly from the DynamoDB table using the AWS CLI.

Answer

Disable state locking in the backend configuration, apply the change, then re-enable locking.

Answer

Run `terraform state pull` to refresh the local copy, then `terraform state push` to overwrite the remote state.

Question 11

Which TWO statements about Terraform's handling of input variables are true?

Accepted Answer

The terraform.tfvars file is automatically loaded by Terraform.. Option C is correct because Terraform automatically loads a file named terraform.tfvars (or terraform.tfvars.json) from the current working directory when running commands like terraform plan and terraform apply, without requiring an explicit -var-file flag. Option E is correct because input variables are declared in configuration files using the variable block, e.g. variable "region" { type = string }, which defines the variable's name, type, and optional default. Option A is false because variables with a default value, or those not referenced in the configuration, do not need to be assigned before terraform plan; only variables lacking a default and actually used must be supplied. Option B is false because Terraform does read environment variables prefixed with TF_VAR_ (e.g. TF_VAR_region) to assign variable values. Option D is false because default values are set with the default argument inside the variable block, not via a .tfvars file, which is instead used to assign values at runtime.

Answer

All variables must be assigned a value before running terraform plan.

Answer

Variable values cannot be overridden using environment variables.

Answer

Default values for variables can only be set using a .tfvars file.

Question 12

A consultant is writing a reusable module that provisions an AWS VPC. Callers are complaining that they cannot tell which inputs are required and which have defaults, and the module's README is frequently out of date. Which practice most directly improves the module's self-documenting interface without adding external tooling?

Accepted Answer

Add a `description` argument to every variable and output declaration, and provide defaults only where a value is genuinely optional.. Descriptions on variables and outputs are the primary in-configuration documentation surface. Tools and the registry read them, and the presence or absence of a default communicates required versus optional. Keeping defaults only for genuinely optional inputs prevents callers from supplying meaningless placeholder values and makes the module interface predictable.

Answer

Move all variable declarations into a separate `variables.tf` file and reference them from a single `main.tf`.

Answer

Set `sensitive = true` on all variables so callers are forced to inspect the module source before using it.

Answer

Convert the module to use `terraform_remote_state` data sources so callers can read the VPC attributes directly.

Question 13

Which Terraform feature helps manage dependencies between resources?

Accepted Answer

depends_on. The depends_on meta-argument in Terraform explicitly defines dependencies between resources, ensuring that one resource is created only after another. This is useful when Terraform cannot infer the dependency from expressions.

Answer

data source

Answer

output

Answer

provisioner

Question 14

A company uses Terraform to manage infrastructure on AWS. They have a configuration that creates an S3 bucket and a DynamoDB table for state locking. The team notices that sometimes when two members run terraform apply simultaneously, they get a state locking error. However, they want to allow concurrent operations on different workspaces. What is the best approach?

Accepted Answer

Use separate state files per workspace and ensure each workspace has its own lock entry in DynamoDB; the current setup already supports this.. Terraform natively supports per-workspace state files, and when using a remote backend like S3 with DynamoDB for state locking, each workspace's state file is stored at a distinct path in S3. The DynamoDB lock entry is tied to the specific state file path via the LockID, so concurrent operations on different workspaces acquire separate locks and do not conflict. This setup allows multiple team members to run terraform apply simultaneously as long as they are working in different workspaces.

Answer

Remove the DynamoDB table and use local state files to avoid locking issues.

Answer

Configure all team members to use the same workspace so that only one person can apply at a time.

Answer

Keep the current setup because the error is harmless and users can retry.

Question 15

Which THREE actions should be taken when migrating Terraform state from local to a remote backend?

Accepted Answer

Run terraform init to initialize the backend and migrate state.. Option E is correct because you must declare a backend block (for example, backend "s3" or backend "azurerm") in the Terraform configuration so Terraform knows which remote backend to use. Option B is correct because after adding the backend block you run terraform init, which initializes the backend and, when existing local state is detected, offers to copy it to the new remote backend. Option D is correct because terraform init prompts 'Do you want to copy existing state to the new backend?' and you must confirm by typing 'yes' to complete the migration. Option A is wrong because deleting the local state file first would destroy the state that needs to be migrated. Option C is wrong because terraform import is used for bringing existing infrastructure under management, not for migrating an already-tracked state file to a remote backend.

Answer

Remove the local state file before running terraform init.

Answer

Manually import all existing resources into the remote state.