How many Troubleshooting Scenario Questions questions are on this page?

This page has 5 Troubleshooting Scenario Questions scenario questions for the TF-004 exam, each with detailed explanations and wrong-answer analysis.

How should I approach TF-004 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to HashiCorp Terraform Associate TF-004 questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise HashiCorp Terraform Associate TF-004 practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

TF-004

exam code

HashiCorp

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

Refer to the exhibit. A team is troubleshooting a Terraform deployment. What information can be inferred from this state file?

Exhibit

{
  "version": 4,
  "terraform_version": "1.5.0",
  "resources": [
    {
      "mode": "managed",
      "type": "aws_instance",
      "name": "web",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "attributes": {
            "id": "i-0a1b2c3d4e5f67890",
            "instance_type": "t2.micro"
          },
          "dependencies": [
            "aws_security_group.web_sg"
          ]
        }
      ]
    }
  ]
}

A
The Terraform version is outdated and must be upgraded.
Why it fails: Terraform version 1.5.0, as indicated in the exhibit, is a relatively recent release within the 1.x series. HashiCorp maintains a stable 1.x branch, with new minor versions frequently introducing enhancements and bug fixes rather than deprecating previous minor versions within the same major release. Therefore, there is no inherent indication that this specific version is outdated or requires an immediate upgrade for basic functionality, especially without encountering specific version-related errors.
B
There is one EC2 instance of type t2.micro with a dependency on a security group.
The Terraform state file, as presented in the exhibit, explicitly shows a single `aws_instance` resource. Within its attributes, `instance_type` is clearly set to `t2.micro`. Furthermore, the `vpc_security_group_ids` attribute contains an array with one entry, indicating an explicit dependency on a security group resource. This direct evidence from the state confirms the presence and configuration of the EC2 instance and its security group association.
C
The instance ID is invalid and needs to be recreated.
Why it fails: The instance ID `i-0a1b2c3d4e5f6a7b8` follows the standard AWS EC2 instance ID format, which typically starts with `i-` followed by 17 alphanumeric characters. There is no information in the exhibit to suggest this ID is invalid, corrupted, or causing any operational issues. Terraform manages resource IDs internally, and an invalid ID would likely manifest as an API error during apply or refresh operations, which is not indicated here.
D
The security group dependency was not applied.
Why it fails: The Terraform state explicitly records the `vpc_security_group_ids` attribute for the `aws_instance` resource, indicating that the dependency on a security group *was* successfully applied and associated with the instance during its creation or last update. The presence of this attribute in the state confirms Terraform's successful application of the configuration. If the security group itself were missing or misconfigured, it would be a separate issue, but the dependency itself was indeed applied.

Full breakdown with real-world context →

Question 2hardmultiple choice

Review the full subnetting walkthrough →

Your organization manages a multi-cloud infrastructure using Terraform. The infrastructure includes an AWS VPC with subnets and EC2 instances, and an Azure resource group with virtual networks and VMs. The Terraform configuration is stored in a Git repository, and state is stored in an S3 bucket with DynamoDB locking. Recently, a developer updated the configuration to add a new security group rule in AWS, but after running `terraform apply`, the rule was not created. The developer verified that the configuration file contains the rule. Additionally, the developer noticed that the state file shows the security group exists but without the new rule. The developer ran `terraform plan` again, and it shows that the rule will be created. However, when applying, it fails with a 'timeout' error. The operations team suspects network connectivity issues to the S3 backend. What is the best course of action to resolve this issue?

A
Run `terraform init` again to reinitialize the backend.
Why it fails: Running `terraform init` again primarily configures the backend, downloads providers, and initializes modules. While it establishes the backend connection, it does not inherently resolve underlying network connectivity issues or transient timeouts between the local machine and the remote state backend. If the network path itself is unstable or congested, re-running `init` will likely encounter the same timeout, as it is not a diagnostic or remediation tool for network infrastructure problems.
B
Migrate the state backend to Terraform Cloud, and use remote operations for applies.
Migrating the state backend to Terraform Cloud and utilizing remote operations offloads the execution of `terraform apply` from the local machine to HashiCorp's managed infrastructure. This approach effectively bypasses local network instability, proxy configurations, or firewall restrictions that might be causing timeouts when accessing the state backend or provider APIs from the local environment. Terraform Cloud's robust and highly available execution environment ensures reliable communication with the state backend and target cloud providers.
C
Increase the timeout value in the Terraform provider configuration.
Why it fails: Increasing the timeout value within a Terraform *provider* configuration, such as for AWS or Azure, only affects the duration Terraform waits for responses from the *cloud provider's API* during resource creation or modification. This setting has no impact on the connectivity or timeout issues experienced when Terraform attempts to communicate with its own *state backend*, which is a separate network operation. The problem lies in accessing the state file, not in the subsequent interaction with cloud resources.
D
Disable state locking by removing the DynamoDB table reference.
Why it fails: Disabling state locking by removing the DynamoDB table reference, which is typically used for robust locking with S3 backends, would indeed bypass any locking-related timeouts. However, this action introduces a critical risk of state corruption, especially in collaborative environments. Without state locking, multiple concurrent `terraform apply` operations could attempt to modify the state file simultaneously, leading to data loss, inconsistent infrastructure, or unrecoverable errors. It is a dangerous workaround that compromises state integrity.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

A developer is troubleshooting a Terraform configuration that fails during `terraform plan` with the error: "Error: Invalid reference". The error points to a line that references `var.environment` in a module block. What is the most likely cause?

A
The Terraform version does not support module variables
Why it fails: Terraform has supported the concept of passing variables to child modules since its very early versions (e.g., 0.6+). This is a fundamental mechanism for abstracting and reusing configuration blocks, allowing modules to be parameterized. Therefore, an error indicating an undefined variable within a module context is highly unlikely to be caused by a lack of version support for module variables themselves. The issue typically lies with the *declaration* of the variable within the specific module's scope.
B
The variable `var.environment` is not defined in the root module's variables.tf
Why it fails: While the root module *does* need to define `var.environment` if it intends to pass a value named `environment` to a child module, the error message described typically arises when the *child module itself* attempts to reference `var.environment` *internally* without having declared it. The root module's definition of `var.environment` is for its own scope and for providing input to the child, not for satisfying the child's internal variable declarations. The problem occurs when the child module tries to use an undeclared input.
C
The variable `environment` is not defined in the child module's variables.tf
When a child module receives input values, it must explicitly declare those inputs as variables within its own scope, typically in a `variables.tf` file inside the module's directory. If the root module attempts to pass a value like `environment = var.environment` to a child module, the child module must have a corresponding `variable "environment" {}` block defined to accept that input. Without this declaration, the child module will report an error indicating an undefined variable when it tries to use `var.environment` internally, as it does not recognize `environment` as a valid input.
D
The module source path is invalid
Why it fails: An invalid module source path, such as a typo in the local directory path or an unreachable remote repository, would typically result in a "Module not found" or "Failed to download module" error during the `terraform init` phase. This type of error occurs much earlier in the Terraform workflow, specifically during the module discovery and download process. It would not manifest as an undefined variable error during the plan or apply phase, which is when variable resolution issues usually become apparent.

Full breakdown with real-world context →

Question 4mediummultiple choice

Full question →

A company uses Terraform to manage infrastructure in multiple AWS accounts. An engineer runs terraform plan and sees that a security group rule will be updated, but the change is not intended. The engineer wants to understand why Terraform is proposing the change without affecting other resources. Which approach should the engineer take to troubleshoot?

A
Run terraform state list to review the current state.
Why it fails: Running `terraform state list` only enumerates the resource addresses currently tracked within the Terraform state file. It provides a simple list of managed resources and their unique identifiers, but it does not perform any comparison against the current configuration or the remote infrastructure. Therefore, this command cannot reveal any proposed changes that would occur if a new configuration were applied.
B
Run terraform show to display the current state.
Why it fails: Running `terraform show` without specifying a plan file will display the current state of the infrastructure as recorded in the `terraform.tfstate` file. While `terraform show` can indeed display the contents of a plan, it explicitly requires a plan file argument (e.g., `terraform show plan.tfplan`) to do so. Consequently, this command alone does not generate or reveal any proposed changes based on the current configuration.
C
Run terraform validate to check for configuration errors.
Why it fails: `terraform validate` performs a static analysis of the Terraform configuration files, primarily checking for syntax errors, attribute type mismatches, and other internal consistency issues. It ensures the configuration is syntactically correct and valid according to Terraform's language rules. However, `validate` does not interact with the state file or remote providers, nor does it generate an execution plan, making it incapable of showing proposed infrastructure changes.
D
Run terraform plan -out=plan.tfplan and then terraform show plan.tfplan.
This two-step approach is the correct method for reviewing proposed infrastructure changes before applying them. `terraform plan -out=plan.tfplan` first generates a detailed execution plan by comparing the current configuration with the existing state and remote infrastructure, saving it to a specified file. Subsequently, `terraform show plan.tfplan` allows for a comprehensive, human-readable inspection of all proposed actions (creations, updates, deletions) contained within that saved plan file, without applying them.

Full breakdown with real-world context →

Question 5hardmultiple choice

Full question →

A DevOps engineer is troubleshooting a failed 'terraform apply'. The error message says: 'Error: Error applying IAM policy: The policy failed validation'. The IAM policy is defined using HCL in a JSON-encoded string. What is the most efficient way to debug this issue?

A
Run 'terraform plan' to see the detailed error.
Why it fails: terraform plan primarily focuses on generating an execution plan by comparing the desired state with the current infrastructure and validating HCL syntax. It does not typically perform deep API-level validation of resource attributes like IAM policy JSON content for correctness against the cloud provider's schema or grammar. Policy validation errors, especially those related to malformed JSON or invalid policy statements, are usually encountered during the terraform apply phase when the provider attempts to send the policy to the cloud API.
B
Use 'terraform console' to test the policy string.
Why it fails: terraform console is an interactive command-line tool designed for evaluating Terraform expressions, interpolating variables, and testing logic within the configuration. While it can confirm if a string is valid JSON from a pure HCL perspective (e.g., jsondecode("...")), it lacks the capability to validate the semantic correctness or API-specific schema of an IAM policy document against a cloud provider's requirements. It cannot simulate the provider's API call to check policy validity.
C
Use a JSON validator tool to check the policy string in the configuration.
A JSON validator tool is highly effective for identifying fundamental syntax errors within an IAM policy string embedded in Terraform configuration. These tools can quickly pinpoint issues like malformed JSON structure, incorrect escaping, missing commas, or unclosed brackets, which are common causes of policy validation failures. Catching these errors locally prevents terraform apply from failing due to basic JSON parsing issues, allowing the DevOps engineer to correct the policy before deployment attempts.
D
Upgrade to the latest Terraform version.
Why it fails: Upgrading to the latest Terraform version is unlikely to resolve an issue stemming from a malformed IAM policy string within the configuration. Terraform version updates primarily address core CLI functionality, HCL language features, or provider compatibility, not the correctness of user-supplied data like JSON policy documents. A syntax error in the policy itself is a configuration issue, not a bug or limitation of the Terraform CLI version.

Full breakdown with real-world context →

These TF-004 practice questions are part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style TF-004 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related TF-004 topic practice pages

Use Terraform outside the core workflow practice questions

Understand IaC concepts practice questions

Interact with Terraform modules practice questions

Understand Terraform's purpose practice questions

Understand Terraform basics practice questions

Implement and maintain state practice questions

Use the core Terraform workflow practice questions

Read, generate and modify configuration practice questions

TF-004 fundamentals practice questions

TF-004 scenario practice questions

TF-004 troubleshooting practice questions

Practice scenarios

Refer to the exhibit. A team is troubleshooting a Terraform deployment. What information can be inferred from this state file?

Exhibit

A developer is troubleshooting a Terraform configuration that fails during `terraform plan` with the error: "Error: Invalid reference". The error points to a line that references `var.environment` in a module block. What is the most likely cause?

A DevOps engineer is troubleshooting a failed 'terraform apply'. The error message says: 'Error: Error applying IAM policy: The policy failed validation'. The IAM policy is defined using HCL in a JSON-encoded string. What is the most efficient way to debug this issue?