[HashiCorp] TA-003 - Terraform Associate Exam Dumps & Study Guide

Free [HashiCorp] TA-003 - Terraform Associate Practice Questions Preview

• Question 1

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

  • A. True
  • B. False

  Correct Answer: B

  Explanation:

  The suggested answer is B. False.
  Reasoning:
  The statement that "the terraform.tfstate file always matches your currently built infrastructure" is false because the state file is merely a snapshot of the infrastructure's configuration as of the last Terraform operation. If changes are made to the infrastructure outside of Terraform (e.g., manual modifications via the cloud provider's console or CLI), the state file will no longer accurately reflect the actual state of the resources. Terraform can only manage resources that it is aware of through its state file. Manual changes introduce "drift," causing the state file to become out of sync with the real infrastructure.

  • For example, if a security group rule is added manually via AWS console, Terraform will not be aware of it unless the state is manually updated or Terraform is used to reconcile the changes.

  Why other options are incorrect:
  Option A, "True," is incorrect because, as explained above, the state file is not automatically updated to reflect changes made outside of Terraform. Manual changes to the infrastructure will cause discrepancies between the state file and the actual infrastructure.

  • Terraform documentation clearly states the importance of keeping the state file synchronized with the actual infrastructure.

  Citations:

  • Terraform State, https://developer.hashicorp.com/terraform/language/state

• Question 2

  One remote backend configuration always maps to a single remote workspace.
  

  • A. True
  • B. False

  Correct Answer: B

  Explanation:

  The statement "One remote backend configuration always maps to a single remote workspace" is False.
  
  Reasoning: A single remote backend configuration in Terraform can indeed manage multiple workspaces. The key to this lies in how the `workspaces` block is configured within the backend settings. This block can be configured to either map to a single, specific workspace or dynamically manage multiple workspaces based on naming conventions or other criteria. This flexibility allows for managing different environments (e.g., development, staging, production) or sets of infrastructure using the same backend configuration, enhancing reusability and reducing redundancy.
  
  The configuration details are documented in Terraform's official documentation. A backend configuration specifies how Terraform persists state, and the remote backend allows for storing this state in a remote location such as Terraform Cloud or HashiCorp Enterprise.
  
  Why other options are incorrect: Option A (True) is incorrect because it limits the capabilities of the remote backend. Terraform is designed to manage multiple environments and infrastructure sets, and restricting a backend to a single workspace would be inefficient and not aligned with best practices.

  • Citations:
  • Terraform Backends, https://developer.hashicorp.com/terraform/language/settings/backends

• Question 3

  How is the Terraform remote backend different than other state backends such as 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:

  The AI agrees with the suggested answer, A. The key difference between Terraform's remote backend and other state backends like S3 or Consul lies in its ability to execute Terraform runs on dedicated infrastructure, whether it's on-premises or within Terraform Cloud. This functionality extends beyond mere state storage.

  Reasoning:

  • The remote backend is designed to not only store state snapshots but also to handle the execution of Terraform operations. This execution can take place in Terraform Cloud or on Terraform Enterprise (on-premises) environments. This centralizes the execution environment, which can enhance security, consistency, and collaboration.
  • The remote backend offers features beyond what basic state storage solutions provide, such as remote execution, access controls, and audit logging, as described in the Terraform documentation.

  Reasons for not choosing other options:

  • Option B: "It doesn't show the output of a terraform apply locally" is incorrect. While the execution happens remotely, the output is typically streamed back and displayed in the local terminal or interface, providing visibility into the progress and results of the Terraform run.
  • Option C: "It is only available to paying customers" is also incorrect. The remote backend functionality is available in both free and paid tiers of Terraform Cloud. While paid tiers offer additional features and capabilities, the basic remote backend functionality is accessible without a paid subscription.
  • Option D: "All of the above" is incorrect because options B and C are incorrect.

  The remote backend's primary distinction is its ability to execute Terraform runs remotely, providing more than just state storage.

• Question 4

  What is the workflow for deploying new infrastructure with 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:

  The AI assistant agrees with the suggested answer D.
  Reasoning: The correct workflow for deploying new infrastructure with Terraform involves the following steps in order:

  • Write a Terraform configuration: Define the desired infrastructure in Terraform configuration files.
  • Run `terraform init`: Initialize the Terraform working directory. This downloads the necessary providers and prepares Terraform for use.
  • Run `terraform plan`: Review the changes Terraform plans to make to your infrastructure. This allows you to verify that the changes are what you expect.
  • Run `terraform apply`: Apply the changes to create the infrastructure. This step executes the actions defined in the plan.

  This sequence ensures that Terraform is properly initialized, the changes are reviewed before execution, and the infrastructure is created in a controlled manner. This workflow is documented in the official Terraform documentation.

  Why other options are incorrect:

  • Option A: `terraform plan` does not import infrastructure; `terraform import` does. Also, the workflow omits `terraform init`.
  • Option B: `terraform show` displays the current state but doesn't show proposed changes like `terraform plan` does. Also, the workflow omits `terraform init`.
  • Option C: `terraform import` is used for bringing existing infrastructure under Terraform management, not for deploying new infrastructure from scratch. Also, it is missing the initialization step.

  The sequence of commands in option D aligns with the recommended Terraform workflow.

  • Terraform Workflow: https://developer.hashicorp.com/terraform/tutorials/aws-get-started/terraform-init

• Question 5

  A provider configuration block is required in every Terraform configuration.
  Example:
  
  

  • A. True
  • B. False

  Correct Answer: B

  Explanation:

  The suggested answer B (False) is correct.
  Reasoning: A provider configuration block is not strictly required in every Terraform configuration. It is only necessary when the configuration interacts with external systems or services through a provider. If the configuration solely manages local resources or the provider is configured via environment variables or other external means, the provider block can be omitted.
  Why other options are incorrect: Option A (True) is incorrect because it states that a provider block is always required, which is not the case in scenarios involving only local resources or external provider configuration. See citations below.

  • Terraform Providers, https://developer.hashicorp.com/terraform/language/providers
  • Terraform documentation on Provider configurations, https://www.terraform.io/language/providers/configuration

• Question 6

  You run a local-exec provisioner in a null resource called null_resource.run_script and realize that you need to rerun the script.
  Which of the following commands would 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:

  The AI agrees with the suggested answer.
  The suggested answer is A: `terraform taint null_resource.run_script`.
  Reasoning:
  The goal is to rerun the local-exec provisioner within the `null_resource.run_script` resource. The `terraform taint` command is designed to mark a resource as tainted, forcing Terraform to destroy and recreate it on the next `terraform apply`. Since the provisioner is executed during resource creation, tainting the resource will cause the provisioner to run again.
  While the `taint` command is considered older, it still serves the purpose of forcing a resource to be recreated, thereby rerunning the provisioner. Alternatives like using `-replace` with `terraform apply` also achieve a similar outcome, the `taint` command directly addresses the need to trigger a re-creation.
  Here's a breakdown of why the other options are less suitable:

  • B: `terraform apply -target=null_resource.run_script`: This command targets the resource for application, but it doesn't guarantee the provisioner will rerun unless the resource's configuration has changed. If Terraform determines no changes are needed, the provisioner won't execute.
  • C: `terraform validate null_resource.run_script`: This command is used for validating the Terraform configuration and does not trigger any resource actions or provisioner executions.
  • D: `terraform plan -target=null_resource.run_script`: This command generates an execution plan for the targeted resource but does not actually apply any changes or rerun the provisioner. It only shows what would happen.

  Therefore, the most direct way to ensure the provisioner reruns is to taint the resource.
  The current documentation still includes the `terraform taint` command:

  • Terraform Taint

  Reasons for not choosing the other answers:
  

  • `terraform apply -target=null_resource.run_script`: This might not rerun the provisioner if Terraform detects no changes to the resource configuration.
  • `terraform validate null_resource.run_script`: This command only validates the configuration and doesn't execute any changes or provisioners.
  • `terraform plan -target=null_resource.run_script`: This command only creates a plan and doesn't execute any changes or provisioners.

  • Terraform Taint, https://developer.hashicorp.com/terraform/cli/commands/taint

• Question 7

  Which provisioner invokes a process on the resource created by Terraform?
  

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

  Correct Answer: A

  Explanation:

  The suggested answer is correct. The correct answer is A: remote-exec.
  Reasoning: The remote-exec provisioner is designed to execute commands on a remote resource after it has been created by Terraform. This makes it suitable for tasks like software installation, configuration, and bootstrapping.
  Why other options are incorrect:

  • null-exec: This provisioner does nothing by itself. It requires a trigger to execute, and its primary purpose is to execute local commands based on changes in other resources. It doesn't inherently invoke processes on a resource created by Terraform.
  • local-exec: This provisioner executes commands on the machine where Terraform is running, not on the resource that Terraform created. Therefore, it is not the correct choice.
  • file: This provisioner is used to copy files to the remote resource, not to execute processes.

  Citations:

  • Terraform provisioners documentation, https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax

• Question 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:

  The suggested answer of E (None of the above) is correct.
  
  Reasoning:
  The question asks for the statement that is *not* true about Terraform providers. All the statements A, B, C, and D are indeed true. Therefore, the correct answer is E, "None of the above".

  • **A. Providers can be written by individuals:** This is true. Anyone can develop a Terraform provider.
  • **B. Providers can be maintained by a community of users:** This is also true. Many providers are community-driven.
  • **C. Some providers are maintained by HashiCorp:** This is true. HashiCorp maintains several core providers (e.g., AWS, Azure, GCP).
  • **D. Major cloud vendors and non-cloud vendors can write, maintain, or collaborate on Terraform providers:** This statement is also true. Cloud providers often contribute to their respective providers.

  Since all the statements are true, the only option that accurately reflects the question ("Which of the following is not true") is "None of the above".
  
  Reasons for not selecting other options:
  Options A, B, C, and D are all true statements about Terraform providers. The question specifically asks for the statement that is *not* true. Since these options are all true, they cannot be the correct answer.

  
  Citations:

  • Terraform Providers, https://developer.hashicorp.com/terraform/tutorials/providers/provider-use

• Question 9

  What command does Terraform require the first time you run it within a configuration directory?
  

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

  Correct Answer: B

  Explanation:

  The suggested answer is correct.
  Terraform init is the command required the first time you run Terraform in a configuration directory.
  Reason: terraform init initializes a working directory containing Terraform configuration files. This is the first command that should be run after writing a new Terraform configuration or cloning an existing one from version control. This command performs several steps:

  • Initializes the working directory: Creates a hidden .terraform subdirectory where Terraform stores its state and other metadata.
  • Downloads plugins: Downloads the necessary plugins (providers) that Terraform needs to interact with the infrastructure specified in the configuration.
  • Configures backend: Sets up the backend where Terraform state will be stored (e.g., local, remote).

  Without running terraform init, Terraform will not be able to understand the configuration, download necessary plugins, or manage the state of the infrastructure.

  Reasons for not choosing the other answers:

  • terraform import: Used to import existing infrastructure into Terraform management, not a prerequisite for initial setup.
  • terraform plan: Used to create an execution plan, which requires initialization first.
  • terraform workspace: Used to manage multiple states of the infrastructure, which also requires initialization first.

  Citations:

  • Terraform init - Initialize a working directory, https://developer.hashicorp.com/terraform/cli/commands/init

• Question 10

  You have deployed a new webapp with a public IP address on a cloud provider. However, you did not create any outputs for your code.
  What is the best method to quickly find the IP address of the resource you deployed?
  

  • 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 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:

  The AI agrees with the suggested answer, which is option C.
  The best method to quickly find the IP address of the deployed resource is to run `terraform state list` to find the name of the resource, then `terraform state show` to find the attributes including the public IP address.
  
  Reasoning:
  Option C is the most appropriate because the question specifies that no outputs were created. In the absence of declared outputs, the Terraform state file holds the information about provisioned resources, including their attributes like public IP addresses. The `terraform state list` command helps identify the resource name, and `terraform state show ` displays the resource's attributes, including the public IP address, if it exists. This method directly accesses the state file without requiring any modifications to the Terraform code.
  
  Reasons for not choosing other options:

  • A: `terraform output ip_address` would not work because the question states that no outputs were created. This command relies on a pre-defined output variable.
  • B: Using `terraform_remote_state` in a new folder is an unnecessarily complex and time-consuming approach. While it would eventually work, it requires setting up a new Terraform configuration and is not the quickest method.
  • D: Running `terraform destroy` and then `terraform apply` just to find the IP address is highly inefficient and destructive. It involves tearing down and recreating the infrastructure, which is not a reasonable solution for simply retrieving the IP address.

  
  This approach aligns with best practices for troubleshooting and information retrieval in Terraform, especially when outputs are not defined.

  
  

  Citations:

  • Terraform state command - Terraform by HashiCorp, https://developer.hashicorp.com/terraform/cli/commands/state