HashiCorp Terraform Associate Practice Test Questions, Exam Dumps

Practice Exams:

View All

Terraform Associate HashiCorp Practice Test Questions and Exam Dumps

Question No 1:

The terraform.tfstate file always matches your currently built infrastructure.

A. True
B. False

Correct Answer: B

Explanation:

The statement that the terraform.tfstate file always matches the currently built infrastructure is false. While Terraform uses the terraform.tfstate file to track the state of the infrastructure, it does not always guarantee a perfect match between the state file and the actual infrastructure. The state file represents the last known state of the infrastructure as managed by Terraform, but there are situations where discrepancies can occur, leading to an out-of-sync state. Below are some key reasons why the terraform.tfstate file might not match the current infrastructure:

Manual Changes to Infrastructure: If someone manually alters the infrastructure outside of Terraform (such as through the AWS console, Azure portal, or any other cloud provider's interface), Terraform will not be aware of these changes. When you run terraform plan, Terraform will attempt to reconcile the state file with the actual infrastructure, potentially reporting differences that exist between the state file and the live environment.
State File Corruption or Loss: If the state file is lost or becomes corrupted, Terraform may not be able to accurately track the current infrastructure. While it can create a new state file, it may have mismatches with the actual infrastructure, requiring you to manually import resources back into the state.
State File Updates Delayed: Terraform updates the state file only after applying changes. If there is an issue during an apply operation (such as network failure or an interrupted operation), the state file might not reflect the most recent changes to the infrastructure, leading to potential discrepancies.
Remote State Management: In the case of using remote state (e.g., stored in an S3 bucket, Terraform Cloud, etc.), there can be delays or sync issues when accessing the most up-to-date state, leading to temporary mismatches. While remote state allows multiple users to collaborate on the same infrastructure, it is still prone to discrepancies if not properly managed.
Partial Resource Updates: Sometimes, a Terraform plan may be applied partially or incorrectly due to resource dependencies or errors. In such cases, the state file may be updated even though some parts of the infrastructure weren't actually changed, leading to discrepancies.

Therefore, it’s essential to be aware that while Terraform strives to maintain the state accurately, there are scenarios where the state file may not fully reflect the real infrastructure, especially in dynamic or manually modified environments. To avoid issues, it’s always recommended to manage infrastructure using Terraform exclusively or to synchronize any manual changes with Terraform.

Question No 2:

Does one remote backend configuration always correspond to a single remote workspace?

A. True
B. False

Correct Answer: B

Explanation:

In Terraform, a remote backend is a configuration that defines where and how the state of your infrastructure is stored, typically in a remote location like AWS S3, Azure Storage, or HashiCorp's Terraform Cloud. The backend manages the state file and can support features like state locking, versioning, and remote execution.

A workspace in Terraform, on the other hand, is a logical container used to manage multiple environments (e.g., development, staging, production) within the same configuration. While workspaces and backends are related, they are not tied in a one-to-one relationship.

Clarifying the relationship between backends and workspaces:

A backend configuration in Terraform specifies how and where the state is stored but does not inherently define the number of workspaces. The configuration for the backend can be used to support multiple workspaces, which is particularly useful in scenarios where the same backend (for example, an S3 bucket) is used for different environments, each having a different workspace.
Multiple workspaces can be used within a single backend to allow for the isolation of state for different purposes (such as different environments or teams) while still utilizing the same backend storage.

For example, if you're using Terraform Cloud, you can create multiple workspaces within the same Terraform Cloud organization, but each workspace can correspond to a different environment (development, staging, production) while sharing the same remote backend configuration.

Why is the answer B (False)?

The statement in the question that "one remote backend configuration always maps to a single remote workspace" is incorrect because a single backend can be used by multiple workspaces. The backend configuration specifies where the state will be stored (for example, an S3 bucket), but you can create multiple workspaces that use the same backend. Each workspace will have its own isolated state within the backend.

Thus, the correct answer is B, as a remote backend does not always map to just one workspace but can support multiple workspaces.

Question No 3:

How does the Terraform remote backend differ from other state backends like S3, Consul, etc.?

A. It can execute Terraform runs on dedicated infrastructure on premises or in Terraform Cloud
B. It doesn't show the output of a terraform apply locally
C. It is only available to paying customers
D. All of the above

Correct Answer: A

Explanation:

In Terraform, state backends are used to store the state of your infrastructure. This state is critical because it allows Terraform to keep track of the infrastructure it manages, ensuring that future changes are made only to the necessary resources. There are different types of state backends, such as local backends (where the state is stored on a local file), remote backends (such as S3, Consul, or Terraform Cloud), and others. These remote backends allow users to store their Terraform state in a centralized location, providing benefits such as collaboration, security, and state versioning.

To understand the difference between a Terraform remote backend and other state backends, it’s essential to look at how each one operates, particularly the Terraform Cloud backend.

The remote backend in Terraform, particularly with Terraform Cloud, offers capabilities that go beyond the simple storage of state. The significant distinction lies in running Terraform plans and applies on remote infrastructure, which is a feature unique to Terraform Cloud. This capability allows teams to leverage dedicated infrastructure for managing their Terraform operations, whether that’s on premises or within the cloud environment. This infrastructure is provided and managed by Terraform Cloud, making it an attractive option for teams who need collaborative infrastructure management with additional security and ease of use.

Here’s why A is correct:

A. It can execute Terraform runs on dedicated infrastructure on premises or in Terraform Cloud is correct because Terraform Cloud is designed to run Terraform operations in a secure and dedicated environment, without requiring the user to manage their own infrastructure. It offers additional features such as workspaces, collaboration tools, version control integration, and remote execution of Terraform plans and applies.

Let’s break down why the other options are not correct:

B. It doesn’t show the output of a terraform apply locally is incorrect. Whether you’re using a local or remote backend, the output of terraform apply is still shown locally by default. What the remote backend affects is where the state is stored and how it is shared across team members, not the local display of output.
C. It is only available to paying customers is incorrect. While Terraform Cloud does have a premium tier, there is also a free tier that allows basic functionality, including remote backend storage and execution. The remote backend functionality itself isn’t restricted to paying customers, though advanced features in Terraform Cloud do require a paid plan.
D. All of the above is incorrect because options B and C are not accurate, as explained above.

In summary, the main difference of the remote backend, specifically with Terraform Cloud, is the ability to execute Terraform runs on dedicated infrastructure. This provides a managed and optimized environment for infrastructure management, which is not a feature of other backends like S3 or Consul that focus more on state storage.

Question No 4:

What is the correct workflow for deploying new infrastructure using Terraform?

A. terraform plan to import the current infrastructure to the state file, make code changes, and terraform apply to update the infrastructure.
B. Write a Terraform configuration, run terraform show to view proposed changes, and terraform apply to create new infrastructure.
C. terraform import to import the current infrastructure to the state file, make code changes, and terraform apply to update the infrastructure.
D. Write a Terraform configuration, run terraform init, run terraform plan to view planned infrastructure changes, and terraform apply to create new infrastructure.

Correct Answer: D

Explanation:

When deploying new infrastructure with Terraform, the proper sequence of steps is crucial to ensure that the process runs smoothly and that the infrastructure is correctly provisioned and managed. Let’s go through the options and explain why D is the correct choice.

A. terraform plan to import the current infrastructure to the state file, make code changes, and terraform apply to update the infrastructure.
This option is not correct because terraform plan does not import existing infrastructure into the state file. Instead, it is used to generate an execution plan based on the current configuration. Importing infrastructure is done using the terraform import command, but terraform plan by itself does not handle importing or modifying the state. Additionally, this workflow omits key steps like initializing Terraform or explicitly applying changes after modifications.

B. Write a Terraform configuration, run terraform show to view proposed changes, and terraform apply to create new infrastructure.
This option is incorrect because terraform show is used to display the current state of resources and does not provide a way to view proposed changes. terraform show only reveals the state after the infrastructure has been applied, not before. The correct command for previewing changes is terraform plan, which shows what changes will occur when the configuration is applied. Therefore, using terraform show instead of terraform plan makes this option incorrect.

C. terraform import to import the current infrastructure to the state file, make code changes, and terraform apply to update the infrastructure.
While this option correctly mentions terraform import to import existing infrastructure into the state, it doesn’t provide a complete workflow for deploying new infrastructure. Importing existing resources into the state file is only necessary when Terraform is being used to manage infrastructure that was previously created outside of Terraform. The option skips essential steps like initializing Terraform or reviewing the execution plan before applying changes.

D. Write a Terraform configuration, run terraform init, run terraform plan to view planned infrastructure changes, and terraform apply to create new infrastructure.
This is the correct and complete workflow for deploying new infrastructure with Terraform. The steps are as follows:

Write a Terraform configuration: Define the desired infrastructure in .tf configuration files.
terraform init: Initialize the working directory, download necessary provider plugins, and set up the Terraform environment.
terraform plan: Generate and review an execution plan. This step shows what changes Terraform will make to the infrastructure, including creating, modifying, or deleting resources.
terraform apply: Apply the changes defined in the plan to provision or modify infrastructure.

This option covers all the necessary steps, from configuring Terraform to initializing, planning, and finally applying changes, making it the correct answer.

Thus, the correct answer is D.

Question No 5:

Is a provider configuration block required in every Terraform configuration?

A. True
B. False

Correct Answer: B

Explanation:

In Terraform, a provider configuration block is not strictly required in every configuration. The provider block is necessary when you want to interact with a specific cloud platform or infrastructure service, such as AWS, Azure, or Google Cloud. It defines the connection between Terraform and the APIs of the provider, including any authentication credentials, configuration options, and the region or environment in which resources will be managed. However, whether or not this block is required depends on the nature of the Terraform configuration.

Understanding Providers in Terraform

A provider in Terraform is a plugin that allows Terraform to interact with different infrastructure platforms. The provider configuration specifies how Terraform should interact with a given provider, which might include setting up authentication keys, region information, or other specifics required by the provider.

When is the Provider Block Required?

The provider configuration block is required only if you are interacting with an external infrastructure service. It is necessary to specify the provider configuration when you want to manage resources within a particular cloud environment or infrastructure platform.

However, it is important to note that there are cases where a provider block is not required in the Terraform configuration. For example:

Local and non-cloud resources: If your Terraform configuration is used to manage local resources or infrastructure that does not require a provider (for example, using the local-exec provisioner or a similar setup), a provider block is not necessary.
Default providers: In some cases, Terraform can automatically select a default provider if the configuration doesn't explicitly define one. For example, if you’re working with a local provider or a simple infrastructure setup, Terraform may not need to be explicitly told how to interact with the resources.
Pre-configured environments: When working with environments where authentication and provider details are already set up (such as using environment variables for AWS credentials or Google Cloud), the provider block can be omitted, as Terraform can use the default settings.

In summary, a provider block is not required in every Terraform configuration. It is only needed when the configuration requires interaction with an external service or infrastructure. If Terraform is managing resources that don’t require a specific provider, such as local resources, the provider block is not mandatory.

Question No 6:

You are using a local-exec provisioner in a null resource called null_resource.run_script and need to rerun the script. Which command should you use first?

A. terraform taint null_resource.run_script
B. terraform apply -target=null_resource.run_script
C. terraform validate null_resource.run_script
D. terraform plan -target=null_resource.run_script

Correct Answer: A

Explanation:

In Terraform, the local-exec provisioner is commonly used to run scripts or commands on the machine running Terraform during resource creation or modification. However, if the script in a null_resource needs to be rerun, Terraform must first be made aware that the resource has been "tainted," meaning it needs to be recreated. The process of "tainting" a resource ensures that Terraform will treat it as needing to be recreated, which triggers the re-execution of its provisioner.

Why Option A is Correct:

Using terraform taint null_resource.run_script marks the null_resource.run_script as tainted. This action tells Terraform that the resource needs to be recreated and, as a result, the local-exec provisioner will run again. When a resource is tainted, the next time Terraform applies changes, it will treat this resource as "dirty" and will re-execute its associated provisioner. This is the most direct and appropriate method to ensure the script runs again.

Explanation of Other Options:

B. terraform apply -target=null_resource.run_script
The terraform apply -target=null_resource.run_script command applies changes specifically to the null_resource.run_script resource. However, this doesn't guarantee the script will be rerun unless the resource has been marked for recreation (i.e., tainted). This option might apply changes to the resource without triggering the provisioner to rerun. The taint command is the recommended approach to ensure the script is executed again.

C. terraform validate null_resource.run_script
The terraform validate command is used to validate the syntax of the Terraform configuration files but does not apply any changes or trigger the execution of provisioners. Running this command would check for errors in the configuration but wouldn't rerun the script. This option is not relevant for rerunning the script in the provisioner.

D. terraform plan -target=null_resource.run_script
The terraform plan -target=null_resource.run_script command would generate an execution plan for the specific resource. However, it would not trigger a rerun of the local-exec provisioner unless the resource has been tainted or modified. While it helps to preview the changes, it does not directly indicate that the provisioner needs to be rerun. This option is useful for seeing what changes would occur but doesn't actively cause the rerun.

Best Practice:

The recommended approach when needing to rerun a script in a null resource is to taint the resource first. This ensures that the resource is recreated, and its provisioner will run again. Therefore, terraform taint null_resource.run_script is the correct choice for triggering the rerun of the script.

Question No 7:

Which provisioner triggers a process on the resource that Terraform creates?

A. remote-exec
B. null-exec
C. local-exec
D. file

Correct Answer: A

Explanation:

In Terraform, provisioners are used to perform actions on resources after they are created. These actions can be remote or local, depending on how the resource is configured. The goal of a provisioner is typically to configure a resource, run a script, or perform other setup tasks once the resource exists. However, each provisioner operates differently and has specific use cases.

Why A is correct:
The remote-exec provisioner is specifically designed to run commands or scripts on the resource that Terraform has just created. This provisioner is useful when the resource is a remote machine or server. For example, you might use remote-exec to run a configuration script on a virtual machine after it has been provisioned. It connects to the resource using SSH (for Linux-based resources) or WinRM (for Windows-based resources) and runs the specified commands. This allows Terraform to automatically set up resources that require additional configuration beyond just creation.

Why B is incorrect:
The null-exec provisioner is typically used for executing scripts or commands that are not directly related to a resource. This can be helpful for running tasks in between creating resources or performing actions that are not tied to a particular resource. However, it does not directly invoke a process on the resource itself, which is the specific behavior described in the question.

Why C is incorrect:
The local-exec provisioner runs commands locally on the machine where Terraform is running, not on the resource that Terraform creates. This is useful for tasks that need to be performed locally, such as notifying external systems or logging information after the resource is created, but it doesn't directly interact with the resource itself.

Why D is incorrect:
The file provisioner is used for uploading files to a remote resource but does not execute any processes on the resource itself. It allows you to transfer files, but the action does not involve invoking a process or running a script on the resource after its creation.

In summary, the remote-exec provisioner is the one that triggers processes on the resources that Terraform creates. This is particularly useful for running configuration commands on remote resources like virtual machines or cloud instances after they are provisioned.

Question No 8:

Which of the following is not true of Terraform providers?

A. Providers can be written by individuals
B. Providers can be maintained by a community of users
C. Some providers are maintained by HashiCorp
D. Major cloud vendors and non-cloud vendors can write, maintain, or collaborate on Terraform providers
E. None of the above

Correct Answer: E

Explanation:

Terraform providers are essential components that enable Terraform to interact with different APIs and services. They allow Terraform to provision and manage infrastructure resources, ranging from cloud services to DNS, monitoring, and other third-party tools. Let’s go through each option and clarify why the statement "None of the above" is correct.

Option A: Providers can be written by individuals
This is true. Terraform provides a framework that allows individuals to create their own providers for services that Terraform doesn't natively support. While HashiCorp maintains many official providers, anyone with the requisite knowledge can create and write their own provider. These individual contributors can even publish their providers to the Terraform Registry for public use.

Option B: Providers can be maintained by a community of users
This is also true. Many providers are open-source and are maintained by a community of contributors. These community-driven providers can be found on GitHub, and anyone can contribute to their development or improvement. The community ensures that providers are up to date with the services they are managing and that issues are resolved collaboratively.

Option C: Some providers are maintained by HashiCorp
This is correct. HashiCorp maintains several official providers, particularly those for major cloud providers like AWS, Azure, and Google Cloud, as well as other core infrastructure services. HashiCorp takes responsibility for ensuring these providers are reliable and up to date, often working directly with cloud vendors to keep the providers aligned with the latest API changes.

Option D: Major cloud vendors and non-cloud vendors can write, maintain, or collaborate on Terraform providers
This is also true. Cloud vendors like AWS, Microsoft Azure, Google Cloud, and non-cloud vendors like Datadog, VMware, and many others can write, maintain, or collaborate on Terraform providers. These providers enable users to manage infrastructure across various platforms, and the vendors themselves often contribute to these providers to ensure they integrate seamlessly with their services. Terraform encourages collaboration between cloud providers, third-party service vendors, and the broader community.

Option E: None of the above
Given that all the previous options (A, B, C, and D) are true statements, this option is the correct one. It asserts that there is nothing false among the options, making "None of the above" the right answer.

Terraform’s modular and open-source nature allows flexibility in how providers are created, maintained, and improved. This flexibility is part of what makes Terraform such a versatile and widely adopted tool in infrastructure automation.

Question No 9:

What is the first command that Terraform requires when you run it within a configuration directory for the first time?

A. terraform import
B. terraform init
C. terraform plan
D. terraform workspace

Correct Answer: B

Explanation:

When you start working with a Terraform configuration for the first time in a new directory, the terraform init command is necessary to initialize your working environment. The terraform init command is the first step in setting up a working configuration and is crucial because it performs several important functions:

Initialize the Backend: Terraform uses the backend configuration to determine where and how it will store the state of the infrastructure. When you run terraform init, it initializes the backend, whether it's a local backend or a remote one (such as AWS S3, Terraform Cloud, etc.).
Download Provider Plugins: Terraform relies on various providers (such as AWS, Azure, Google Cloud, etc.) to interact with different infrastructure components. When you run terraform init, Terraform will automatically download and install the necessary provider plugins based on the configuration files (such as the provider block in the .tf files). Without these plugins, Terraform would not be able to execute commands for resource creation or modification.
Initialize Modules: If your configuration uses modules, terraform init will initialize those as well. It downloads modules that are either locally defined or sourced from external repositories (like the Terraform Registry or GitHub).
Prepare for Future Operations: After running terraform init, your working directory is ready for subsequent Terraform commands like terraform plan or terraform apply. It sets up the environment so you can plan, apply, or modify your infrastructure as defined in your Terraform configuration files.

Why is the answer B (terraform init)?

The terraform init command is the required first step whenever you are working within a new Terraform configuration directory. It sets up the working environment by configuring the backend, installing providers, and preparing any modules. Running terraform init is always necessary before running other commands like terraform plan or terraform apply, as these commands rely on a properly initialized environment.

Why not the other options?

A. terraform import: The terraform import command is used to import existing resources into Terraform management. This is not the first command you run; you typically use it when you want Terraform to manage resources that were created outside of Terraform.
C. terraform plan: The terraform plan command is used to preview changes Terraform will make based on the current configuration and the actual infrastructure. However, it cannot be executed until the environment is initialized with terraform init.
D. terraform workspace: The terraform workspace command is used to manage multiple workspaces in Terraform, which allows you to isolate different configurations or environments. However, initializing the workspace isn’t the first thing you need to do in a configuration directory.

Question No 10:

What is the best method to quickly find the IP address of the resource you deployed if you did not create any outputs in your code?

A. Run terraform output ip_address to view the result
B. In a new folder, use the terraform_remote_state data source to load in the state file, then write an output for each resource that you find in the state file
C. Run terraform state list to find the name of the resource, then terraform state show to find the attributes including public IP address
D. Run terraform destroy then terraform apply and look for the IP address in stdout

Correct Answer: C

Explanation:

When you deploy a web application using Terraform and need to quickly find the IP address of the deployed resource but didn't create any outputs in your configuration, there are several ways to retrieve that information from Terraform’s state. The best method involves directly interacting with the state file that Terraform uses to track the deployed infrastructure. The key here is that the IP address of the resource is stored in the state file, and you can access it through Terraform’s state commands.

Option C, which suggests running terraform state list to find the resource name and then using terraform state show to view the attributes, including the public IP address, is the most efficient and direct method. Let’s break it down:

Running terraform state list will show all the resources that Terraform is currently managing in the state file. This will give you the name of the resource you deployed, such as an EC2 instance, load balancer, or VM, depending on your infrastructure setup.
Once you have the resource name, you can use terraform state show <resource_name> to inspect the full resource details. This will include all the resource’s attributes, such as the public IP address, which is typically stored in the state file. This method doesn’t require re-running Terraform or altering any configurations, making it quick and non-intrusive.

Now, let’s look at why the other options are not as ideal:

Option A is incorrect because terraform output ip_address only works if outputs were defined in the configuration. Since you didn’t create any outputs, this command will return nothing or an error.
Option B suggests using the terraform_remote_state data source to load in the state file and then define outputs. This approach requires creating a new Terraform project with a remote state data source, which is more complex than simply querying the current state of your deployment. This method introduces unnecessary overhead when you only need the IP address quickly.
Option D is not a good practice because terraform destroy would destroy your resources, and terraform apply would re-create them. This is disruptive and could lead to data loss or downtime. The IP address would be shown in the stdout of the terraform apply command, but you would be re-creating the resources unnecessarily, which is inefficient and not recommended.

In summary, Option C is the best method because it allows you to directly query the state file and retrieve the necessary information about the deployed resource without any disruption or unnecessary steps. It is quick, efficient, and non-intrusive.