Free Terraform-Associate-003 Practice Test Questions and Answers (2026)

The statement reverses the correct order of operations. A Terraform backend must first be configured in the Terraform configuration files (e.g., main.tf) within a terraform block. After the configuration is written, the terraform init command is executed to initialize the working directory. During initialization, Terraform reads the backend configuration and prepares to use the specified remote location for state storage.

The statement "True" is incorrect because the terraform init command requires the backend configuration to be present in the code to know which backend to initialize and how to connect to it. Without a configuration, terraform init cannot set up a specific remote backend; it would default to using the local backend.

1. HashiCorp Developer: Terraform Documentation

"Backend Configuration": The documentation explicitly states the required sequence. "To configure a backend

you add a backend block within the top-level terraform block. ... After configuring a backend

you must run terraform init. This command will validate and configure the backend

and in some cases will prompt for migration of existing state." This shows configuration precedes initialization.

Source: HashiCorp

Terraform Language Documentation

"Settings - Backends - Configuration"

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

2. HashiCorp Developer: Terraform Documentation

"Command: init": This page details the actions of the init command. Under the "Backend Initialization" section

it explains: "During init

the root module's backend configuration is consulted. If a backend is configured

Terraform will verify that the configuration is syntactically valid...". This confirms that init consults an existing configuration

meaning the configuration must be defined before initialization can occur.

Source: HashiCorp

Terraform CLI Documentation

"Commands - init"

https://developer.hashicorp.com/terraform/cli/commands/init#backend-initialization

The description argument for input variables and output values is metadata intended for human operators and documentation generation. This information is used by Terraform to provide context in the command-line interface (e.g., when prompting for a variable) and is included in module documentation. However, this descriptive metadata is not stored within the Terraform state file. The state file's primary purpose is to map the configuration to remote resources, track resource attributes, and manage dependencies, not to store the descriptive text from the configuration files.

The statement is incorrect because the state file is a machine-readable mapping of resources, not a repository for the human-readable comments or descriptions present in the .tf configuration files. The absence of this metadata in the state file can be confirmed by inspecting the raw terraform.tfstate JSON file after an apply operation.

1. HashiCorp Terraform Documentation

"Input Variables - The description Argument": This source explains the function of the description argument for variables. It states

"This description is displayed to the user in the CLI when they are prompted for a value

and is also used to generate documentation for a module." It makes no mention of the description being stored in the state file.

Source: HashiCorp

Terraform Language Documentation

"Input Variables"

https://developer.hashicorp.com/terraform/language/values/variables#the-description-argument.

2. HashiCorp Terraform Documentation

"Output Values - The description Argument": This document details the description argument for outputs

noting its purpose for human readability. It states

"This description is included in the output of terraform output and can be used to generate documentation for a module." This confirms its role is for user-facing information

not for state management.

Source: HashiCorp

Terraform Language Documentation

"Output Values"

https://developer.hashicorp.com/terraform/language/values/outputs#the-description-argument.

3. HashiCorp Terraform Documentation

"Purpose of Terraform State": This page describes the contents and purpose of the state file. It specifies that state is used for "Mapping to the Real World

" "Metadata

" and "Performance." The metadata mentioned refers to resource dependencies and provider configurations

not descriptive text from variables or outputs. The document states the state file stores "bindings between objects in a remote system and the resource instances declared in your configuration."

Source: HashiCorp

Terraform Language Documentation

"State"

https://developer.hashicorp.com/terraform/language/state#purpose-of-terraform-state.

The sensitive = true argument on an output value primarily affects how Terraform displays that value in the command-line interface. When an output is marked as sensitive, its value is redacted from the output of terraform apply and terraform plan. However, the actual value is still recorded in the Terraform state file. This is necessary because other Terraform configurations may need to read this value using the terraformremotestate data source. Therefore, the state file itself must be treated as a sensitive artifact and secured accordingly.

The statement "True" is incorrect because it misrepresents the function of the sensitive argument. The argument's purpose is to prevent accidental exposure in logs and CLI output, not to prevent the value from being stored. The state file must contain the complete state of the managed infrastructure, including the values of all outputs, to function correctly.

1. HashiCorp Terraform Documentation

"Output Values"

section "Sensitive Outputs". This section explicitly states: "An output can be marked as containing sensitive material using the optional sensitive argument... Terraform will still record sensitive values in the state

and so anyone who can access the state data will have access to the sensitive values. For more information

see Sensitive Data in State."

2. HashiCorp Terraform Documentation

"Sensitive Data in State". This page elaborates on the concept: "Terraform state can contain sensitive data... When you use a resource

any arguments or attributes for that resource are stored in plain-text in the state file... The values of output values are also stored in plain-text in the state file." This confirms that output values

regardless of the sensitive flag

are stored in the state.

The statement is correct. Terraform is designed with a plugin-based architecture, where providers are the primary type of plugin. A provider is responsible for understanding API interactions and exposing resources for a specific service (e.g., a cloud platform, a SaaS provider, or an in-house system). Users can develop their own custom providers using the Terraform Plugin Framework, typically in the Go programming language, to extend Terraform's management capabilities to any platform that exposes a CRUD (Create, Read, Update, Delete) API.

The alternative, "False," is incorrect because it contradicts a core design principle of Terraform. Terraform is not a closed system with a fixed set of supported services. Its extensibility through custom providers is a fundamental feature that allows the community and vendors to add support for new and niche services, making it a versatile infrastructure as code tool.

1. HashiCorp Developer Documentation

"Terraform Plugins: Providers". This document explicitly states

"Providers are the primary vehicle for Terraform to support new infrastructure and services... If you want to manage a component or system that is not currently supported by an existing provider

you can write your own."

Source: HashiCorp

Terraform Documentation.

Reference: https://developer.hashicorp.com/terraform/plugin/providers (Introduction section).

2. HashiCorp Developer Documentation

"What are Terraform Providers?". This foundational document explains the role of providers as plugins that enable Terraform to interact with various services. It states

"Each provider adds a set of resource types and/or data sources that Terraform can manage." This implies that new providers can be added to manage new sets of resources.

Source: HashiCorp

Terraform Documentation.

Reference: https://developer.hashicorp.com/terraform/language/providers (Introduction section).

3. HashiCorp Developer Tutorial

"Call APIs with Custom Providers". This official tutorial provides a step-by-step guide on how to build a custom Terraform provider from scratch to manage resources from a custom API. This serves as a practical confirmation that developing custom providers is a supported and documented process.

Source: HashiCorp

Terraform Tutorials.

Reference: https://developer.hashicorp.com/terraform/tutorials/providers/provider-call-apis (Overview section).

The statement is false because a single remote backend configuration block in Terraform does not always map to a single remote workspace. While it is possible to create a one-to-one mapping using the workspaces.name attribute, the remote backend also supports the workspaces.prefix attribute. When prefix is used, the single backend configuration can map to multiple remote workspaces that share the specified prefix. The user can then switch between these workspaces using the terraform workspace select command.

The statement "True" is incorrect because it makes an absolute claim ("always") that is invalidated by the existence and functionality of the workspaces.prefix attribute in the remote backend configuration. This feature explicitly allows a single configuration to be associated with a group of workspaces, not just one.

1. HashiCorp Terraform Documentation

"Backend Configuration - remote": In the "Configuration Variables" section for the remote backend

the documentation describes the workspaces block. It states: "A workspaces block can be specified to override the default workspace selection behavior. A workspaces block can contain either a name or a prefix attribute." It further clarifies that prefix allows the configuration to be used with any workspace name that has the given prefix. This directly contradicts the idea of a permanent one-to-one mapping.

2. HashiCorp Terraform Documentation

"Workspaces": In the section on "Remote Workspaces"

the documentation explains how a configuration's backend block connects it to a workspace in Terraform Cloud. It notes

"When using a remote backend

the Terraform CLI maps each workspace to a corresponding workspace in the remote system." The mechanism for this mapping

as detailed in the backend configuration

includes the flexible prefix option

allowing one configuration to map to many potential workspaces.

The statement is false because the word "always" is an absolute. While the default behavior of terraform init is to download providers from the public Terraform Registry over the Internet, Terraform explicitly supports several alternative installation methods that do not require an Internet connection. These methods are designed for use cases such as air-gapped environments or organizations that wish to use a curated set of private providers. Terraform can be configured to install providers from a local filesystem mirror, a network mirror on a private network, or an implied local mirror directory where pre-downloaded provider plugins are stored.

The "True" option is incorrect. It oversimplifies the provider installation process by ignoring the documented, officially supported mechanisms for offline and private provider distribution. The existence of alternatives like filesystem mirrors and the user plugins directory directly refutes the claim that providers are always installed from the Internet.

1. HashiCorp Terraform Documentation

"Provider Installation"

Section: "Filesystem Mirrors": This section explicitly describes how to configure Terraform to use a local directory as a source for providers

which is a common practice in environments without internet access. It states

"A filesystem mirror is a directory on the local filesystem which is laid out in the same way as a network mirror... This can be useful for air-gapped environments

or for forcing the use of a particular set of provider versions that have been approved by a local security policy." This directly contradicts the premise that providers are always installed from the Internet.

2. HashiCorp Terraform Documentation

"Provider Installation"

Section: "Implied Local Mirror Directories": This section details how Terraform automatically searches for provider plugins in specific local directories (e.g.

~/.terraform.d/plugins on Unix-like systems). This allows for manual

offline placement of provider binaries. The documentation notes

"Terraform will search these directories for provider plugins before consulting the configured installation methods." This is another official

non-Internet-based installation method.

3. HashiCorp Terraform Documentation

"CLI Configuration File"

Section: "Provider Installation": This document outlines the providerinstallation block

which can be used in a CLI configuration file to override the default installation behavior. It provides the syntax for configuring filesystemmirror and networkmirror methods

giving users explicit control to source providers from locations other than the public internet registry. The presence of these configuration options confirms that internet-based installation is not the only method.

The public Terraform Module Registry is a free service provided by HashiCorp that allows any user to publish and share Terraform modules. The primary prerequisite for publishing is that the user must have a GitHub account, as the registry uses GitHub as the source for modules. The module itself must be hosted in a public GitHub repository and adhere to specific, documented requirements regarding naming conventions, repository structure, and version tagging. There are no fees or special approval processes required for a user to be eligible to publish; the process is open to anyone who can meet these technical requirements.

The statement "False" is incorrect because it would imply the existence of significant barriers to publishing, such as requiring a paid enterprise account, being a verified HashiCorp partner, or undergoing a manual vetting process for every user. The public registry is designed to be an open, community-driven platform, and the process is automated for any user who connects their GitHub account and has a properly formatted module repository.

1. HashiCorp Terraform Documentation

"Publishing Modules to the Public Registry": This official guide outlines the requirements and steps for publishing. It explicitly states the process begins by signing in with a GitHub account and that the module must be in a public GitHub repository. The "Requirements" section details the technical prerequisites

which are open for any user to fulfill.

Source: HashiCorp

Terraform Documentation.

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

Details: The document states

"The public Terraform Registry is the main source for publicly available Terraform modules... To publish a module to the public registry

you will need to meet the following requirements: 1. GitHub: The module must be on GitHub and in a public repo... 2. Naming convention: The repository must use this name format: terraform--... 3. Repository description:... 4. Standard module structure:... 5. x.y.z release tags: Your repository must have x.y.z release tags..."

2. HashiCorp Terraform Documentation

"Publishing a Module" (Step-by-step guide): This section details the user workflow

which confirms that any user can initiate the process.

Source: HashiCorp

Terraform Documentation.

Section: "Modules > Publishing to the Registry > Publishing Modules to the Public Registry > Publishing a Module".

Details: The first step listed is: "Sign in to the Terraform Registry with your GitHub account." This is followed by selecting a repository and clicking "Publish Module

" demonstrating an open

self-service process not restricted to a specific class of users.

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 public Terraform Module Registry, available at registry.terraform.io, is a free service provided by HashiCorp. It serves as a central repository for the community to discover, use, and publish Terraform modules. There are no fees associated with browsing, downloading, or publishing modules to this public registry. While HashiCorp offers paid tiers in Terraform Cloud and Terraform Enterprise that include a private module registry for proprietary modules, the public registry remains a core, free component of the Terraform ecosystem.

The statement 'False' is incorrect because it would wrongly imply that there is a cost to use the public Terraform Module Registry. This service is provided at no charge to foster community collaboration and module reuse.

1. HashiCorp Terraform Documentation

"Terraform Registry": The documentation introduces the public Terraform Registry as the primary place for users to find and use modules written by the community. The entire section on publishing and using public modules details the process without any mention of associated costs.

Source: HashiCorp

"Terraform Registry

" Terraform Documentation. Accessed at: https://developer.hashicorp.com/terraform/language/registry

2. HashiCorp Terraform Cloud

"Pricing": The official pricing page for Terraform Cloud explicitly lists "Access to the public module registry" as a feature included in the "Free" tier. This directly confirms that access and use of the public registry are free. Paid tiers are distinguished by the inclusion of a "Private module registry."

Source: HashiCorp

"Terraform Pricing

" Terraform Cloud Documentation. Accessed at: https://www.hashicorp.com/products/terraform/pricing (Refer to the feature comparison table under the "Free" tier).

3. HashiCorp Terraform Documentation

"Publishing Modules to the Public Registry": This guide details the technical requirements for publishing a module

such as using a public Git repository and following naming conventions. It notably omits any mention of fees or payment

reinforcing that publishing is a free process.

Source: HashiCorp

"Publishing Modules to the Public Registry

" Terraform Documentation. Accessed at: https://developer.hashicorp.com/terraform/registry/modules/publish

The terraform state rm command is used exclusively to remove a resource from the Terraform state file. This action does not destroy the actual infrastructure object in the remote system (e.g., an EC2 instance on AWS). Instead, it "orphans" the resource, meaning Terraform will no longer manage its lifecycle. The real-world resource will continue to exist until it is removed manually or managed by another tool. The command to destroy infrastructure managed by Terraform is terraform destroy.

The statement is "False". The alternative, "True", is incorrect because it confuses state manipulation with resource lifecycle management. The terraform state family of commands is designed for advanced operations on the state file itself, not for altering the real-world infrastructure that the state file represents. The command that performs the destruction of infrastructure is terraform destroy.

1. HashiCorp Terraform Documentation

"Command: state rm":

Location: https://developer.hashicorp.com/terraform/cli/commands/state/rm

Quote/Paraphrase: The documentation explicitly states

"This command removes items from the state file

but does not destroy the objects in the remote system." This directly refutes the claim made in the question. It further clarifies that the command is used to "unmanage" a resource from Terraform's perspective.

HCP Terraform and Terraform Cloud are designed to solve the challenges of using Terraform in a team environment. Two of its core, foundational features are remote state storage and a web-based user interface (UI). Remote state storage provides a centralized, secure backend to store the Terraform state file, enabling collaboration, locking to prevent concurrent runs, and versioning. The web-based UI provides a central dashboard for managing workspaces, securely storing variables, reviewing infrastructure plans, approving applies, and viewing run histories, which simplifies the entire infrastructure lifecycle management process for teams.

A. Automatic backups of configuration and state.

While HCP Terraform versions state files, which acts as a form of backup, this is a sub-feature of remote state management, not a distinct primary feature like remote state itself.

C. Automated infrastructure deployment visualization.

HCP Terraform provides detailed logs and a UI for the deployment process (plan/apply), but it does not natively generate a graphical visualization or architectural diagram of the deployed infrastructure.

1. HashiCorp Developer Documentation

"About Terraform Cloud": This document outlines the key features of Terraform Cloud. It explicitly lists "Remote state management and locking" as a primary feature. The entire platform is described as "a central place to manage infrastructure

" which is facilitated by the web UI.

Source: HashiCorp

"About Terraform Cloud"

Terraform Documentation. Section: "Key Features".

2. HashiCorp Developer Documentation

"State in Terraform Cloud": This page details how state is managed. It states

"Terraform Cloud manages state for you. It stores the state in the service

and protects it with access controls." This directly supports the "Remote state storage" feature.

Source: HashiCorp

"State in Terraform Cloud"

Terraform Documentation. Section: "How Terraform Cloud Manages State".

3. HashiCorp Developer Documentation

"The UI-driven Run Workflow": This page describes one of the primary workflows

which is entirely based on interacting with the web interface. It states

"The most basic workflow for Terraform Cloud is the UI/VCS-driven workflow

which is a great starting point for many teams." This confirms the web-based UI as a central feature.

Source: HashiCorp

"The UI-driven Run Workflow"

Terraform Documentation. Introduction paragraph.

A Terraform provider is a plugin responsible for understanding the API of a specific service (e.g., AWS, Azure, GCP) and managing resources within that service. Its core functions include exposing resources, understanding API interactions, and executing create, read, update, and delete (CRUD) actions.

The responsibility for orchestrating and provisioning infrastructure across multiple clouds or services lies with Terraform Core, not any single provider. Terraform Core reads the configuration, builds the dependency graph, and then instructs the appropriate provider for each resource, allowing users to manage a multi-cloud environment within a single configuration.

A. This is a primary responsibility. Providers translate a service's API into a set of declared resources and data sources for use in Terraform configurations.

B. This is a core function. When Terraform detects a difference, it instructs the provider to execute the necessary create, update, or delete operations on the resource.

C. This is the fundamental purpose of a provider. It acts as a client for a target API, abstracting the complexities of authentication, requests, and responses.

1. HashiCorp Terraform Documentation

"Providers": "Providers are plugins that Terraform uses to manage resources. Each provider is responsible for understanding API interactions and exposing resources. For example

the AWS provider knows how to interact with the AWS APIs to create and manage resources on AWS." This supports that A

B

and C are provider responsibilities.

2. HashiCorp Terraform Documentation

"Core Concepts": "You can use multiple providers in your Terraform configuration to manage resources from different infrastructure platforms. Terraform Core is responsible for managing the lifecycle of these resources

while the providers are responsible for the specific details of how to create and manage them." This clarifies the distinction between Terraform Core's role (managing multiple platforms) and a provider's role (managing a specific platform).

3. HashiCorp Learn

"What are Providers?": "Terraform relies on providers to interact with cloud providers

SaaS providers

and other APIs... Providers are distributed separately from Terraform itself

and each provider has its own release cycle and versioning." This highlights the modular

single-purpose nature of a provider

contrasting with the multi-service orchestration role of Terraform Core.

The terraform taint command is used to manually mark a Terraform-managed resource as "tainted." A tainted resource will be planned for destruction and recreation on the next terraform apply. This forces a replacement of the resource instance without requiring any changes to the configuration code. By targeting only the virtual machine resource with the taint command, you ensure that the database resource remains unaffected during the subsequent apply operation, precisely matching the user's requirement to replace only the VM.

A. terraform state rm only removes the resource from the state file, orphaning the actual cloud resource. It does not trigger a replacement.

C. terraform apply -target is used to focus an apply operation on a subset of resources, but it will not replace a resource unless its configuration has changed.

D. This manual, two-step process (remove/apply, then add/apply) is inefficient, error-prone, and not the intended workflow for replacing a resource.

1. HashiCorp Terraform Documentation

taint Command: "The terraform taint command manually marks a Terraform-managed resource as tainted

forcing it to be destroyed and recreated on the next apply." This documentation confirms that taint is the specific command for forcing replacement.

Source: HashiCorp

Terraform CLI Documentation

Command: taint. (Note: The page mentions the command is deprecated in favor of terraform apply -replace

but its function is as described and it remains a valid concept for the exam).

2. HashiCorp Terraform Documentation

state rm Command: "This command removes the resource from the state

but does not destroy the actual infrastructure object... This is a destructive operation." This clarifies that state rm is for state file manipulation

not for replacing infrastructure.

Source: HashiCorp

Terraform CLI Documentation

Command: state rm.

3. HashiCorp Terraform Documentation

Resource Targeting: "Use of -target is not recommended for routine operations... it can cause undetected configuration drift... The -target option is provided for exceptional circumstances". This explains that targeting is not for standard operations like resource replacement.

Source: HashiCorp

Terraform CLI Documentation

Command: plan

Resource Targeting (-target option).

A child module is an encapsulated and reusable component. It cannot directly access variables, local values, or data sources from its parent module's scope. For a child module to use a value from its parent, the parent module must explicitly pass that value to an input variable defined within the child module. This design principle ensures that modules are self-contained and predictable, preventing them from being implicitly affected by the environment in which they are called.

A. True: This is incorrect. It violates Terraform's fundamental principle of module encapsulation. Direct access is not permitted; variables must be explicitly passed as arguments.

1. HashiCorp Terraform Documentation. (n.d.). Module Composition. In Terraform Language. Retrieved from https://developer.hashicorp.com/terraform/language/modules/compose. The section "Child Module Encapsulation" explicitly states: "A child module can't access the variables of a parent module

but a parent module can pass values to the input variables of a child module."

2. HashiCorp Terraform Documentation. (n.d.). Calling a Child Module. In Terraform Language. Retrieved from https://developer.hashicorp.com/terraform/language/modules/syntax#calling-a-child-module. This section demonstrates that values are passed to a module as arguments within the module block

reinforcing the concept of explicit passing rather than direct access.

3. HashiCorp Terraform Documentation. (n.d.). Input Variables. In Terraform Language. Retrieved from https://developer.hashicorp.com/terraform/language/values/variables. The documentation describes input variables as the formal parameters for a module

which is the mechanism for passing data into it.

Infrastructure as Code (IaC) treats infrastructure definitions as software code. This approach allows configurations to be stored in version control systems (like Git), enabling tracking of changes, collaboration among team members through sharing, and the creation of reusable modules. This directly corresponds to the advantage of versioning, reusing, and sharing configurations.

Furthermore, by codifying and automating the provisioning process, IaC significantly reduces the risk of human error inherent in manual GUI-based operations. Automated workflows ensure that infrastructure is deployed consistently and repeatably every time, eliminating mistakes like misconfigurations or forgotten steps that can occur during manual setup.

B. Provisions the same resources at a lower cost

IaC does not change the pricing of the underlying cloud resources. The cost is determined by the cloud provider, not the method used for provisioning.

C. Secures your credentials

While IaC tools provide mechanisms for handling credentials, they do not inherently secure them more than a GUI. Secure credential management is a separate operational responsibility.

E. Prevents manual modifications to your resources

IaC does not prevent out-of-band or manual changes (known as "drift"). It provides tools like terraform plan to detect such changes, but it is not a preventative control.

1. HashiCorp Learn. (n.d.). Introduction to Infrastructure as Code with Terraform. HashiCorp. Retrieved from https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code.

In the section "What is infrastructure as code?"

the text states: "IaC allows you to build

change

and manage your infrastructure in a safe

consistent

and repeatable way by defining resource configurations that you can version

reuse

and share." (Supports A)

In the section "Benefits of Infrastructure as Code"

a key benefit listed is to "Reduce human error and increase automation." (Supports D)

2. HashiCorp Terraform Documentation. (n.d.). What is Terraform?. HashiCorp. Retrieved from https://developer.hashicorp.com/terraform/intro.

Under the "Manage any infrastructure" section

it highlights that Terraform helps "manage infrastructure throughout its lifecycle

" which includes using terraform plan to see changes before applying them. This process helps catch errors

thus "reducing the risk of operator error." (Supports D)

The introduction emphasizes that configuration files "describe to Terraform the components needed to run a single application or your entire datacenter

" which can be versioned and shared. (Supports A)

In a CI/CD environment, sensitive data such as API keys, passwords, or certificates should never be stored in version control. The safest method among the choices is to inject these variables at runtime. The -var command-line flag allows you to pass a variable value directly to the terraform apply or terraform plan command. In a CI/CD pipeline, the value for this flag would be sourced from a secure secret store (e.g., HashiCorp Vault, AWS Secrets Manager, or the CI/CD platform's native secret management) and passed to the Terraform process, ensuring the secret is never hardcoded in the configuration files.

A. Copy the sensitive variables into your Terraform code

This is highly insecure as it hardcodes secrets into version-controlled files, exposing them to anyone with repository access.

B. Store the sensitive variables in a securevarS.tf file

A filename does not confer security. If this file is committed to the repository, it is just as insecure as hardcoding variables elsewhere.

C. Store the sensitive variables as plain text in a source code repository

This is a major security anti-pattern and directly contradicts the goal of handling sensitive variables safely.

1. HashiCorp Terraform Documentation

"Input Variables - Assigning Values to Root Module Variables": This page details the various methods for setting input variables. It lists command-line flags as a primary method: "To specify individual variables on the command line

use the -var option." This establishes -var as a standard mechanism for runtime injection.

Source: HashiCorp

"Input Variables"

Terraform Documentation

https://developer.hashicorp.com/terraform/language/values/variables#assigning-values-to-root-module-variables

Section: "On the Command Line".

2. HashiCorp Terraform Documentation

"Running Terraform in Automation": This guide provides best practices for using Terraform in CI/CD. It explicitly warns against storing secrets in version control and recommends injecting them at runtime. While it prefers environment variables (TFVAR...)

it acknowledges command-line flags as a valid method.

Source: HashiCorp

"Running Terraform in Automation"

Terraform Documentation

https://developer.hashicorp.com/terraform/cli/run/automation

Section: "Variable and Credential Management". The document states

"Do not save plain-text credentials in your VCS... You can set input variables from a file (-var-file) or the command line (-var)..." This directly contrasts the insecure methods (A

B

C) with the secure runtime injection method (D).

Provider credentials supplied via environment variables are read directly by the provider plugin at runtime. These credentials are not part of the Terraform configuration arguments that are evaluated and tracked by Terraform core. As a result, Terraform does not record these credentials in the state file. This method is a recommended best practice for handling sensitive data, as it decouples authentication secrets from both the version-controlled configuration and the state file, enhancing security.

B. Specifying the login credentials in the provider block: This method hardcodes secrets directly into the configuration. These values are then stored in plain text within the Terraform state file, which is a significant security risk.

C. Setting credentials as Terraform variables: Even when a variable is marked as sensitive, Terraform still records its actual value in the state file. The sensitive flag only redacts the value from CLI output.

D. None of the above: This is incorrect because using environment variables (Option A) is a valid and recommended method that prevents provider credentials from being stored in the state file.

---

1. HashiCorp Terraform Documentation

"Sensitive Input Variables": This document explicitly states

"Terraform will still record the value in the state file

and so anyone who can access the state data will have access to the sensitive values in cleartext." This directly refutes the effectiveness of option C for preventing storage in the state file. (Source: HashiCorp

Terraform Documentation

docs/language/values/variables.md

Section: "Sensitive Input Variables").

2. HashiCorp Terraform Documentation

"Provider Configuration": This page recommends against hardcoding credentials (Option B) and suggests environment variables as a preferred alternative. It states

"Hard-coding credentials into any Terraform configuration is not recommended... we recommend using environment variables where possible for the provider's credentials." This separation is key to why the credentials don't end up in the state. (Source: HashiCorp

Terraform Documentation

docs/language/providers/configuration.md

Section: "Provider Configuration").

3. HashiCorp Terraform Documentation

AWS Provider

"Authentication and Configuration": The documentation for specific providers

such as AWS

details the credential lookup order. Environment variables are a standard method where the provider's underlying SDK (e.g.

AWS SDK) reads the credentials from the environment. This process happens within the provider

outside of the configuration values that Terraform itself persists to the state file. (Source: HashiCorp

Terraform Registry

providers/hashicorp/aws/latest/docs

Section: "Authentication and Configuration").

The terraform console command provides an interactive command-line interface for evaluating and experimenting with Terraform expressions. It loads the configuration from the current directory, allowing you to test interpolations, function calls, and variable values in real-time without modifying your state or running a full plan/apply cycle. This makes it the ideal tool for exploring the behavior of Terraform's language features and functions.

Terraform validate checks the syntax and internal consistency of configuration files but does not provide an interactive environment for evaluating expressions.

Terraform env is a command used to manage different named CLI configurations, such as workspaces or credentials, not for expression experimentation.

Terraform test is used to execute structured integration tests against real infrastructure, which is different from interactively experimenting with individual expressions.

---

1. HashiCorp. (n.d.). Command: console. Terraform CLI Documentation. Retrieved from https://developer.hashicorp.com/terraform/cli/commands/console.

Reference Point: The first sentence of the documentation states

"The terraform console command provides an interactive console for evaluating and experimenting with expressions."

2. HashiCorp. (n.d.). Command: validate. Terraform CLI Documentation. Retrieved from https://developer.hashicorp.com/terraform/cli/commands/validate.

Reference Point: The documentation states

"The terraform validate command runs checks that verify whether a configuration is syntactically valid and internally consistent..."

3. HashiCorp. (n.d.). Command: test. Terraform CLI Documentation. Retrieved from https://developer.hashicorp.com/terraform/cli/commands/test.

Reference Point: The documentation specifies

"The terraform test command executes integration tests for the modules and root configuration in the current working directory."

4. HashiCorp. (n.d.). Command: env. Terraform CLI Documentation. Retrieved from https://developer.hashicorp.com/terraform/cli/commands/env.

Reference Point: The documentation explains

"The terraform env command is used to manage different named Terraform CLI configurations on your local machine."

Terraform does not have a native data type or input mechanism called "secure string." While other systems like AWS Systems Manager Parameter Store use this terminology, it is not a feature within the Terraform language (HCL) for defining or passing variables. Terraform can mark variables as sensitive to redact their values from CLI output, but the underlying type remains a standard string. The other options represent valid, documented methods for providing sensitive data to a Terraform configuration without hardcoding it.

A. A Terraform provider: Providers like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault are specifically designed to fetch secrets dynamically at runtime using data sources, which is a recommended practice.

B. Environment variables: Terraform automatically reads environment variables prefixed with TFVAR to populate input variables, providing a common method for injecting secrets from a CI/CD system.

C. A -var flag: The -var 'foo=bar' command-line flag is a direct way to pass variable values, including secrets, during plan or apply operations, keeping them out of the configuration files.

1. HashiCorp Terraform Documentation

"Input Variables": This document details the primary ways to assign values to variables. It explicitly lists command-line flags (-var and -var-file) and Environment Variables (TFVAR...) as valid methods. It does not mention a "secure string" mechanism.

Source: HashiCorp

Terraform Language Documentation

"Assigning Values to Root Module Variables".

URL: https://developer.hashicorp.com/terraform/language/values/variables#assigning-values-to-root-module-variables

2. HashiCorp Terraform Documentation

"Sensitive Values": This page explains the sensitive argument for variables and outputs. It clarifies that this is a boolean flag (sensitive = true) applied to a variable to suppress its value in UI output

not a distinct data type.

Source: HashiCorp

Terraform Language Documentation

"Suppressing Values in CLI Output".

URL: https://developer.hashicorp.com/terraform/language/values/variables#suppressing-values-in-cli-output

3. HashiCorp Vault Provider Documentation: This official provider documentation demonstrates the use of data sources (e.g.

data "vaultgenericsecret" "...") to retrieve secrets from an external system (Vault)

confirming that providers are a valid method for secret management.

Source: HashiCorp

Terraform Registry

"Vault Provider - vault\generic\secret Data Source".

URL: https://registry.terraform.io/providers/hashicorp/vault/latest/docs/data-sources/genericsecret

The Terraform state file stores the attributes of all managed resources. When outputs are not defined, the most direct way to inspect these attributes is by using the terraform state subcommands. The terraform state list command will display the addresses of all resources in the current state. Once the specific resource address is identified, terraform state show can be used to print all of its attributes, including the public IP address, directly from the state file. This is a non-destructive, read-only operation designed for state inspection.

A. Using terraformremotestate requires writing a new configuration, which is not a quick method for simply viewing an attribute of an existing resource.

C. The terraform output command only works if an output block has been explicitly defined in the configuration, which the scenario states was not done.

D. This is a destructive and slow process. It would destroy the existing resource and create a new one, which would have a different public IP address.

1. HashiCorp Terraform Documentation

state list command: "The terraform state list command is used to list resources within a Terraform state." This supports the first step of identifying the resource.

Source: HashiCorp

Terraform CLI Documentation

Command: state list.

2. HashiCorp Terraform Documentation

state show command: "The terraform state show command is used to show the attributes of a single resource in the Terraform state... This command can be useful for inspecting the current state of a resource." This confirms it is the correct tool for viewing the resource's attributes like an IP address.

Source: HashiCorp

Terraform CLI Documentation

Command: state show.

3. HashiCorp Terraform Documentation

Output Values: "The terraform output command is used to extract the value of an output variable from the state file." This implies an output must first be defined in the configuration.

Source: HashiCorp

Terraform Language Documentation

Configuration Language

Output Values.

4. HashiCorp Terraform Documentation

terraformremotestate Data Source: "The terraformremotestate data source allows you to use the root-level outputs of another Terraform configuration as input data." This shows its purpose is for sharing data between configurations

not simple inspection.

Source: HashiCorp

Terraform Language Documentation

Data Sources

terraformremotestate.