Terraform-Associate-003 HashiCorp Certified: Terraform Associate (003) (HCTA0-003) Questions and Answers

Terraforminstalls providers during the terraform init phase.

Providers aredownloaded and installedwhen running terraform init.

A (terraform plan)is incorrect because terraform plan only calculates changes but does not install providers.

C (terraform refresh)is incorrect because terraform refresh only updates the state but does not install providers.

Official Terraform Documentation Reference:

Provider Installation - HashiCorp Documentation

You do not need to use different Terraform commands depending on the cloud provider you use. Terraform commands are consistent across different providers, as they operate on the Terraform configuration files and state files, not on the provider APIs directly.

The default “local” Terraform backend stores the state file in a local file named terraform.tfstate, which can be used to track and manage the state of your infrastructure3.

Terraform workspaces allow you to create multiple states but still be associated with your current code. Workspaces are like “environments” (e.g. staging, production) for the same configuration. You can use workspaces to spin up a copy of your production deployment for testing purposes without having to configure a new state backend. Terraform data sources, local values, and modules are not features that allow you to create multiple states. References = Workspaces and How to Use Terraform Workspaces

Sensitive values such as API tokens should be stored in a secure way, either in Terraform Cloud variables marked as sensitive or in HashiCorp Vault. Storing secrets in version control systems or plaintext files is not recommended.

Detailed Explanation:

Rationale for Correct Answer (C):Credentials should not be hardcoded in Terraform files. Best practice is to configure them via environment variables or secret managers.

Analysis of Incorrect Options:

A: Shared servers introduce risk and drift.

B: Storing secrets in config/version control is insecure.

D: Incorrect since option C is valid.

Key Concept:Separation of credentials from code is a Terraform security best practice.

This is what will happen if you run terraform apply in the working directory again, after removing the resource definition from your Terraform configuration file. Terraform will detect that there is a resource in the state file that is not present in the configuration file, and will assume that you want to delete it.

The public Terraform Module Registry is free to use, as it is a public service that hosts thousands of self-contained packages called modules that are used to provision infrastructure. You can browse, use, and publish modules to the registry without any cost.

Setting the TF_LOG environment variable to DEBUG causes debug messages to be logged into stdout, along with other log levels such as TRACE, INFO, WARN, and ERROR. This can be useful for troubleshooting or debugging purposes.

Module variable assignments are not inherited from the parent module and you need to explicitly set them using the source argument. This allows you to customize the behavior of each module instance.

Dynamic blocks in Terraform allow you to define multiple nested blocks within a resource based on the values of a variable. This feature is particularly useful for scenarios where the number of nested blocks is not fixed and can change based on variable input.

You do not need to use different Terraform commands depending on the cloud provider you use. Terraform commands are consistent across different providers, as they operate on the Terraform configuration files and state files, not on the provider APIs directly.

From Terraform CLI Overview:

"Terraform provides a consistent CLI workflow regardless of which cloud or service you’re managing."

Thesame Terraform commandswork across all providers via plugins.

This is a secure way to inject sensitive variables into your Terraform run, as they will not be stored in any file or source code repository. You can also use environment variables or variable files with encryption to pass sensitive variables to Terraform.

 This is the command that you would use to access all of the attributes and details of a resource managed by Terraform, by providing the resource address as an argument. For example, terraform state show 'aws_instance.example' will show you all the information about the AWS instance named example.

It lets you version, reuse, and share infrastructure configuration as code files, which can be stored in a source control system and integrated with your CI/CD pipeline.

It reduces risk of operator error by automating repetitive tasks and ensuring consistency across environments. IaC does not necessarily provision resources at a lower cost, secure your credentials, or prevent manual modifications to your resources - these depend on other factors such as your cloud provider, your security practices, and your access policies.

Terraform providers are not part of the Terraform core binary. Providers are distributed separately from Terraform itself and have their own release cadence and version numbers. Providers are plugins that Terraform uses to interact with various APIs, such as cloud providers, SaaS providers, and other services. You can find and install providers from the Terraform Registry, which hosts providers for most major infrastructure platforms. You can also load providers from a local mirror or cache, or develop your own custom providers. To use a provider in your Terraform configuration, you need to declare it in the provider requirements block and optionally configure its settings in the provider block. References = : Providers - Configuration Language | Terraform : Terraform Registry - Providers Overview | Terraform

HashiCorp Configuration Language (HCL) does not support user-defined functions. You can only use the built-in functions that are provided by the language. The built-in functions allow you to perform various operations and transformations on values within expressions. The general syntax for function calls is a function name followed by comma-separated arguments in parentheses, such as max(5, 12, 9). You can find the documentation for all of the available built-in functions in the Terraform Registry orthe Packer Documentation, depending on which tool you are using. References = : Functions - Configuration Language | Terraform : Functions - Configuration Language | Packer

The public Terraform Module Registry automatically exposes all the information about published modules, including required input variables, optional input variables and default values, and outputs. This helps users to understand how to use and configure the modules.

The execution plan for terraform apply will not be the same as the one you ran locally with terraform plan, if your teammate manually modified the infrastructure component you are working on. This is because Terraform will refresh the state file before applying any changes, and will detect any differences between the state and the real resources.

According to theofficial Terraform documentationhere:

????Terraform Docs – Declaring an Output Value

In Terraform 0.12 and later, you can directly use expressions in outputs without interpolation syntax:

output "instance_ip_addr" {

value = aws_instance.server.private_ip

}

This aligns perfectly withOption A:

output "instance_ip_addr" {

value = aws_instance.main.private_ip

}

Why not the others?

❌Option B: Incorrect syntax. "${main.private_ip}" is referencing main as if it were a global variable or resource, but it isn’t defined. Plus, the output name is oddly written as aws_instance.instance_ip_addr, which is not a valid identifier format.

❌Option C: Although valid in older versions (<= 0.11), interpolation with "${}" isdeprecatedin Terraform 0.12+. The docs clearly advise using direct expressions instead.

❌Option D: Terraform hasno return statement; this is syntactically invalid in Terraform’s HCL.

The terraform apply command changes both the cloud infrastructure and the state file after you approve the execution plan. The command creates, updates, or destroys the infrastructure resources to match theconfiguration. It also updates the state file to reflect the new state of the infrastructure. The .terraform directory, the execution plan, and the Terraform code are not changed by the terraform apply command. References = Command: apply and Purpose of Terraform State

Terraform detects infrastructure drift by comparing thestate filewith the actual infrastructure.

When an instance ismanually deleted, Terraformsees it as missingand marks it for recreation.

Running terraform apply willonly recreate the missing instanceswhile leaving the rest of the infrastructure unchanged.

Explanation of incorrect answers:

A (Tear down everything and rebuild)– Incorrect. Terraform does not destroy existing infrastructure unless explicitly told to.

B (Build a completely new set of infrastructure)– Incorrect. Terraform does not create duplicates unless configuration changes.

D (Stop and error out)– Incorrect. Terraform does not fail; itrebuilds missing resourcesautomatically.

Official Terraform Documentation Reference:

Handling Infrastructure Drift

Running terraform fmt without any flags in a directory with Terraform configuration files will not check the formatting of those files without changing their contents, but will actually rewrite them to a canonical format and style. If you want to check the formatting without making changes, you need to use the -check flag.

Sentinel is a policy-as-code framework that integrates with Terraform Cloud to enforce security, compliance, and governance rules. You can enforce rules such as approved AMIs and ensure security best practices. Policies are written in the Sentinel language, not HCL.

The terraform state file is locked when a Terraform operation that could write state is in progress. This prevents concurrent state operations that could corrupt the state. The forbidden actions when the state file is locked are those that could write state, such as terraform apply, terraform destroy, terraform refresh, terraform taint, terraform untaint, terraform import, and terraform state *. The terraform validate command is also forbidden, because it requires an initialized working directory with the state file. The allowed actions when the state file is locked are those that only read state, such as terraform plan, terraform show, terraform output, and terraform console. References = [State Locking] and [Command: validate]

 Terraform configuration (including any module references) can contain more than one Terraform provider type. Terraform providers are plugins that Terraform uses to interact with various cloud services and other APIs. A Terraform configuration can use multiple providers to manage resources across different platforms and services. For example, a configuration can use the AWS provider to create a virtual machine, the Cloudflare provider to manage DNS records, and the GitHub provider to create a repository. Terraform supports hundreds of providers for different use cases and scenarios. References = [Providers], [Provider Requirements], [Provider Configuration]

To prevent two Terraform runs from changing the same state file simultaneously, state locking is used. State locking ensures that when one Terraform operation is running, others will be blocked from making changes to the same state, thus preventing conflicts and data corruption. This is achieved by configuring the state backend to support locking, which will lock the state for all operations that could write to the state.References = This information is supported by Terraform's official documentation, which explains the importance of state locking and how it can be configured for different backends to prevent concurrent state modifications .

This is how Terraform chooses which version of the provider to use, when you add a new resource to an existing Terraform configuration, but do not update the version constraint in the configuration. The lock file records the exact version of each provider that was installed in your working directory, and ensures that Terraform will always use the same provider versions until you run terraform init -upgrade to update them.

Changes invoked by terraform apply take effect once the resource provider has fulfilled the request, not after Terraform has updated the state file or immediately. The state file is only a reflection of the real resources, not a source of truth.

The terraform init command is used to initialize a working directory containing Terraform configuration files. This command performs several different initialization steps to prepare the current working directory for use with Terraform, which includes initializing the backend, installing provider plugins, and copying any modules referenced in the configuration. However, it does not validate whether all required variables are present; that is a task performed by terraform plan or terraform apply1.

References = This information can be verified from the official Terraform documentation on the terraform init command provided by HashiCorp Developer1.

Inrefresh-only mode(terraform apply -refresh-only), Terraformupdates the state fileto match the actual infrastructurewithout modifying resources.

A (Terraform configuration)–Not modifiedin refresh-only mode.

B (Terraform plan)–Plan is generated but not modified.

D (Cloud infrastructure)–Not modifiedin refresh-only mode.

Official Terraform Documentation Reference:

Refresh-Only Mode

The .terraform.lock.hcl file is a new feature in Terraform 0.14 that records the exact versions of each provider used in your configuration. This helps ensure consistent and reproducible behavior across different machines and runs.

The Terraform binary version and provider versions do not have to match each other in a single configuration. Terraform allows you to specify provider version constraints in the configuration’s terraform block, which can be different from the Terraform binary version1. Terraform will use the newest version of the provider that meets the configuration’s version constraints2. You can also use the dependency lock file to ensure Terraform is using the correct provider version3. References =

•1: Providers - Configuration Language | Terraform | HashiCorp Developer

•2: Multiple provider versions with Terraform - Stack Overflow

•3: Lock and upgrade provider versions | Terraform - HashiCorp Developer

In Terraform, theresource nameis the second argument in the resource block.

The structure of a resource block is:

resource "provider_resource_type" "resource_name" {

# Configuration settings

}

Here, the provider type isgoogle_compute_instance, and theresource nameis "main".

The name "test" is simply the value assigned to the name attribute, which is unrelated to the Terraform resource name.

"google" and "compute_instance" are part of the provider and resource type, not the resource name.

Official Terraform Documentation Reference:

Terraform Resource Documentation

This is one disadvantage of using dynamic blocks in Terraform, as they can introduce complexity and reduce readability of the configuration. The other options are either advantages or incorrect statements.

None of the above methods prevent credentials from being stored in the state file. Terraform stores the provider configuration in the state file, which may include sensitive information such as credentials. This is a potential security risk and should be avoided if possible. To prevent credentials from being stored in the state file, you can use one of the following methods:

Use environment variables to pass credentials to the provider. This way, the credentials are not part of the provider configuration and are not stored in the state file. However, this method may not work for some providers that require credentials to be set in the provider block.

Use dynamic credentials to authenticate with your cloud provider. This way, Terraform Cloud or Enterprise will request temporary credentials from your cloud provider for each run and use them to provision your resources. The credentials are not stored in the state file and are revoked after the run is completed. This method is supported for AWS, Google Cloud Platform, Azure, and Vault. References = : [Sensitive Values in State] : Authenticate providers with dynamic credentials

terraform state listonly displays resources stored in the state filebut doesnot interact with the cloud provideror refresh the state.

terraform plan, terraform apply, and terraform destroycompare or modify the infrastructure, so theyrefresh the stateto ensure accuracy.

Official Terraform Documentation Reference:

terraform state list - HashiCorp Documentation

This is a bad practice, as it exposes your credentials to anyone who can access your configuration files or state files. You should use environment variables, credential files, or other mechanisms to provide credentials to Terraform.

If you update the version constraint in your Terraform configuration, Terraform will update your lock file the next time you run terraform init3. This will ensure that you use the same provider versions across different machines and runs.

State locking prevents other users from modifying the state file while a Terraform operation is in progress. This prevents conflicts and data loss1.

Importing Existing Resources: Theterraform importcommand brings resources already deployed in a cloud environment into Terraform’s state file, allowing Terraform to manage them.

Workflow Usage: Importing is vital when managing resources created outside of Terraform or those in place before Terraform adoption.

Refer to Terraform’s import command documentation.

The two steps that are required to provision new infrastructure in the Terraform workflow are init and apply. The terraform init command initializes a working directory containing Terraform configuration files. It downloads and installs the provider plugins that are needed for the configuration, and prepares the backend for storing the state. The terraform apply command applies the changes required to reach the desired state of the configuration, as described by the resource definitions in the configuration files. It shows a plan of the proposed changes and asks for confirmation before making any changes to the infrastructure. References = [The Core Terraform Workflow], [Initialize a Terraform working directory with init], [Apply Terraform Configuration with apply]

Terraform follows adeclarativeapproach, meaning it ensures the infrastructure matches the configuration.

If you run terraform apply againwithout any changes, Terraform willdetect that the infrastructure is already up to dateand willdo nothing.

The command will complete successfully with the message"No changes. Your infrastructure matches the configuration."

Official Terraform Documentation Reference:

Terraform Apply - HashiCorp Documentation

The statement that you must use the CLI to switch between workspaces is false. Terraform Cloud workspaces are different from Terraform CLI workspaces. Terraform Cloud workspaces are required and represent all of the collections of infrastructure in an organization. They are also a major component of role-based access in Terraform Cloud. You can grant individual users and user groupspermissions for one or more workspaces that dictate whether they can manage variables, perform runs, etc. You can create, view, and switch between Terraform Cloud workspaces using the Terraform Cloud UI, the Workspaces API, or the Terraform Enterprise Provider5. Terraform CLI workspaces are optional and allow you to create multiple distinct instances of a single configuration within one working directory. They are useful for creating disposable environments for testing or experimenting without affecting your main or production environment. You can create, view, and switch between Terraform CLI workspaces using the terraform workspace command6. The other statements about Terraform Cloud workspaces are true. They have role-based access controls that allow you to assign permissions to users and teams based on their roles and responsibilities. You can create and manage roles using the Teams API or the Terraform Enterprise Provider7. Plans and applies can be triggered via version control system integrations that allow you to link your Terraform Cloud workspaces to your VCS repositories. You can configure VCS settings, webhooks, and branch tracking to automate your Terraform Cloud workflow8. They can securely store cloud credentials as sensitive variables that are encrypted at rest and only decrypted when needed. You can manage variables using the Terraform Cloud UI, the Variables API, or the Terraform Enterprise Provider9. References = [Workspaces]5, [Terraform CLI Workspaces]6, [Teams and Organizations]7, [VCS Integration]8, [Variables]9

The key principle of infrastructure as code that is not listed among the options is golden images. Golden images are pre-configured, ready-to-use virtual machine images that contain a specific set of software and configuration. They are often used to create multiple identical instances of the same environment, such as for testing or production. However, golden images are not a principle of infrastructure as code, but rather a technique that can be used with or without infrastructure as code. The other options are all key principles of infrastructure as code, as explained below:

Self-describing infrastructure: This means that the infrastructure is defined in code that describes its desired state, rather than in scripts that describe the steps to create it. This makes the infrastructure easier to understand, maintain, and reproduce.

Idempotence: This means that applying the same infrastructure code multiple times will always result in the same state, regardless of the initial state. This makes the infrastructure consistent and predictable, and avoids errors or conflicts caused by repeated actions.

Versioned infrastructure: This means that the infrastructure code is stored in a version control system, such as Git, that tracks the changes and history of the code. This makes the infrastructure code reusable, auditable, and collaborative, and enables practices such as branching, merging, and rollback. References = [Introduction to Infrastructure as Code with Terraform], [Infrastructure as Code in a Private or Public Cloud]

Terraform variable names are not saved in the state file, only their values are. The state file only stores the attributes of the resources and data sources that are managed by Terraform, not the variables that are used to configure them.

terraform init is the first command that should be run after writing a new Terraform configuration or cloning an existing one from version control. It initializes a working directory containing Terraform configuration files and downloads any required providers and modules. The other commands are used for different purposes, such as importing existing resources, switching between workspaces, generating execution plans, etc.

B (terraform init)–Must be run firstto initialize the Terraform working directory, download providers, and configure the backend.

A (terraform apply)– Requires initialization first, so itcannotbe run before terraform init.

C (terraform plan)– Also requires terraform init first to generate a plan.

D (terraform show)– Displays the state,not relevantfor first-time deployment.

Official Terraform Documentation Reference:

terraform init - HashiCorp Documentation

When the state file is locked, operations that modify or depend on the state (liketerraform apply,terraform destroy, andterraform state list) are blocked.terraform fmtonly formats the configuration files and does not interact with the state, so it is allowed.

Terraform state files are not automatically encrypted by default. Sensitive values are stored in plaintext within the state file. However, you can protect the state file by using remote backends that support encryption, such as AWS S3 with server-side encryption enabled or Terraform Cloud, which offers encrypted state storage.

This is where Terraform cannot load a provider from, as it requires a compiled binary file that implements the provider protocol. You can load a provider from a plugins directory, a provider plugin cache, or the official HashiCorp distribution on releases.hashicorp.com.

This is a key benefit of the Terraform state file, as it stores and tracks the metadata and attributes of the resources that are managed by Terraform, and allows Terraform to compare the current state with the desired state expressed by your configuration files.

Detailed Explanation:

Rationale for Correct Answer:While HashiCorp publishes and maintains some official modules, many modules on the Terraform Registry are community-maintained. HashiCorp does not test or maintain all published modules. The Registry clearly distinguishes between official, partner, and community modules.

Analysis of Incorrect Options (Distractors):

A. True: Incorrect because not all Registry modules are maintained or tested by HashiCorp.

Key Concept:Understanding the difference between official, partner, and community modules in the Terraform Registry.

These are two ways to produce a list of the IDs from a list of objects that have an attribute id, using either a for expression or a splat expression syntax.

C (✅Correct)– If changes require aresource replacement(e.g., changing an immutable attribute like instance type), Terraform willdestroy and recreate the resource.

E (✅Correct)– Terraform only appliesthe configuration in the current directory or workspace.

This command will check if all code in a Terraform configuration that references multiple modules is properly formatted without making changes, and will return a non-zero exit code if any files need formatting. The other commands will either make changes, list the files that need formatting, or not check the modules.

The purpose of state in Terraform is to keep track of the real-world resources managed by Terraform, mapping them to the configuration. The state file contains metadata about these resources, such as resource IDs and other important attributes, which Terraform uses to plan and manage infrastructure changes. The state enables Terraform to know what resources are managed by which configurations and helps in maintaining the desired state of the infrastructure.References = This role of state in Terraform is outlined in Terraform's official documentation, emphasizing its function in mapping configuration to real-world resources and storing vital metadata .

This is a secure way to protect sensitive data in the state file, as it will be encrypted at rest and in transit2. The other options are not recommended, as they could lead to data loss, errors, or security breaches.

You can configure a backend in your Terraform code before initializing it. Initializing a backend will store the state file remotely and enable features like locking and workspaces. References = [Terraform Backends]

This is what state locking accomplishes, by preventing other users from modifying the state file while a Terraform operation is in progress. This prevents conflicts and data loss.

Detailed Explanation:

Rationale for Correct Answers:

C. terraform.tfvars securely managed: Acceptable if distributed securely outside version control.

D. HCP Terraform/Terraform Cloud sensitive variables: Official best practice for team-based workflows.

E. Vault: HashiCorp Vault is designed for secret management and integrates well with Terraform.

Analysis of Incorrect Options:

A: Storing plaintext secrets on shared drives is insecure.

B: Checking secrets into version control is a major security risk.

Key Concept:Sensitive values should be managed securely in Vault, HCP Terraform, or securely shared .tfvars files — never in plaintext or version control.

Terraform providers are not always installed from the Internet. There are other ways to install provider plugins, such as from a local mirror or cache, from a local filesystem directory, or from a network filesystem. These methods can be useful for offline or air-gapped environments, or for customizing the installation process. You can configure the provider installation methods using the provider_installation block in the CLI configuration file.

Detailed Explanation:

Rationale for Correct Answer (B):Provider version constraints in Terraform are specified using the version argument in the required_providers block, e.g.:

terraform {

required_providers {

aws = {

source = "hashicorp/aws"

version = "3.1"

}

}

}

This ensures Terraform always uses a specific provider version (or constraint expression).

Analysis of Incorrect Options:

A. version: Incomplete, no value specified.

C. version: 3.1: Incorrect syntax, Terraform uses = not :.

D. version - 3.1: Incorrect syntax, - is invalid here.

Key Concept:Defining provider version constraints ensures consistent provider behavior across environments and avoids breaking changes.

Terraform modules are referenced by specifying a source location. This location can be a URL or a file path. However, specifying query parameters such as ?version=vl.6.0 directly within the source path is not a valid or supported method for specifying a module version in Terraform. Instead, version constraints are specified using the version argument within the module block, not as part of the source string.References = This clarification is based on Terraform's official documentation regarding module usage, which outlines the correct methods for specifying module sources and versions.

This is the meta-argument that you must include in any non-default provider configurations, as it allows you to give a friendly name to the configuration and reference it in other parts of your code. The other options are either invalid or irrelevant for this purpose.

Child modulesdo not automatically inheritvariables from the parent module.

To pass values from theparent moduleto thechild module, you mustexplicitly define input variablesin the child module and pass them in the parent module.

Example:

hcl

CopyEdit

module "example" {

source = "./child_module"

var1 = "value"

}

Official Terraform Documentation Reference:

Passing Variables to Modules

In Terraform Cloud, you can switch between workspaces using both the web UI and CLI. The statement that you "must use the CLI" is false. Workspaces can securely store cloud credentials, offer role-based access control, and integrate with VCS to trigger plan and apply operations.

From the Terraform Output Docs – Sensitive:

"Marking an output as sensitive prevents Terraform from showing its value in the CLI output,but it will still bestored in the state file."

Thus, it protects display, not storage.

The terraform state list command lists all resources that are managed by Terraform in the current state file1. The terraform state show command shows the attributes of a single resource in the state file2. By using these two commands, you can compare the VM IDs in your list with the ones in the state file and identify which one is managed by Terraform.

The terraform import command is not part of any other Terraform workflow. It must be explicitly invoked by the user with the appropriate arguments, such as the resource address and the ID of the existing infrastructure to import. References = [Importing Infrastructure]

All of the statements are true of Terraform providers. Terraform providers are plugins that enable Terraform to interact with various APIs and services1. Anyone can write a Terraform provider, either as an individual or as part of a community2. HashiCorp maintains some providers, such as the AWS, Azure, and Google Cloud providers3. Cloud providers and infrastructure vendors can also write, maintain, or collaborate on Terraform providers, such as the VMware, Oracle, and Alibaba Cloud providers. References =

•1: Providers - Configuration Language | Terraform | HashiCorp Developer

•2: Plugin Development - How Terraform Works With Plugins | Terraform | HashiCorp Developer

•3: Terraform Registry

•: Terraform Registry

You should run terraform fmt to rewrite all Terraform configurations within the current working directory to conform to Terraform-style conventions. This command applies a subset of the Terraform language style conventions, along with other minor adjustments for readability. It is recommended to use this command to ensure consistency of style across different Terraform codebases. The command is optional, opinionated, and has no customization options, but it can help you and your team understand the code more quickly and easily. References = : Command: fmt : Using Terraform fmt Command to Format Your Terraform Code