TERRAFORM-ASSOCIATE-003 Practice Questions

The .terraform.lock.hcl file records the specific versions of providers that Terraform has selected to use for a configuration. The terraform init command is responsible for initializing a working directory, which includes downloading and installing the necessary providers based on the version constraints defined in the configuration files. When terraform init is executed, it compares the version constraints in the configuration with the versions recorded in the lock file. If the constraints have been updated in a way that the locked version no longer satisfies them, Terraform will find the newest available provider version that meets the new constraint, download it, and update the .terraform.lock.hcl file to record the newly selected version and its checksum.

The "False" option is incorrect because it contradicts the fundamental dependency management workflow of Terraform. The primary mechanism for updating provider dependencies and the corresponding lock file is the terraform init command. If init did not update the lock file after a constraint change, the lock file would become outdated and no longer reflect the actual dependencies required by the configuration, defeating its purpose of ensuring consistent and repeatable builds.

1. HashiCorp Terraform Documentation

"Dependency Lock File (.terraform.lock.hcl)": In the section "Managing Selections in the Lock File

" the documentation explicitly states: "If you change the version constraints for a provider in your configuration

the next time you run terraform init Terraform will select the newest-available provider version that meets the new constraint and update the lock file accordingly."

2. HashiCorp Terraform Documentation

"Command: init": Under the "Provider Installation" section

it describes the role of terraform init in downloading and installing providers. It notes

"If a lock file is present (.terraform.lock.hcl)

terraform init will also check that the installed provider versions are consistent with the checksums recorded in the lock file..." This implies that init is the command that manages the relationship between the configuration

the installed providers

and the lock file.

3. HashiCorp Terraform Documentation

"Provider Requirements": This page details how to declare provider version constraints within the requiredproviders block. It establishes that these constraints are the source of truth that terraform init uses to select an appropriate provider version

which is then recorded in the lock file.

The Terraform state file does not store the names of the input variables defined in your configuration (.tf files). Instead, it stores the values that are assigned to resource attributes, which may have originated from variables. The state file's primary purpose is to map the configured resources to real-world objects and to cache the attribute values of those resources. The configuration logic, including variable names, resides solely in the .tf configuration files.

The statement is False. The state file is a record of the state of your infrastructure, not a copy of the code used to create it. For example, if you have a variable var.instancesize with a value of "t2.micro" and use it to set an EC2 instance's instancetype, the state file will record "instancetype": "t2.micro", but it will not contain any reference to the variable name instancesize.

1. HashiCorp Developer Documentation

"Purpose of Terraform State": This document explains that the state file is used for "Mapping to Real World"

"Metadata"

and "Performance". It emphasizes that the state stores "attribute values for all resources

" which are the resolved values

not the variable names from the configuration. The document makes no mention of storing variable names.

Source: HashiCorp

"Purpose of Terraform State"

https://developer.hashicorp.com/terraform/language/state/purpose

2. HashiCorp Developer Documentation

"State File Format": This technical reference details the JSON structure of the state file. The schema includes objects for resources and their instances

which contain an attributes map. This map holds the key-value pairs of the resource's arguments and their final

computed values. The schema does not include any fields for storing the names of the input variables used to derive these values.

Source: HashiCorp

"State File Format"

https://developer.hashicorp.com/terraform/language/state/format

The statement is false. By default, when you run terraform apply without a pre-saved plan file, it first runs its own planning phase. This phase includes a "refresh" step where Terraform queries the cloud provider APIs to get the current, real-world state of the infrastructure. In this scenario, the refresh step will detect the manual changes made by the teammate. Consequently, the execution plan generated by terraform apply will be different from the one generated by the earlier terraform plan command, as it will account for this newly discovered "drift" between the state file and the actual infrastructure.

The "True" option is incorrect because it presumes that the initial terraform plan output is static and will be used by a subsequent terraform apply. This ignores Terraform's core mechanism for ensuring consistency: refreshing the state from the remote environment before proposing and executing changes. This refresh is crucial for preventing unintended consequences from out-of-band modifications.

1. HashiCorp Terraform Documentation

"Command: apply": "By default

apply will also run terraform plan to generate a plan before prompting for approval. This is a convenience feature

and it is recommended to run terraform plan directly and save the plan to a file to be sure that you are applying the changes you expect." This confirms that apply runs its own plan

which includes a refresh.

Source: HashiCorp Developer

developer.hashicorp.com/terraform/cli/commands/apply. Accessed on the current date.

2. HashiCorp Terraform Documentation

"Command: plan": "As part of creating a plan

Terraform reads the current state of any already-existing remote objects to make sure that the Terraform state is up-to-date. This is what we refer to as a "refresh" of the state." This explains that the planning process

whether invoked by plan or apply

inherently involves a refresh against the real infrastructure.

Source: HashiCorp Developer

developer.hashicorp.com/terraform/cli/commands/plan. Accessed on the current date.

3. HashiCorp Terraform Documentation

"State: Resource Drift": "When the real-world resource differs from Terraform's state file

this is called "drift". [...] When you run terraform plan or terraform apply

Terraform will read the current attributes of the existing resource and update the state file. This detects the drift and may plan to update the resource to match the configuration." This directly addresses the scenario in the question

defining drift and explaining how plan and apply detect and handle it.

Source: HashiCorp Developer

developer.hashicorp.com/terraform/language/state#resource-drift. Accessed on the current date.

The core Terraform Command Line Interface (CLI) commands and workflow are designed to be provider-agnostic. The standard commands—terraform init, terraform plan, terraform apply, and terraform destroy—remain the same regardless of which cloud provider (e.g., AWS, Azure, Google Cloud) you are targeting. The differentiation between providers is handled within the Terraform configuration files (.tf) through the declaration of a specific provider block and the use of provider-specific resource types (e.g., awsinstance vs. azurermvirtualmachine).

The "True" option is incorrect because it fundamentally misunderstands one of Terraform's key value propositions: providing a consistent, unified workflow to manage infrastructure across any platform. If the commands changed for each provider, this would eliminate the benefit of a common interface and add unnecessary complexity.

1. HashiCorp Developer - Core Terraform Workflow: The official documentation outlines a standard

three-stage workflow (Write

Plan

Apply) that is universal. It states

"This core workflow is the same for any project." The commands associated with this workflow (terraform init

terraform plan

terraform apply) are presented as the consistent method for managing any infrastructure.

Source: HashiCorp Developer

"Core Terraform Workflow"

https://developer.hashicorp.com/terraform/intro/core-workflow

Introduction section.

2. HashiCorp Developer - Providers: This documentation explains that providers are plugins Terraform uses to interact with cloud providers and other APIs. It clarifies that providers are specified within the configuration code itself using a provider block. This confirms that the provider-specific logic is handled within the configuration

not by altering the CLI commands used to execute the workflow.

Source: HashiCorp Developer

"Providers"

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

"Provider Requirements" section.

3. HashiCorp Developer - Command: apply: The documentation for the terraform apply command describes its function in a generic

provider-agnostic way: "The terraform apply command executes the actions proposed in a Terraform plan." There is no mention of provider-specific variations of the command itself. This holds true for all other core workflow commands.

Source: HashiCorp Developer

"Command: apply"

https://developer.hashicorp.com/terraform/cli/commands/apply

Usage section.

A provider configuration block is only required if the Terraform configuration declares resources or data sources that rely on that specific provider. A Terraform configuration can be syntactically valid and functional without any provider blocks if it does not manage any external resources. For example, a configuration that only uses output blocks to display static values or locals to perform transformations does not require a provider block to initialize or apply.

The statement "True" is incorrect because it presents the provider block as a mandatory, universal requirement for all Terraform configurations. The need for a provider block is conditional upon the use of resources or data sources associated with that provider. A minimal configuration file containing only an output block is a valid counterexample.

1. HashiCorp Terraform Documentation

"Providers - Configuration": The documentation states

"The provider block configures the specified provider

such as AWS

Google Cloud

or another cloud or service provider." This describes the purpose of the block

which is to configure a provider when it is being used

implying it is not needed if no provider-specific resources are being managed.

Source: HashiCorp

"Provider Configuration

" Terraform Language Documentation. Retrieved from https://developer.hashicorp.com/terraform/language/providers/configuration

2. HashiCorp Terraform Documentation

"Configuration Language - Overview": This page describes the various top-level blocks available in the Terraform language

such as terraform

provider

resource

variable

and output. It does not specify that a provider block is a mandatory component for a configuration file to be considered valid. The validity depends on the contents and their interdependencies.

Source: HashiCorp

"The Terraform Language

" Terraform Language Documentation. Retrieved from https://developer.hashicorp.com/terraform/language

3. HashiCorp Terraform Documentation

"Core Terraform Workflow - Write Configuration": The tutorials often begin with a provider configuration because the goal is to create a resource. However

the fundamental requirement is tied to resource management. The documentation notes

"The set of resources supported by Terraform is determined by the providers you use." This directly links the necessity of a provider to the management of resources.

Source: HashiCorp

"Write Configuration

" Core Terraform Workflow Documentation. Retrieved from https://developer.hashicorp.com/terraform/intro/core-workflow#write

The terraform init command is used to initialize a working directory that already contains Terraform configuration files (such as main.tf). Its primary purpose is to prepare the directory for other commands by performing three main actions: initializing the backend, downloading required provider plugins, and installing any referenced modules. The command reads existing configuration files to determine which providers and modules are needed; it does not create any example or boilerplate configuration files itself.

The statement is false because the creation of configuration files like main.tf is a prerequisite step that the user must perform before running terraform init. The command's role is to set up the environment based on pre-existing configuration, not to generate that configuration.

1. HashiCorp Terraform Documentation

"Command: init". The official documentation states

"The terraform init command initializes a working directory containing Terraform configuration files." The page details the command's actions as Backend Initialization

Child Module Installation

and Plugin Installation

none of which involve the creation of a main.tf file. The command's premise is that configuration files already exist.

Source: HashiCorp

Terraform CLI Documentation

"Command: init"

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

2. HashiCorp Learn

"Get Started - Provision Infrastructure". In the official introductory tutorials

the workflow clearly separates file creation from initialization. In the "Write Configuration" step

the user is explicitly instructed to create a main.tf file. Only in the subsequent step

"Initialize the directory

" is the user directed to run terraform init. This procedural separation confirms that init does not create the file but rather acts upon it.

Source: HashiCorp Learn

Get Started with Terraform

"Provision Infrastructure"

https://developer.hashicorp.com/terraform/tutorials/aws-get-started/aws-build

The terraform validate command is used to check whether a set of configuration files are syntactically valid and internally consistent. It performs a static analysis of the .tf files in the current directory to catch syntax errors, incorrect argument types, and other code-level issues. It does not access any remote services, provider APIs, or the Terraform state file, and therefore cannot confirm if the deployed infrastructure matches the state.

The statement is false because it incorrectly describes the function of terraform validate. The command that compares the current configuration against the existing infrastructure (as recorded in the state file) to determine what changes are needed is terraform plan. A terraform plan that results in no proposed changes indicates that the deployed infrastructure matches the configuration.

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 require access to both the configuration and the state

and reports inconsistencies." This source explicitly states that validate does not access remote state or infrastructure.

2. HashiCorp Terraform Documentation

"The Core Terraform Workflow": In the "Write" and "Validate" step

the documentation describes terraform validate as a command to "check your configuration for syntax errors and other issues." In the subsequent "Plan" step

it describes terraform plan as the command to "preview the changes Terraform will make to match your configuration." This clearly separates the roles of the two commands.

3. HashiCorp Learn

"Validate Terraform Configuration": This tutorial states

"The terraform validate command validates the syntax of your Terraform code. It is a good practice to run this command before you run terraform plan or terraform apply to get fast feedback on any syntax errors in your configuration." This reinforces that its purpose is a pre-check on the code itself

not a comparison with live infrastructure.

The official Terraform Module Registry hosts modules from three distinct tiers: Community, Partner, and Verified. The "Community" tier consists of modules published by any member of the Terraform community, and these modules do not undergo a formal verification process by HashiCorp. The "Verified" status is a specific badge awarded to a subset of modules, primarily from official HashiCorp partners, that meet a higher standard of quality, maintenance, and testing. Therefore, the statement that all modules are verified is incorrect.

The "True" option is incorrect because it makes an absolute claim that is factually wrong. The existence of the "Community" module tier, which allows for the publication of modules without HashiCorp's formal review or verification, directly contradicts the assertion that "all" modules are verified.

1. HashiCorp Terraform Documentation

"Module Tiers": This document explicitly defines the different tiers of modules available in the registry. It states

"The Terraform Registry has three tiers of modules: Community

Partner

and Verified." It describes Community modules as being published by members of the Terraform community

distinguishing them from the reviewed Partner and Verified modules.

Source: HashiCorp

Terraform Documentation.

Section: Registry > Publishing Modules > Module Tiers.

URL: https://developer.hashicorp.com/terraform/registry/modules/tiers

2. HashiCorp Terraform Documentation

"Publishing Modules to the Registry": This guide details the requirements for publishing modules. It outlines a simple process for community modules that relies on a correctly formatted source code repository (e.g.

on GitHub) and does not mention a mandatory verification step by HashiCorp for this tier.

Source: HashiCorp

Terraform Documentation.

Section: Registry > Publishing Modules > Publishing Modules to the Registry.

URL: https://developer.hashicorp.com/terraform/registry/modules/publish

The statement is false because Terraform's primary mechanism for managing dependencies is implicit. Terraform automatically builds a dependency graph by parsing the configuration and analyzing the references between resources. For example, if a virtual machine resource configuration references the ID of a virtual network, Terraform understands that the virtual machine depends on the virtual network and will create the network first. The dependson meta-argument is an override mechanism used only to create explicit dependencies for cases where a dependency is not visible to Terraform through direct resource references.

The statement "True" is incorrect because it completely ignores Terraform's core feature of implicit dependency resolution. Relying solely on dependson for all dependencies would be cumbersome and is contrary to Terraform's design, which aims to automate as much of the dependency management as possible.

1. HashiCorp Terraform Documentation

"Resource Dependencies": "When one resource refers to another

it creates an implicit dependency. Terraform uses this dependency information to determine the correct order in which to create the different resources... The dependson argument is accepted by any resource or module block and accepts a list of references to other resources or modules in the same calling module. This creates an explicit dependency."

2. HashiCorp Terraform Documentation

"The dependson Meta-Argument": "Use the dependson meta-argument to handle hidden resource or module dependencies that Terraform cannot automatically infer. You only need to explicitly specify a dependency when a resource relies on some other resource's behavior but does not access any of that resource's data in its arguments."

3. HashiCorp Learn

"Manage Resource Dependencies": "Terraform analyzes your configuration to automatically find dependencies between your resources. This creates an implicit ordering for resource creation and destruction... For dependencies that Terraform cannot infer

you can use the dependson meta-argument to create an explicit dependency."

Setting the TFLOG environment variable to DEBUG does enable detailed logging for Terraform's core and providers. However, by default, this log output is sent to the stderr (standard error) stream, not the stdout (standard output) stream. This separation ensures that diagnostic and debug information does not interfere with the primary, often machine-readable, output of commands like terraform plan or terraform show, which are directed to stdout.

The statement "True" is incorrect because it misidentifies the standard stream used for logging. Terraform explicitly directs log output to stderr to keep it separate from the command's primary result on stdout.

1. HashiCorp Terraform Documentation

"Debugging Terraform": "To enable logging

set the TFLOG environment variable to one of the log levels (TRACE

DEBUG

INFO

WARN

ERROR) to display logs. ... By default

the log is sent to stderr."

Source: HashiCorp

Terraform CLI Documentation

"Debugging Terraform". Retrieved from https://developer.hashicorp.com/terraform/cli/commands/debug

2. HashiCorp Terraform Documentation

"Environment Variables": Under the TFLOG section

the documentation confirms the behavior: "By default

the log is sent to stderr. To send the log to a file

set the TFLOGPATH environment variable."

Source: HashiCorp

Terraform CLI Documentation

"Environment Variables". Retrieved from https://developer.hashicorp.com/terraform/cli/config/environment-variables#tflog