Terraform-Associate-004 Practice Questions

The statement is false because the command provided, terraform fnt, is incorrect. The correct command to rewrite Terraform configuration files to a canonical format and style is terraform fmt. The fmt command recursively scans the current directory and applies standard Terraform formatting conventions, such as alignment and spacing, to all .tf and .tf.json files it finds. Executing terraform fnt would result in an error, as it is not a valid Terraform CLI command.

The statement would be considered "True" only if the command were correctly written as terraform fmt. The typo (fnt instead of fmt) makes the entire statement factually incorrect, as the specified command does not exist and will not perform the described action.

1. HashiCorp Developer Documentation, "Terraform CLI - fmt Command": This official documentation page explicitly names the command as fmt. It states, "The terraform fmt command is used to rewrite Terraform configuration files to a canonical format and style." The page does not list fnt as a valid command or alias.

Source: HashiCorp, Terraform CLI Commands, "fmt". Retrieved from https://developer.hashicorp.com/terraform/cli/commands/fmt

2. HashiCorp Developer Documentation, "Format Configuration" Tutorial: This official tutorial guides users on code formatting. The first step instructs the user to "Run the terraform fmt command to format the configuration in your current directory." This reinforces that fmt is the correct command for this purpose.

Source: HashiCorp, Terraform Tutorials, "Format Terraform Configuration". Retrieved from https://developer.hashicorp.com/terraform/tutorials/cli/format

3. HashiCorp Developer Documentation, "Terraform CLI - Commands (Index)": The main index of all available Terraform CLI commands lists fmt but does not include fnt or any similar command, confirming that fnt is not a recognized command.

Source: HashiCorp, Terraform CLI, "Commands". Retrieved from https://developer.hashicorp.com/terraform/cli/commands

The statement is incorrect. Child modules in Terraform do not automatically inherit variable values from their parent module. A parent module must explicitly pass values to the input variables declared in the child module. This is done by setting arguments within the module block that calls the child. This explicit passing of variables is a fundamental design principle of Terraform that ensures modules are encapsulated, predictable, and reusable. If a required input variable in a child module is not assigned a value in the module block (and it does not have a default value), Terraform will return an error during the planning phase.

The "True" option is wrong because it describes a behavior of automatic, implicit inheritance. Terraform's module system is designed to be explicit. The interface between a parent and child module is strictly defined by the child's input variables and outputs. Values must be deliberately passed into the module, not assumed or inherited from the parent's scope.

1. HashiCorp Terraform Documentation, "Calling a Child Module": This document explicitly states how to pass values to a child module. It says, "The arguments of a module block correspond to the input variables of the module." The provided examples show explicit assignment for each variable being passed.

Source Reference: In the "Module Arguments" section, it details the syntax: argumentname = . This demonstrates that each value must be explicitly assigned.

2. HashiCorp Terraform Documentation, "Input Variables": This page clarifies the different ways variables can be assigned. For modules, it is unambiguous.

Source Reference: Under the section "Assigning Values to Module Input Variables," the documentation states: "When you call a module from a parent configuration, you set values for its input variables using arguments in the module block." This directly contradicts the idea of automatic inheritance.

3. HashiCorp Terraform Learn, "Create and Use a Local Module": This official tutorial guides users through the process of creating and calling a module, reinforcing the concept of explicit variable passing.

Source Reference: In the section "Pass data with an input variable," the tutorial demonstrates adding a variable "serverport" to a module and then explicitly setting it in the root main.tf file with the line serverport = 8080 inside the module "webserver" block. This practical example shows that assignment is a required, explicit step.

The terraform validate command is used to perform a static check of the Terraform configuration files in the current directory. Its primary function is to verify that the configuration is syntactically valid and internally consistent. This includes checking for correct syntax, proper block structure, valid attribute names, and appropriate value types, all without accessing remote services or state.

The statement is not False. While the validate command also checks for internal consistency beyond pure syntax (like ensuring resource arguments are valid for the specified provider), checking for syntactic correctness is a fundamental and explicitly stated purpose of the command. Therefore, the assertion that it "confirms the syntax" is accurate.

1. HashiCorp Terraform Documentation, validate Command: "The terraform validate command validates the configuration files in a directory... Validate runs checks that verify whether a configuration is syntactically valid and internally consistent, regardless of any provided variables or existing state. It is thus primarily useful for general verification of reusable modules, including correctness of attribute names and value types."

Source: HashiCorp, Terraform CLI - Command: validate. Retrieved from https://developer.hashicorp.com/terraform/cli/commands/validate

2. HashiCorp Terraform Associate 004 Exam Study Guide: The study guide lists terraform validate under objective 1c, "Demonstrate use of Terraform CLI (outside of core workflow)." The purpose of this command aligns with preparing configurations for execution, which begins with ensuring they are syntactically correct.

Source: HashiCorp, Study Guide - Terraform Associate Certification 004. Retrieved from https://developer.hashicorp.com/terraform/tutorials/certification-003/associate-study-guide#demonstrate-use-of-terraform-cli-outside-of-core-workflow (Note: The 003 guide is the current reference for the 004 exam objectives).

The terraform state rm command removes the record of a resource from the Terraform state file. This action does not destroy the actual, real-world infrastructure object. It simply tells Terraform to no longer manage that resource. The resource will continue to exist in the cloud provider's environment, but it becomes "orphaned" from the Terraform configuration that created it. To destroy the infrastructure itself, you must use the terraform destroy command.

The statement is false because it incorrectly equates state file manipulation with infrastructure lifecycle management. The terraform state subcommand family is designed for advanced state manipulation, which is separate from the standard plan/apply/destroy workflow that affects real resources.

1. HashiCorp Terraform Documentation, "Command: state rm": The official documentation explicitly states, "This does not destroy the infrastructure represented by the item, but it does remove the binding from the state. If you want to destroy the item, use terraform destroy instead." This directly refutes the premise of the question.

Source: HashiCorp Terraform CLI Documentation, developer.hashicorp.com/terraform/cli/commands/state/rm

2. HashiCorp Learn, "Manage Resources in Terraform State": This official tutorial provides a practical example and clarifies the command's purpose. In the section "Remove a resource from Terraform state," it guides the user to run terraform state rm and then confirms, "Terraform no longer manages this S3 bucket, but the bucket still exists in your AWS account."

Source: HashiCorp Learn, developer.hashicorp.com/terraform/tutorials/state/state-rm

The statement is false. Terraform modules are designed to be encapsulated, self-contained packages of configuration. Input variables are used to pass data into a module from a calling configuration. However, the variables, local values, and resources defined within a module are scoped locally to that module and are not directly accessible from the outside. To expose a value from a module to the parent (calling) module, an output value must be explicitly declared.

The "True" option is incorrect because it violates the fundamental principle of module encapsulation in Terraform. If internal variables were directly accessible, it would create tightly-coupled configurations, making modules less reusable, harder to maintain, and less predictable. The designated mechanism for returning data from a module is through output blocks, which act as a formal API for the module.

1. HashiCorp Terraform Documentation, "Input Variables": This source clarifies that input variables serve as parameters for a module, allowing a parent module to pass data into the child module. It does not describe a mechanism for accessing them from the outside. The documentation states, "Input variables serve as parameters for a Terraform module, allowing aspects of the module to be customized without altering the module's own source code, and allowing modules to be shared between different configurations." This defines their role as an input mechanism only.

Source: HashiCorp, "Terraform / Language / Modules / Input Variables".

2. HashiCorp Terraform Documentation, "Output Values": This is the most direct source refuting the statement. It explicitly defines output values as the sole method for exporting data from a module. The documentation states, "Output values are like the return values of a module... They are a way to expose some information about the resources a module creates to the module that called it." This confirms that a specific construct (output) is required to make data accessible outside the module.

Source: HashiCorp, "Terraform / Language / Modules / Output Values".

3. HashiCorp Terraform Documentation, "Module Composition": This section describes the benefits of modules, including encapsulation. It explains that modules are self-contained and interact with parent modules through a defined interface of input variables and output values. "A good module has a clean separation between its implementation details and its inputs and outputs. This makes the module easier to understand and to change over time." This principle of a "clean separation" is violated if internal variables are directly accessible.

Source: HashiCorp, "Terraform / Language / Modules / Module Composition".

The terraform init command is responsible for preparing a working directory for use with Terraform. One of its primary tasks is module installation. During this process, Terraform scans the configuration for any module blocks that reference remote sources (such as the Terraform Registry, Git repositories, or HTTP URLs). It then downloads the source code for these modules and stores them in a local subdirectory named .terraform/modules. This local copy serves as a cache, ensuring that subsequent commands like plan and apply have access to the complete configuration code.

The statement is a correct description of a core function of the terraform init command. Therefore, selecting "False" would be incorrect. If terraform init did not retrieve and cache remote modules, Terraform would be unable to interpret the full configuration, and commands like terraform plan or terraform apply would fail because they would lack the resource definitions contained within those modules.

1. HashiCorp Terraform Documentation, "Command: init": In the "Module Installation" section, the documentation states, "During init, the root module's configuration is searched for module blocks, and the source code for referenced modules is retrieved from the locations given in their source arguments... Terraform will download and cache the module in a subdirectory of the .terraform/modules directory in your working directory."

Source: HashiCorp, Terraform CLI Documentation, "Command: init", section "Module Installation". Retrieved from https://developer.hashicorp.com/terraform/cli/commands/init#module-installation.

2. HashiCorp Terraform Documentation, "Module Sources": This page details how modules are sourced and explicitly links this action to the init command. It states, "When you run terraform init, Terraform will read the source argument for each of your modules and download the module's files into a subdirectory of your .terraform/modules directory."

Source: HashiCorp, Terraform Language Documentation, "Module Sources". Retrieved from https://developer.hashicorp.com/terraform/language/modules/sources#module-sources.

The terraform validate command is a static, local operation that checks the syntax and internal consistency of Terraform configuration files. It verifies that the code is syntactically correct and consistent with the schemas of the providers and modules defined in the configuration. It does not make any network calls to provider APIs to verify resource settings or credentials. This command is designed to be a quick, offline check before committing code or running a plan.

The statement is false because it incorrectly describes the function of terraform validate. The command that interacts with provider APIs to check the validity of settings against the remote infrastructure is terraform plan. During the plan phase, Terraform refreshes the state and communicates with the provider APIs to determine what changes are needed, which implicitly validates many settings against the target platform. terraform validate strictly operates on the local files and downloaded provider schemas.

1. HashiCorp Terraform Documentation, "Command: validate": "The terraform validate command validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc. Validate runs checks that verify whether a configuration is syntactically valid and internally consistent, regardless of any provided variables or existing state."

2. HashiCorp Terraform Documentation, "Core Terraform Workflow - Validate Configuration": "Validate checks your configuration for syntax errors and internal consistency. It does not access any remote services, such as provider APIs or state. This means validate cannot check that your provider credentials are correct, or that the arguments for a specific resource are valid for your infrastructure."

3. HashiCorp Learn, "Validate Terraform Configuration": "The terraform validate command checks your configuration for syntax errors and internal consistency. Validation requires an initialized working directory with the necessary providers, but does not connect to the providers to check your configuration. This lets you run validation without providing credentials for your providers."

The version argument within a module block is not required when referencing a module from the Terraform Module Registry. While specifying a version is a strongly recommended best practice to ensure configuration stability and prevent breaking changes from new module releases, it is an optional argument. If the version argument is omitted, Terraform will automatically download and use the latest available version of the module.

The statement is "True" is incorrect because the version argument is explicitly defined as optional in the Terraform language specification for module blocks. Terraform has a default behavior (use the latest version) when the argument is not present, which confirms it is not a mandatory requirement for the configuration to be valid.

1. HashiCorp Terraform Documentation, "Module Sources": In the section titled "Terraform Registry," the documentation states: "The version argument is optional. If omitted, Terraform will download the latest version of the module that is compatible with the other constraints in the configuration." This directly confirms that the argument is not required.

2. HashiCorp Terraform Documentation, "The module Block": In the description of the version meta-argument, the documentation says: "We recommend explicitly constraining the module version to avoid unexpected or unwanted changes." The use of the word "recommend" indicates that it is a best practice, not a requirement.

3. HashiCorp Learn, "Use Modules from the Terraform Registry": This tutorial explains the components of a module block sourced from the registry. It describes the version argument as a way to "tell Terraform which version of the module to use" and recommends setting it, but does not state it is a requirement for the block to function.

The terraformremotestate data source is used to fetch the root module outputs of a separate Terraform configuration. While its name implies it is only for remote backends (like S3, AzureRM, or Terraform Cloud), it is also explicitly designed to work with state files stored on the local filesystem. To achieve this, the backend argument within the data source block is set to "local", and the config block must specify the path to the terraform.tfstate file.

The statement is not False. A common misconception is that the terraformremotestate data source can only target backends that are network-accessible or "remote." However, the official implementation and documentation confirm that "local" is a valid backend type for this data source, allowing it to read state files directly from the local disk.

1. HashiCorp Terraform Documentation, terraformremotestate Data Source: The official documentation provides a direct example of this usage. In the "Example Usage" section, it shows how to configure the data source with backend = "local" and a config block containing the path to the state file.

Source: HashiCorp, Terraform Documentation.

Reference: Data Sources > terraformremotestate > Example Usage. The example explicitly states:

hcl

data "terraformremotestate" "vpc" {

backend = "local"

config = {

path = "../vpc/terraform.tfstate"

}

}

2. HashiCorp Terraform Documentation, Backends - local: This page describes the local backend, which stores the state file on the local filesystem. The terraformremotestate data source can be configured to read from a state file managed by this backend type.

Source: HashiCorp, Terraform Documentation.

Reference: Terraform > Backends > Types > local. This page confirms that the local backend stores state in a local file named terraform.tfstate by default, which is the target file for the terraformremotestate data source when using the local backend type.

The statement is false because speculative plans in a Terraform Cloud workspace linked to a Version Control System (VCS) are not triggered by direct commits or merges to the tracked branch. Instead, they are specifically triggered when a pull request (or merge request) is opened against the tracked branch. The purpose of a speculative plan is to allow for review and validation of proposed changes before they are merged into the main codebase. A direct commit or merge to the tracked branch triggers a standard plan, not a speculative one.

The statement would be true if it correctly identified the trigger for a speculative plan. However, it incorrectly states that merges or commits trigger these plans. This confuses the trigger for a standard run (commits/merges to the tracked branch) with the trigger for a speculative plan (opening a pull request).

1. HashiCorp Terraform Documentation, "Run Modes and Options": In the section on Speculative Plans, the documentation explicitly states, "Terraform Cloud can also run speculative plans on pull requests to the chosen VCS branch, which helps you verify the changes before merging them." This clarifies that the trigger is a pull request, not a direct commit or merge.

Source: HashiCorp, Terraform Cloud Documentation, "Run Modes and Options", section "Speculative Plans". Retrieved from https://developer.hashicorp.com/terraform/cloud-docs/run/modes-and-options#speculative-plans

2. HashiCorp Terraform Documentation, "VCS-Driven Workflow": This page details the different triggers for runs. It distinguishes between the two main triggers: "When you push new commits to a VCS branch that is associated with a Terraform Cloud workspace, Terraform Cloud automatically queues a plan..." and "When you open a pull request against a branch that is associated with a Terraform Cloud workspace, Terraform Cloud runs a speculative plan with the code from the pull request." This directly refutes the question's premise.

Source: HashiCorp, Terraform Cloud Documentation, "Workspaces > VCS-Driven Workflow", section "Run Triggers". Retrieved from https://developer.hashicorp.com/terraform/cloud-docs/workspaces/vcs#run-triggers