HashiCorp TERRAFORM-ASSOCIATE-003 Online Practice Questions and Exam Preparation

HashiCorp TERRAFORM-ASSOCIATE-003 Online Questions & Answers

• Question 471:

  Which of the following is not a key principle of infrastructure as code?

  A. Versioned infrastructure
  B. Golden images
  C. Idempotence
  D. Self-describing infrastructure
  B. Golden images

  ---

  Explanation

  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]

• Question 472:

  You have a Terraform configuration that defines a single virtual machine with no references to it, You have run terraform apply to create the resource, and then removed the resource definition from your Terraform configuration file. What will happen you run terraform apply in the working directory again?

  A. Terraform will remove the virtual machine from the state file, but the resource will still exist
  B. Nothing
  C. Terraform will error
  D. Terraform will destroy the virtual machine
  D. Terraform will destroy the virtual machine

  ---

  Explanation

  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.

• Question 473:

  Which of the following commands would you use to access all of the attributes and details of a resource managed by Terraform?

  A. terraform state list `provider_type.name'
  B. terraform state show `provider_type.name'
  C. terraform get `provider_type.name'
  D. terraform state list
  B. terraform state show `provider_type.name'

  ---

  Explanation

  The terraform state show command allows you to access all of the attributes and details of a resource managed by Terraform. You can use the resource address (e.g. provider_type.name) as an argument to show the information about a

  specific resource. The terraform state list command only shows the list of resources in the state, not their attributes. The terraform get command downloads and installs modules needed for the configuration. It does not show any information

  about resources.

  References: [Command:

  state show] and [Command: state list]

• Question 474:

  You have created a custom variable definition file my_vars.tfvars. How will you use it for provisioning infrastructure?

  A. terraform apply-var-state-file ="my_vars.tfvars"
  B. terraform apply var-file="my_vars.tfvars"
  C. terraform plan-var-file="my_vars.tfvar"
  D. terraform apply-var-file="my_vars.tfvars"
  D. terraform apply-var-file="my_vars.tfvars"

  ---

  Explanation

  To set lots of variables, it is more convenient to specify their values in a variable definitions file (with a filename ending in either .tfvars or .tfvars.json) and then specify that file on the command line with-var-file:

  terraform apply-var-file="my_vars.tfvars"

  https://www.terraform.io/docs/configuration/variables.html#variable-definitions-tfvars-files

• Question 475:

  When using multiple configurations of the same Terraform provider, what meta-argument must be included in any non-default provider configurations?

  A. name
  B. alias
  C. depends_on
  D. id
  B. alias

  ---

  Explanation

• Question 476:

  Provisioners should only be used as a last resort.

  A. False
  B. True
  B. True

  ---

  Explanation

  Provisioners are a Last Resort Terraform includes the concept of provisioners as a measure of pragmatism, knowing that there will always be certain behaviors that can't be directly represented in Terraform's declarative model. However, they also add a considerable amount of complexity and uncertainty to Terraform usage. Firstly, Terraform cannot model the actions of provisioners as part of a plan because they can in principle take any action. Secondly, successful use of provisioners requires coordinating many more details than Terraform usage usually requires: direct network access to your servers, issuing Terraform credentials to log in, making sure that all of the necessary external software is installed, etc. The following sections describe some situations which can be solved with provisioners in principle, but where better solutions are also available. We do not recommend using provisioners for any of the use-cases described in the following sections. Even if your specific use-case is not described in the following sections, we still recommend attempting to solve it using other techniques first, and use provisioners only if there is no other option. https://www.terraform.io/docs/provisioners/index.html

• Question 477:

  Your team has started using terraform OSS in a big way , and now wants to deploy multi region deployments (DR) in aws using the same terraform files . You want to deploy the same infra (VPC,EC2 ...) in both us-east-1 ,and us-west-2 using the same script , and then peer the VPCs across both the regions to enable DR traffic. But , when you run your script , all resources are getting created in only the default provider region. What should you do? Your provider setting is as below

  # The default provider configuration provider "aws" { region = "us-east-1" }

  A. No way to enable this via a single script . Write 2 different scripts with different default providers in the 2 scripts , one for us-east , another for us-west.
  B. Create a list of regions , and then use a for-each to iterate over the regions , and create the same resources ,one after the one , over the loop.
  C. Use provider alias functionality , and add another provider for us-west region . While creating the resources using the tf script , reference the appropriate provider (using the alias).
  D. Manually create the DR region , once the Primary has been created , since you are using terraform OSS , and multi region deployment is only available in Terraform Enterprise.
  C. Use provider alias functionality , and add another provider for us-west region . While creating the resources using the tf script , reference the appropriate provider (using the alias).

  ---

  Explanation

  You can optionally define multiple configurations for the same provider, and select which one to use on a per-resource or per-module basis. The primary reason for this is to support multiple regions for a cloud platform; other examples include

  targeting multiple Docker hosts, multiple Consul hosts, etc.

  To include multiple configurations for a given provider, include multiple provider blocks with the same provider name, but set the alias meta-argument to an alias name to use for each additional configuration. For example:

  # The default provider configuration

  provider "aws" {

  region = "us-east-1"

  }

  # Additional provider configuration for west coast region provider "aws" {

  alias = "west"

  region = "us-west-2"

  }

  https://www.terraform.io/docs/configuration/providers.html

• Question 478:

  You wanted to destroy some of the dependent resources from real infrastructure. You choose to delete those resources from your configuration file and run terraform plan and then apply. Which of the following way your resources would be destroyed?

  A. Terraform can still determine the correct order for destruction from the state even when you delete one or more items from the configuration.
  B. Those would be destroyed in the order in which they were written in the configuration file previously before you have deleted them from configuration file.
  C. The resource will be destructed in random order as you have already deleted them from configuration.
  D. You can not destroy resources by deleting them from configuration file and running plan and apply.
  A. Terraform can still determine the correct order for destruction from the state even when you delete one or more items from the configuration.

  ---

  Explanation

  Terraform typically uses the configuration to determine dependency order. However, when you delete a resource from a Terraform configuration, Terraform must know how to delete that resource. Terraform can see that a mapping exists for a resource not in your configuration and plan to destroy. However, since the configuration no longer exists, the order cannot be determined from the configuration alone. To ensure correct operation, Terraform retains a copy of the most recent set of dependencies within the state. Now Terraform can still determine the correct order for destruction from the state when you delete one or more items from the configuration.

• Question 479:

  What is one disadvantage of using dynamic blocks in Terraform?

  A. They cannot be used to loop through a list of values
  B. Dynamic blocks can construct repeatable nested blocks
  C. They make configuration harder to read and understand
  D. Terraform will run more slowly
  C. They make configuration harder to read and understand

  ---

  Explanation

  "Overuse of dynamic blocks can make configuration hard to read and maintain, so we recommend using them only when you need to hide details in order to build a clean user interface for a re-usable module. Always write nested blocks out literally where possible."

  https://github.com/hashicorp/terraform/issues/19291

• Question 480:

  You have created two workspaces PROD and DEV. You have switched to DEV and provisioned DEV infrastructure from this workspace. Where is your state file stored?

  A. terraform.d
  B. terraform.tfstate
  C. terraform.tfstate.DEV
  D. terraform.tfstate.d
  D. terraform.tfstate.d

  ---

  Explanation

  Terraform stores the workspace states in a directory called terraform.tfstate.d. This directory should be treated similarly to default workspace state file terraform.tfstate main.tf provider.tf terraform.tfstate.d DEV terraform.tfstate # DEV workspace state file PROD terraform.tfstate # PROD workspace state file terraform.tfvars # Default workspace state file variables.tf