TF-004 Practice Test 5 — 25 Questions

Question 1

After applying the configuration above, the user changes the AMI to a new value and runs 'terraform apply'. Assuming the new AMI triggers a recreate, what happens during the apply?

Accepted Answer

The existing instance is deleted before the new one is created.. Terraform's default lifecycle for resource replacement is to destroy the existing resource first, then create the new one. This is the standard behavior unless `create_before_destroy` is explicitly set to `true`. The AMI change triggers a recreate, and by default, the old instance is deleted before the new one is provisioned.

Answer

Both instances run simultaneously only if the instance type allows it.

Answer

The new instance is created first, then the old one is deleted.

Answer

The plan fails because AMI change with create_before_destroy is not allowed.

Question 2

A team uses Terraform Cloud with a VCS-backed workflow. They notice that a recent commit triggered a run that failed because of an invalid configuration. The team fixed the configuration and wants to re-run the plan without committing again. Which action should they take?

Accepted Answer

Create a new commit with the fix. In a VCS-backed Terraform Cloud workspace, runs are triggered by commits to the linked repository. When a configuration error is found in the code, fixing it requires a new commit that includes the corrected code. The 'Queue Plan' button re-runs a plan using the same commit, so it cannot incorporate local fixes. Creating a new commit (option B) triggers a new run with the fixed configuration.

Answer

Amend the previous commit and force push

Answer

Use the 'Queue Plan' button in the Terraform Cloud UI

Answer

Run terraform plan locally and apply

Question 3

A company has a monolithic Terraform configuration that manages all infrastructure. As the infrastructure grows, plan and apply times become very long. They want to break the configuration into smaller, independent units to improve performance and reduce blast radius. Which approach should they take?

Accepted Answer

Split the configuration into separate root modules, each with its own state file, and use data sources to share outputs. Splitting the monolithic configuration into separate root modules, each with its own state file, reduces the scope of `terraform plan` and `terraform apply` operations, improving performance. Using data sources to share outputs between root modules allows independent management while maintaining necessary dependencies, which also reduces the blast radius by isolating failures to a single root module.

Answer

Refactor into multiple Terraform modules and use a single root module

Answer

Use Terraform workspaces to separate environments

Answer

Use terraform state mv to reorganize resources into different state files

Question 4

Refer to the exhibit. A developer runs terraform plan and sees "No changes". However, the developer knows that manual changes were made to the infrastructure outside Terraform. What is the most likely reason terraform plan does not detect the drift?

Accepted Answer

The manual changes were made to resources not managed by Terraform.. Terraform plan detects drift by comparing the current configuration against the state file, but only for resources that Terraform manages. If manual changes are made to resources that are not recorded in Terraform's state (i.e., resources created outside of Terraform or not imported), then plan will not detect them because those resources are unknown to Terraform. Options B, C, and D are incorrect: B is false because plan can detect drift with refresh; C is not necessarily true as the changes may still exist; D is false because modern Terraform refreshes state by default before planning, but that refresh only applies to managed resources.

Answer

Terraform only detects drift when running terraform apply.

Answer

The manual changes were reverted before the plan was run.

Answer

Terraform plan does not refresh state by default; it uses the existing state file.

Question 5

A module requires a specific provider configuration with aliases. The root module has two provider configurations: provider 'aws' (default) and provider 'aws' with alias = 'uswest'. The module uses the us-west alias. How should the module block be configured to ensure the correct provider is used?

Accepted Answer

Use the providers argument in the module block: providers = { aws = aws.uswest }.. Terraform uses the `providers` argument in a module block to explicitly map provider configurations from the root module into the module. Since the root module has two AWS provider configurations (default and `uswest` alias), and the module requires the us-west alias, the mapping `providers = { aws = aws.uswest }` ensures the module uses the aliased provider. Without this explicit mapping, Terraform would default to the root module's default provider, which may not have the correct region or settings.

Answer

Set required_providers inside the module to include the alias.

Answer

Include a provider block inside the module block with alias = 'uswest'.

Answer

Do nothing; Terraform automatically uses the default provider.

Question 6

A team uses Terraform Cloud for remote state management. They want to ensure that state file changes are only made through the Terraform Cloud API and not through direct access to the storage backend. Which feature should they enable?

Accepted Answer

Remote state locking. Remote state locking ensures that only one operation can modify the Terraform state at a time. When using Terraform Cloud as the remote backend, locking is automatically managed and prevents any direct modifications to the state file outside of a Terraform run. Because Terraform Cloud handles locking through its API, any attempt to directly access the storage backend would fail to acquire a lock, thus preventing changes. This effectively enforces that all state modifications go through the Terraform Cloud API.

Answer

Sentinel policy enforcement

Answer

VCS integration

Answer

Team tokens

Question 7

An organization uses Terraform Cloud to manage infrastructure across multiple teams. They need to enforce that all workspaces use a specific version of Terraform and that no workspace can be deleted accidentally. Which approach meets these requirements without using Sentinel or Terraform Enterprise?

Accepted Answer

Configure version constraints in the Terraform Cloud workspace settings and enable deletion protection.. Terraform Cloud allows configuring the Terraform version at the workspace level, ensuring a specific version is used. The 'Prevent deletion' option in workspace settings protects against accidental deletion. While per-workspace, administrators can enforce these settings across workspaces via API or organization defaults. Options A and B do not prevent deletion; Option C is incorrect because OPA is not natively integrated—Sentinel is the built-in policy engine but is excluded.

Answer

Include `required_version` in each workspace's root module and configure workspace locks in the UI.

Answer

Set `required_providers` with version constraints in a global Terraform file.

Answer

Use the Terraform Cloud API to write an OPA policy that enforces Terraform version and prevents workspace deletion.

Question 8

Refer to the exhibit. A developer runs `terraform apply` and the operation succeeds. Later, they manually terminate the EC2 instance through the AWS console. What will happen when the developer runs `terraform apply` again?

Accepted Answer

Terraform will recreate the EC2 instance and reassociate the Elastic IP. Terraform maintains the Elastic IP (EIP) association in its state file. When the EC2 instance is manually terminated outside of Terraform, the state still records the EIP as associated with that instance ID. On the next `terraform apply`, Terraform detects that the instance is missing (drift) and plans to recreate it, then reassociates the EIP to the new instance as defined in the configuration, ensuring the public IP remains attached.

Answer

The Elastic IP will be disassociated and the instance will be recreated

Answer

Terraform will only recreate the EC2 instance without reassociating the Elastic IP

Answer

The apply will fail because the Elastic IP is still attached to the terminated instance

Question 9

A Terraform configuration uses a module from the Terraform Registry. The module's documentation states it requires Terraform version >= 0.14. The team is using Terraform 0.12. What should the developer do to use this module?

Accepted Answer

Upgrade Terraform to a supported version.. The module explicitly requires Terraform >= 0.14, and the team is using Terraform 0.12, which lacks features or syntax changes introduced in later versions. Terraform modules from the Registry enforce version constraints via the `required_version` setting; using an incompatible version will cause a clear error during `terraform init` or `terraform plan`. The only reliable solution is to upgrade Terraform to a version that satisfies the module's requirement.

Answer

Fork the module and modify it to be compatible.

Answer

Add a version constraint in the module block to pin to an older compatible version.

Answer

Use the module as-is; the version requirement is only a recommendation.

Question 10

A startup is adopting Terraform to manage their cloud infrastructure. They want to ensure that changes to infrastructure are reviewed and approved before being applied. Which practice aligns with Infrastructure as Code principles to achieve this?

Accepted Answer

Implement a Git-based workflow with pull requests and automated plan reviews.. It aligns with Infrastructure as Code (IaC) principles by using a Git-based workflow where changes are proposed via pull requests, reviewed by peers, and validated through automated Terraform plan runs before merging. This ensures that all infrastructure modifications are version-controlled, auditable, and require explicit approval, preventing unauthorized or erroneous changes from being applied directly.

Answer

Use Terraform workspaces to separate environments and manually apply changes.

Answer

Store Terraform state files in a version control system to track changes.

Answer

Encourage developers to run terraform apply directly on production.

Question 11

A team uses Terraform to manage infrastructure. After running 'terraform apply', a developer notices that a new security group rule was added, but then immediately removed. What is the most likely cause?

Accepted Answer

The security group rule was added manually and Terraform removed it to match the configuration.. Terraform operates on a desired-state model: it compares the configuration in `.tf` files against the real-world infrastructure and the state file. If a security group rule was added manually outside of Terraform, Terraform detects it as a drift during the next `apply` and removes it to reconcile the actual state with the declared configuration. This is the core behavior of Terraform's lifecycle management.

Answer

The state file was corrupted and Terraform performed a refresh.

Answer

The configuration was changed to remove the rule after the apply.

Answer

The developer accidentally ran 'terraform destroy' instead.

Question 12

A developer runs terraform plan and sees a large number of resources will be destroyed. They suspect the state file is corrupted. They have a recent backup of the state file. Which command can help recover the previous state from the backup?

Accepted Answer

terraform state push. The `terraform state push` command is used to manually upload a local state file to the remote backend, overwriting the current remote state. In this scenario, the developer can use a recent backup of the state file and run `terraform state push` to restore the previous state, effectively recovering from the corruption. This command directly replaces the remote state with the specified local file, allowing Terraform to revert to the known good state.

Answer

No command can recover; they must re-import all resources.

Answer

terraform state rm

Answer

terraform state pull

Question 13

A team manages infrastructure with Terraform and uses a remote backend in an S3 bucket. After a recent state migration, a developer runs 'terraform plan' and gets an error: 'Error: Error loading state: NoSuchKey: The specified key does not exist.' The developer confirms that the state file exists in the bucket. What is the most likely cause?

Accepted Answer

The backend configuration in the Terraform code does not match the actual state file path.. The error 'NoSuchKey: The specified key does not exist' indicates that Terraform is looking for the state file at a specific key (path) in the S3 bucket, but that key does not exist. Since the developer confirms the state file exists in the bucket, the most likely cause is a mismatch between the backend configuration in the Terraform code (e.g., the `key` argument) and the actual path where the state file is stored. This often happens after a state migration if the backend configuration was not updated to reflect the new location.

Answer

Terraform state locking is enabled but the lock was not released.

Answer

The S3 bucket policy does not allow reading the state file.

Answer

S3 bucket versioning is enabled, and the state file is a non-current version.

Question 14

A developer creates a module that provisions an AWS EC2 instance and an S3 bucket. The module outputs the instance ID and bucket ARN. When using this module, the root configuration references module.my_module.instance_id and module.my_module.bucket_arn. After running terraform apply, they notice that the bucket ARN is empty. What is the most likely cause?

Accepted Answer

The output value in the module is defined incorrectly, e.g., referencing a non-existent attribute.. The most likely cause of an empty output value is that the output block in the module references an attribute that does not exist on the resource. For example, if the output is defined as `output "bucket_arn" { value = aws_s3_bucket.my_bucket.arn }` but the resource is actually `aws_s3_bucket.my_bucket` and the correct attribute is `arn`, a typo like `arnn` or `id` would cause Terraform to return an empty string (or an error during plan). Terraform validates attribute references at plan time, but if the attribute is missing or misspelled, the output value will be empty or cause a failure.

Answer

The output is defined in the module but not in the root configuration.

Answer

The S3 bucket creation depends on another resource that hasn't been created yet.

Answer

The IAM role used by Terraform does not have permission to read the bucket ARN.

Question 15

After adding a new module sourced from a Git repository with a specific tag, terraform init reports that the module is being downloaded. What is the best practice to ensure the team uses the same version of this module consistently?

Accepted Answer

Use a Git tag, like '?ref=v1.0.0', to pin the version.. Using a Git tag (e.g., `?ref=v1.0.0`) in the module source URL pins the module to a specific, immutable commit. This ensures that every team member downloads the exact same version of the module, regardless of future changes to the default branch. Terraform resolves the tag to a commit hash and caches it, providing deterministic and reproducible infrastructure.

Answer

Use a version constraint in the module block, e.g., version = 1.0.0.

Answer

Specify the source as the branch name 'main'.

Answer

Use the 'latest' tag in the source URL.

Question 16

A team is using Terraform for infrastructure as code. They want to ensure that the state file is stored securely and can be accessed by multiple team members. Which backend type should they use?

Accepted Answer

Remote backend such as Amazon S3 with DynamoDB state locking. A remote backend like Amazon S3 with DynamoDB state locking provides secure, centralized storage for the Terraform state file and enables state locking to prevent concurrent modifications. This setup ensures that multiple team members can safely access and update the state without conflicts, while S3 offers encryption and access control. Local backends or network shares lack these locking and security features, making them unsuitable for team collaboration.

Answer

The -state flag pointing to a network share

Answer

Using the -lock=false flag

Answer

Local backend with .terraform directory version-controlled

Question 17

An organization uses Terraform with a remote backend in Azure. After a network outage, a developer attempts to run `terraform apply` and receives the error: "Error: Failed to get existing workspaces: blob (key) not found". What is the most likely cause?

Accepted Answer

The state file for the current workspace was deleted or corrupted. The error 'blob (key) not found' indicates that Terraform cannot locate the state file for the current workspace in the Azure storage container. After a network outage, the state file may have been deleted or corrupted, preventing Terraform from reading the existing state. This error is specific to the missing blob key, not to authentication or storage account availability.

Answer

The Terraform backend configuration has incorrect access key

Answer

The Azure storage account was deleted

Answer

The workspace was not created via `terraform workspace new`

Question 18

You are a platform engineer at a large e-commerce company that uses Terraform Enterprise to manage thousands of infrastructure resources across multiple teams. The company has a central 'networking' workspace that provisions shared VPCs and subnets, and several application workspaces that consume these networking resources via remote state data sources. Recently, the networking team changed the CIDR block of a shared subnet from '10.0.1.0/24' to '10.0.2.0/24' and applied the change successfully. However, the application teams are now reporting that their Terraform runs are failing with errors indicating that the subnet ID they reference does not exist. The application workspaces use the following configuration to consume the subnet:

```hcl
data "terraform_remote_state" "networking" {
  backend = "remote"
  config = {
    organization = "mycompany"
    workspaces = {
      name = "networking"
    }
  }
}

resource "aws_instance" "app" {
  subnet_id = data.terraform_remote_state.networking.outputs.subnet_id
  ...
}
```

The application workspaces have not been modified recently. The networking workspace output 'subnet_id' now contains the ID of the updated subnet. What is the most likely cause of the failures?

Accepted Answer

The application workspaces are using a cached version of the remote state outputs and need to run 'terraform plan' to refresh.. Terraform caches remote state data during the planning phase, and the `terraform_remote_state` data source only fetches the latest state when `terraform plan` or `terraform apply` is executed. Since the application workspaces have not been modified or re-planned, they are using a stale cached version of the networking workspace's outputs, which still contains the old subnet ID. Running `terraform plan` forces a refresh of the remote state data, retrieving the updated `subnet_id` and resolving the error.

Answer

The application workspaces do not have permission to read the networking workspace's state.

Answer

The networking workspace output variable 'subnet_id' was removed or renamed.

Answer

The application workspaces need to update the remote state data source to reference the new subnet ID.

Question 19

An organization uses Terraform with the AzureRM backend. The team recently split a large configuration into multiple smaller configurations, each with its own state file. They want to share outputs from one configuration (networking) as inputs to another (compute). Which approach should they use to reference the networking state from the compute configuration without duplicating data?

Accepted Answer

Use a 'data' 'terraform_remote_state' block in the compute configuration to read the networking state.. The `terraform_remote_state` data source allows one Terraform configuration to read the root-level output values from another configuration's state file stored in the AzureRM backend. This enables sharing of networking outputs (e.g., subnet IDs) into the compute configuration without duplicating data or manually exporting values. The data source retrieves the state directly from the configured backend, ensuring the compute configuration always uses the latest networking outputs.

Answer

Define output values in the networking configuration and they will be automatically available in the compute configuration.

Answer

Run 'terraform output' on the networking state and save the values to a JSON file, then use 'terraform_remote_state' to read them.

Answer

Hardcode the subnet IDs from the networking configuration into the compute configuration.

Question 20

A team has been manually modifying cloud resources outside of Terraform. They now find that Terraform plans show changes that don't match their expectations. What core concept of Terraform's purpose does this situation violate?

Accepted Answer

Declarative configuration with desired state. Terraform's core purpose is to manage infrastructure through a declarative configuration that defines the desired state. When users manually modify cloud resources outside of Terraform, the actual state diverges from the desired state defined in the configuration. Terraform detects this drift and plans changes to reconcile the actual state back to the desired state, which may include unexpected modifications or deletions. This violates the fundamental principle that Terraform should be the single source of truth for infrastructure state.

Answer

Idempotency

Answer

Immutable infrastructure

Answer

Procedural scripting