The Terraform state file's primary purpose is to store the state of managed infrastructure resources, mapping them to your configuration. It does not store the names or values of the input variables that are declared in your .tf files. The state file records the attributes of the created resources and the values of any output variables. The input variable declarations and their names are part of the configuration code itself, not the resulting state.

The statement "True" is incorrect because the state file is not a mirror of your configuration code. Its role is to track the real-world resources that Terraform manages. While the values of output variables are stored in the state to be easily queried and used by other configurations, the input variables used to generate the plan are not persisted there.

1. HashiCorp Terraform Documentation, "Purpose of Terraform State": This document explains that the state file is used for mapping resources to configuration, tracking metadata, and improving performance. It details what is stored, focusing on managed resources and their attributes. It makes no mention of storing input variable names.

Source: HashiCorp, "Purpose of Terraform State," Terraform Documentation.

Reference: "State is used by Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures... This state is stored by default in a local file named terraform.tfstate..."

2. HashiCorp Terraform Documentation, "Input Variables": This page describes how input variables serve as parameters for a Terraform module, allowing aspects of the configuration to be customized without altering the source code. Their scope and purpose are confined to the configuration and planning phase, not the state file.

Source: HashiCorp, "Input Variables," Terraform Documentation.

Reference: "Input variables let you customize aspects of Terraform modules without altering the module's own source code. This allows you to share modules across different Terraform configurations, making your module composable and reusable."

3. HashiCorp Terraform Documentation, "Output Values": This source explicitly states that output values are stored in the state file, which contrasts with input variables. This highlights that only a specific type of variable-related data is stored.

Source: HashiCorp, "Output Values," Terraform Documentation.

Reference: "Output values are like the return values of a Terraform module... When you run terraform apply, Terraform prints the values of your outputs to the screen. You can also use the terraform output command to query them. The values of root module outputs are also stored in the state file."

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 statement is false. The TFLOG environment variable is used to enable detailed logging and set the verbosity level (e.g., TRACE, DEBUG, INFO). However, to direct the log output to a specific file, you must use the TFLOGPATH environment variable. If TFLOGPATH is not set, the log output is directed to the stderr stream, not a file.

The statement is incorrect because it misattributes the function of directing logs to a file to the TFLOG variable. The core function of TFLOG is to control the level of logging, while the separate TFLOGPATH variable controls the destination of the log output when that destination is a file.

1. HashiCorp Terraform Documentation, "Environment Variables":

TFLOG: "This is a legacy environment variable. To enable detailed logs, set TFLOG to one of the log levels (TRACE, DEBUG, INFO, WARN, ERROR) to display detailed logs for that level and higher. When TFLOG is set, the logs are written to stderr."

TFLOGPATH: "Sets a path to a file that Terraform will use to write detailed logs. If TFLOGPATH is set, TFLOG must also be set. For example, TFLOG=TRACE TFLOGPATH=terraform.log."

Source: HashiCorp, "Terraform CLI - Configuration - Environment Variables", developer.hashicorp.com/terraform/cli/config/environment-variables. Accessed May 2024.

2. HashiCorp Learn, "Debug Terraform" Tutorial:

Section: "Enable Logging": This tutorial explicitly demonstrates the combined use of both variables. It states, "To persist the log to a file, set the TFLOGPATH environment variable to your desired log file. You must set TFLOG for TFLOGPATH to have an effect." This clarifies that TFLOG alone does not configure file-based logging.

Source: HashiCorp Learn, "Debug Terraform", developer.hashicorp.com/terraform/tutorials/debug/debug-terraform. Accessed May 2024.

Local values (locals) are scoped to the module in which they are defined and are not directly accessible by a calling (parent) module. The designated mechanism for a module to expose data to its caller is through output values (output). An output block can be defined within the module, and its value argument can be set to any valid expression, including a reference to a local value. This effectively makes the internal local value part of the module's public interface, allowing the parent module to access it.

The statement "False" would be incorrect. This describes the standard and intended design pattern for module composition in Terraform. Modules encapsulate logic, and outputs provide a controlled interface for returning results. Denying that an output can expose a local value would contradict this fundamental principle of module architecture.

1. HashiCorp Terraform Documentation, "Local Values": This document establishes the scope of local values. It states, "A local value can only be accessed in expressions within the module where it was defined." This confirms their private nature, necessitating a mechanism like outputs for external access.

Source: HashiCorp, "Local Values - Configuration Language," Terraform Documentation. Available at: https://developer.hashicorp.com/terraform/language/values/locals

2. HashiCorp Terraform Documentation, "Output Values": This document defines the purpose of outputs. It explains, "Output values are like the return values of a module... The value argument takes an expression whose result is to be returned to the user." This confirms that an output's value can be derived from an expression, which can include a local value.

Source: HashiCorp, "Output Values - Configuration Language," Terraform Documentation. Available at: https://developer.hashicorp.com/terraform/language/values/outputs

3. HashiCorp Terraform Documentation, "Module Blocks": This document describes how modules interact, specifically how a parent module accesses the outputs of a child module. The section on "Accessing Module Output Values" shows the syntax module.., which is how the calling module would consume the local value that has been exposed via an output.

Source: HashiCorp, "Module Blocks - Configuration Language," Terraform Documentation. Available at: https://developer.hashicorp.com/terraform/language/modules/syntax#accessing-module-output-values

The statement presents the order of operations incorrectly. The correct process is to first configure the backend within a Terraform configuration file (e.g., main.tf) by adding a backend block. After the configuration is written, you run the terraform init command to initialize the backend, which involves reading the configuration, validating it, and preparing it for use.

The statement "True" is incorrect because initialization is the action that processes the pre-existing backend configuration. You cannot initialize a backend that has not yet been defined or configured in your .tf files.

1. HashiCorp Terraform Documentation, "Backend Configuration":

Location: developer.hashicorp.com/terraform/language/settings/backends/configuration

Section: "Using a Backend Block"

Quote/Paraphrase: The documentation explicitly states, "To configure a backend, you add a nested backend block within the top-level terraform block... After adding a backend block to your configuration, you must run terraform init again to apply the change." This demonstrates that configuration precedes initialization.

2. HashiCorp Terraform Documentation, "Command: init":

Location: developer.hashicorp.com/terraform/cli/commands/init

Section: "Backend Initialization"

Quote/Paraphrase: This section explains that "During init, Terraform searches the configuration for a backend block..." This confirms that the init command acts upon a configuration that is already present in the files.

3. HashiCorp Learn, "Store and Manage State" Tutorial:

Location: developer.hashicorp.com/terraform/tutorials/state/store-manage

Section: "Configure the S3 backend"

Quote/Paraphrase: The tutorial guides the user to first add the backend "s3" block to their main.tf file (configuration step) and then run terraform init to migrate the state (initialization step). This practical example reinforces the correct order of operations.

The statement is false because of the absolute term "always". While the default behavior of terraform init is to download providers from the public, internet-facing HashiCorp Terraform Registry, Terraform provides multiple mechanisms for installing providers from other locations. This is essential for operating in air-gapped environments, for security compliance, or for using custom-developed internal providers. Terraform can be configured to install providers from a local filesystem mirror, a private network mirror, or a private registry.

The statement "True" is incorrect because it overlooks Terraform's explicit support for alternative provider installation methods beyond the public internet. The providerinstallation block in the Terraform CLI configuration allows operators to define non-default installation strategies, such as sourcing providers from a local directory (filesystemmirror) or an internal artifact repository (networkmirror), which do not require internet access to the public registry.

1. HashiCorp Terraform Documentation, "Provider Installation": This document explicitly details alternative installation methods. It states, "For air-gapped systems or to ensure you're only using approved providers, you can configure Terraform to use a local provider mirror."

Source: HashiCorp Terraform Official Documentation.

Section: Configuration > Provider Installation > Filesystem Mirrors

2. HashiCorp Terraform Documentation, "CLI Configuration File": This page describes the providerinstallation block, which is the primary mechanism for configuring alternative provider sources. It outlines the filesystemmirror, networkmirror, and direct installation methods.

Source: HashiCorp Terraform Official Documentation.

Section: Configuration > CLI Configuration File > providerinstallation

3. HashiCorp Terraform Documentation, "Provider Sources": This page explains how Terraform determines where to download a provider from, based on its source address. It clarifies that a source address can point to the public registry, a private registry, or a third-party registry.

Source: HashiCorp Terraform Official Documentation.

Section: Configuration > Providers > Provider Sources

The statement incorrectly identifies the trigger for speculative plan runs. In an HCP Terraform or Terraform Cloud workspace linked to a version control system (VCS), speculative plans are automatically initiated when a pull request (or merge request) is opened. They are designed to show the potential outcome of merging the proposed changes. In contrast, committing or merging changes directly to the main tracked branch of the repository triggers a standard plan and potentially an apply, not a speculative plan.

The statement is false because it confuses the trigger for a speculative plan with the trigger for a standard run. A speculative plan is for a proposed change (a pull request), allowing for review before merging. A standard run is for an actual change committed to the tracked branch.

1. HashiCorp Terraform Documentation, "VCS-Driven Runs": In the section "Speculative Plans on Pull Requests," the documentation explicitly states: "When you create a pull request (or merge request) in your connected VCS repository, Terraform Cloud automatically starts a speculative plan in the associated workspace. This helps you verify whether the change will have the intended effect before merging it." This directly contradicts the question's claim that merges or commits trigger speculative plans.

2. HashiCorp Terraform Documentation, "Run Modes and Options": Under the "Speculative Plans" section, the documentation clarifies their purpose: "Speculative plans are plans that Terraform Cloud runs on proposed changes, such as pull requests or merge requests. They let you see the potential effects of a change before you decide whether to merge and apply it." This reinforces that the trigger is a proposed change, not a finalized merge or commit.

3. HashiCorp Terraform Documentation, "VCS-Driven Runs": The section "Standard Runs on Merges" describes the correct behavior for merges: "When you merge a pull request, Terraform Cloud automatically starts a new run in the associated workspace. Depending on the workspace's settings, this can be an apply run or a plan-only run." This clearly distinguishes the standard run triggered by a merge from the speculative plan triggered by opening a pull request.

The statement is false. A Terraform plan file, typically created using terraform plan -out=filename, is a portable artifact. Any user or automated system that has read access to the plan file and possesses the necessary credentials and permissions for the target cloud provider can execute terraform apply using that file. The identity of the user who generated the plan is not a prerequisite for applying it. This separation of planning and applying is a fundamental feature that enables collaborative workflows, such as code review and CI/CD pipelines, where one user or process generates a plan for review, and a different user or automated process applies it after approval.

The statement "True" is incorrect because it wrongly implies an identity-based restriction is built into Terraform's core workflow. The ability to apply a plan is governed by the permissions of the entity executing the terraform apply command, not the identity of the entity that ran terraform plan.

1. HashiCorp Terraform Documentation, "Command: plan": In the section "Saving a Plan", the documentation states, "To save the generated plan to a file, use the -out command line option... This is primarily used when you want to be sure that exactly the planned operations are executed... You can then later execute this plan with terraform apply." This describes the mechanism of creating a portable plan file without mentioning any user-specific restrictions.

2. HashiCorp Terraform Documentation, "Command: apply": In the section "Execution Modes", it details applying a saved plan file: "When you run terraform apply with a saved plan file, Terraform will make exactly the changes specified in the plan, and will not ask for confirmation." This confirms that the apply command's primary input is the plan file itself, not the identity of the user who created it.

3. HashiCorp Terraform Documentation, "Running Terraform in Automation": This guide explicitly outlines a recommended CI/CD workflow that contradicts the statement. It describes a process where "A CI job runs terraform plan and saves the plan file as an artifact. A human operator reviews the plan file and, if acceptable, triggers another CI job. The second job runs terraform apply with the saved plan file to carry out the planned changes." This workflow is fundamentally dependent on the ability of different users or systems to apply a plan generated by another.

The statement is correct. Within a Terraform configuration, the terraform { requiredproviders { ... } } block is the sole location where a provider's global source address (e.g., hashicorp/aws) is mapped to a local name (e.g., aws). Every other part of the configuration, including resource, data, and provider blocks, must use this established local name to refer to the provider. This design decouples the provider's source from its usage within the module, allowing for flexibility and clarity.

The alternative, "False," is incorrect. If this were false, it would imply that other parts of the configuration could or should use the provider's full source address (e.g., resource "hashicorp/awsinstance" "example"). This is not valid Terraform syntax. The Terraform language parser is designed to recognize a resource type as , and it relies on the local name defined in the requiredproviders block to identify which provider a resource belongs to.

1. HashiCorp Terraform Documentation, "Provider Requirements":

Location: Configuration Language -> Providers -> Provider Requirements.

Quote: "The requiredproviders block specifies all of the providers required by the current module, mapping each local provider name to a source address and a version constraint. The local name is used in the rest of the configuration to refer to the provider..." This text explicitly states that the local name is used throughout the rest of the configuration.

URL: https://developer.hashicorp.com/terraform/language/providers/requirements

2. HashiCorp Terraform Documentation, "Providers":

Location: Configuration Language -> Providers.

Quote: "A provider block configures a specified provider, such as aws. A provider is a plugin that Terraform uses to create and manage your resources... To configure a particular provider, you can use a provider block. This block is identified by the local name of the provider it configures." This confirms that the provider configuration block itself is identified by the local name.

URL: https://developer.hashicorp.com/terraform/language/providers/configuration

3. HashiCorp Learn, "Manage Providers" Tutorial:

Location: Terraform -> Tutorials -> Manage Providers.

Quote: "Terraform uses the provider's local name when you reference it in your configuration, for example when you define a resource. In this case, the local name for the hashicorp/random provider is random." This tutorial reinforces the concept by providing a clear example of the mapping between the source (hashicorp/random) and the local name (random) and its subsequent use in resource definitions.

URL: https://developer.hashicorp.com/terraform/tutorials/configuration-language/providers#review-provider-configuration

The statement is false for two primary reasons. First, not all standard backend types support state locking. A notable example is the default local backend, which stores the state file on the local filesystem and does not implement any locking mechanism. Second, remote operations (executing plan, apply, etc., in a remote environment) are a specific feature of certain backends, primarily the remote backend which integrates with Terraform Cloud and Terraform Enterprise. Most other backends, such as s3, azurerm, or gcs, provide remote state storage and locking, but the Terraform operations themselves are still executed on the local machine where the commands are run.

The statement "True" is incorrect because the claim "All standard backend types" is an absolute that is disproven by counterexamples. The local backend does not support locking, and backends like s3 or gcs do not support remote operations; they only provide a remote location for state file storage and a mechanism for locking.

1. HashiCorp Terraform Documentation, "State Locking": This document explicitly states that locking is not a universal feature. "Not all backends support locking. The documentation for each backend includes details about whether it supports locking." This directly refutes the first part of the question.

Source: HashiCorp, Terraform Documentation, Language, State, "State Locking".

Reference: developer.hashicorp.com/terraform/language/state/locking

2. HashiCorp Terraform Documentation, "Backend Type: local": The documentation for the standard local backend makes no mention of locking capabilities, as it is intended for individual use where concurrent operations are not a concern. This serves as a specific example of a standard backend without locking.

Source: HashiCorp, Terraform Documentation, Language, Settings, Backends, "Standard Backends: local".

Reference: developer.hashicorp.com/terraform/language/settings/backends/local

3. HashiCorp Terraform Documentation, "Backend Type: remote": This page details the functionality of the remote backend, which is designed for Terraform Cloud and Enterprise. It describes remote operations as a key feature: "The remote backend can also be configured to execute Terraform operations in a remote environment..." This highlights that remote execution is a specific feature of this backend, not a general feature of all backends.

Source: HashiCorp, Terraform Documentation, Language, Settings, Backends, "Standard Backends: remote".

Reference: developer.hashicorp.com/terraform/language/settings/backends/remote

4. HashiCorp Terraform Documentation, "Backend Type: s3": The documentation for the s3 backend shows that it supports locking via a DynamoDB table, but it does not perform remote operations. The plan and apply commands are executed locally, accessing the state file stored remotely in the S3 bucket. This distinguishes remote state storage from remote operations.

Source: HashiCorp, Terraform Documentation, Language, Settings, Backends, "Standard Backends: s3".

Reference: developer.hashicorp.com/terraform/language/settings/backends/s3 (See section on "State Locking and Consistency").