Terraform-Associate Flashcards

Question

True or False? Collection variable types allow multiple values of one primitive type variable to be grouped together.

Answer 1

False Terraform comes pre-packaged with a number of built-in functions. Users cannot create their own functions like in a programming language.

Answer 2

Structural A structural variable type allows multiple values of various primitive types to be grouped together as a single value. In this case, the variable training has 2 separate types of values within it, namely a string and a number.

Answer 3

TF_LOG=TRACE

Answer 4

terraform workspace select production

Answer 5

It formats your Terraform code for readability and consistency.

Answer 6

- It will mark the resource as tainted in the state file - It will be deleted - Re-created upon the next terraform apply.

Answer 7

It brings external, unmanaged resources into your Terraform configuration to be tracked and managed by it.

Answer 8

It helps teams use Terraform together. | Easy access to shared state and secret data.

Answer 9

Open-source Terraform workspaces can automatically back up your configuration to Terraform Cloud.

Answer 10

A repository of publicly available Terraform providers and modules.

Answer 11

- makes deployments more secure | - act as protection against accidental deployments.

Answer 12

- It can store your long-lived credentials in a secure way | - "dynamically inject short-lived", "temporary keys" to Terraform at deployment.

Answer 13

A policy-as-code framework that enforces adherence to policies within your Terraform code.

Answer 14

A secure place to manage access to the secrets for your Terraform configurations, in addition to integrating with other popular cloud vendors. Provides short-lived, temporary credentials for users with only the permissions needed for infrastructure creation. Allows you to store sensitive data securely that can be used for your Terraform configurations.

Answer 15

A built-in version control similar to GitHub

Answer 16

providers are released on a separate schedule from Terraform itself; therefore a newer version could introduce breaking changes

Answer 17

the resource will be updated in place

Answer 18

a plugin that Terraform uses to translate the API interactions with the service or provider

Answer 19

required_providers For production use, you should constrain the acceptable provider versions via configuration file to ensure that new versions with breaking changes will not be automatically installed by Terraform init in the future. When terraform init is run without provider version constraints, it prints a suggested version constraint string for each provider For example: ``` terraform { required_providers { aws = ">= 3.1.0" } } ```

Answer 20

update the configuration file to include the new resources Explanation The current implementation of Terraform import can only import resources into the state. It does not generate a configuration. Because of this, and prior to running terraform import, it is necessary to manually write a resource configuration block for the resource to which the imported object will be mapped. First, add the resources to the configuration file: ``` resource "aws_instance" "example" { # ...instance configuration... } Then run the following command: ``` $ terraform import aws_instance.example i-abcd1234 https://www.terraform.io/docs/commands/import.html

Answer 21

rewrite Terraform configuration files to a canonical format and style

Answer 22

- Clustering

Answer 23

current working directory By default, the state file is stored in a local file named "terraform.tfstate", but it can also be stored remotely, which works better in a team environment.

Answer 24

The local backend: "stores state on the local filesystem" "locks the state using system APIs" "performs operations locally" Information on the default local backend can be found at this link. Example: ``` terraform { backend "local" { path = "relative/path/to/terraform.tfstate" } } ```

Answer 25

False If you are already using Terraform to manage infrastructure, you probably want to transfer to another backend, such as Terraform Cloud, so you can continue managing it. By migrating your Terraform state, you can hand off infrastructure without de-provisioning anything.

Answer 26

- ssh - winrm The remote-exec provisioner invokes a script on a remote resource after it is created. The remote-exec provisioner supports both ssh and winrm type connections.

Answer 27

Terraform provider

Answer 28

- terraform.tfstate | - terraform.tfvars

Answer 29

dynamic block A dynamic block acts much like a for expression but produces nested blocks instead of a complex typed value. It iterates over a given complex value and generates a nested block for each element of that complex value.

Answer 30

- When using local state, the state file is stored in plain-text - The Terraform state can contain sensitive data, therefore the state file should be protected from unauthorized access - Terraform Cloud always encrypts state at rest - Storing state remotely can provide better security Terraform state can contain sensitive data, depending on the resources in use and your definition of "sensitive." The state contains resource IDs and all resource attributes. For resources such as databases, this may contain initial passwords. When using the local state, the state is stored in plain-text JSON files. If you manage any sensitive data with Terraform (like database passwords, user passwords, or private keys), treat the state itself as sensitive data. Storing Terraform state remotely can provide better security. As of Terraform 0.9, Terraform does not persist state to the local disk when the remote state is in use, and some backends can be configured to encrypt the state data at rest.

Answer 31

the output of another module

Answer 32

- increased performance - determining the correct order to destroy resources - mapping configuration to real-world resources

Answer 33

- main.tf is the calling module | - app-cluster is the child module

Answer 34

terraform validate The terraform validate command validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc. Validate runs checks that verify whether a configuration is syntactically valid and internally consistent, regardless of any provided variables or existing state. It is thus primarily useful for general verification of reusable modules, including the correctness of attribute names and value types.

Answer 35

- show examples and READMEs - automatically generated documentation - allow browsing version histories - support versioning

Answer 36

- command-line key/value pairs - interactively on the command line - use the -backend-config=PATH to specify a separate config file

Answer 37

terraform show The terraform show command is used to provide human-readable output from a state or plan file. This can be used to inspect a plan to ensure that the planned operations are expected, or to inspect the current state as Terraform sees it. Machine-readable output can be generated by adding the -json command-line flag. Note: When using the -json command-line flag, any sensitive values in Terraform state will be displayed in plain text.

Answer 38

- to execute one or more commands on the machine running Terraform - to invoke a local execution

Answer 39

- Infrastructure as Code gives the user the ability to recreate an application's infrastructure for (1) "disaster recovery scenarios" - Infrastructure as Code easily (2)"repeatable" allowing the user to reuse code to deploy similar, yet different resources - Infrastructure as Code allows a user to turn a manual task into a simple, (3)"automated deployment" - Infrastructure as Code provides (4)"configuration consistency and standardization among deployments" - Infrastructure as Code is relatively (5)"simple to learn and write", regardless of a user's prior experience with developing code

Answer 40

the output of a module named web_server

Answer 41

- download the declared providers which are supported by HashiCorp - initializes downloaded and/or installed providers - initializes the backend configuration

Answer 42

- public module registry | - private module registry

Answer 43

- input variables

Answer 44

secrets are persisted to the state file and plans

Answer 45

- declared/used in a configuration file | - initialized

Answer 46

team management and governance

Answer 47

True The list function is deprecated. From Terraform v0.12, the Terraform language has built-in syntax for creating lists using the [ and ] delimiters. Use the built-in syntax instead. The list function will be removed in a future version of Terraform.

Answer 48

an API token

Answer 49

10 Terraform can limit the number of concurrent operations as Terraform walks the graph using the -parallelism=n argument. The default value for this setting is 10. This setting might be helpful if you're running into API rate limits.

Answer 50

Terraform analyzes any expressions within a resource block to find references to other objects and treats those references as implicit ordering requirements when creating, updating, or destroying resources.

Answer 51

since he has introduced a new provider, a terraform init needs to be run to download the Infoblox plugin

Answer 52

- use of any resource belonging to a particular provider in a resource or data block in the configuration - Existence of any resource instance belonging to a particular provider in the current state. - Explicit use of a provider block in configuration, optionally including a version constraint.

Answer 53

add an "output that references the subnet module" and retrieve the value using "module.subnet.subnet_id" in the load balancer module

Answer 54

{ "a" = 1 "b" = 2 } zipmap constructs a map from a list of keys and a corresponding list of values. A map is denoted by { } whereas a list is denoted by [ ].

Answer 55

Terraform is an immutable, declarative, Infrastructure as Code provisioning language based on Hashicorp Configuration Language, or optionally JSON.

Answer 56

- use terraform taint to mark the virtual machine as tainted The terraform taint command manually marks a Terraform-managed resource as tainted, forcing it to be destroyed and recreated on the next apply. This command will not modify infrastructure but does modify the state file in order to mark a resource as tainted. Once a resource is marked as tainted, the next plan will show that the resource will be destroyed and recreated and the next apply will implement this change. You could also use terraform destroy -target and destroy only the virtual machine and then run a terraform apply again.

Answer 57

terraform init terraform get Both the terraform get and terraform init commands will install and update-modules. The terraform init command will also initialize backends and install plugins.

Answer 58

force-unlock terraform force-unlock removes the lock on the state for the current configuration. Be very careful forcing an unlock, as it could cause data corruption and problems with your state file.

Answer 59

- macOS - Solaris - FreeBSD - Linux - Windows

Answer 60

2 index finds the element index for a given value in a list starting with index 0. Therefore, "a" is at index 0, "b" is at index 1, and "c" is at index 2.

Answer 61

False Currently, Terraform has no mechanism to redact or protect secrets that are returned via data sources, so secrets read via this provider will be persisted into the Terraform state, into any plan files, and in some cases in the console output produced while planning and applying. These artifacts must, therefore, all be protected accordingly.

Answer 62

terraform validate The terraform validate command validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc. Validate runs checks that verify whether a configuration is syntactically valid and internally consistent, regardless of any provided variables or existing state. It is thus primarily useful for general verification of reusable modules, including the correctness of attribute names and value types. https://www.terraform.io/docs/commands/validate.html

Answer 63

resource The format of resource block configurations is as follows: "" ""

Answer 64

terraform workspace select dev

Answer 65

the resource is marked as tainted

Answer 66

True Terraform destroy will always prompt for confirmation before executing unless passed the -auto-approve flag.

Answer 67

- SAML/SSO - Audit Logging - Self-Service Infrastructure Self-Service Infrastructure, Audit Logging, and SAML/SSO are only available in Terraform Cloud for Business or Terraform Enterprise.

Answer 68

variable "example" { description = "This is a variable description" type = list(string) default = {} } Lists are defined with [ ], maps are defined with { }.

Answer 69

these variables that are passed into the child module are likely used for resource creation These are the input variables that are being set for the child module, in which the child module will likely use to create resources. These variables are declared elsewhere, likely in a variables.tf file, and the values are pulled from either the default value, a .tfvars file, environment variable, or from another resource.

Answer 70

run a "terraform state rm" command to remove the Cloud SQL instance from Terraform management before running the terraform destroy command Ex: In this case, the easiest way to accomplish this is to remove the database from the terraform state file, removing that resource from Terraform management. Afterward, the team can use the terraform destroy command which will delete all other resources. All other options would be too time-consuming or would cause an outage to the database.

Answer 71

Terraform 0.12 introduced substantial changes to the syntax used to write a Terraform configuration. Explanation You can use required_version to ensure that a user deploying infrastructure is using Terraform 0.12 or greater, due to the vast number of changes that were introduced. As a result, many previously written configurations had to be converted or rewritten.

Answer 72

directory called terraform.tfstate.d

Answer 73

- it can be versioned - it can be shared - it can be reused Explanation Infrastructure as Code has many benefits, including being able to create a blueprint of your data center which can be versioned, shared, and reused. However, in a general sense, not all IaC tools are platform agnostic like Terraform. https://www.terraform.io/intro/index.html#infrastructure-as-code

Answer 74

False Explanation The terraform refresh command is used to reconcile the state Terraform knows about (via its state file) with the real-world infrastructure. This can be used to detect any drift from the last-known state, and to update the state file. This does not modify infrastructure but does modify the state file. If the state is changed, this may cause changes to occur during the next plan or apply.

Answer 75

modify the current state, such as removing items Explanation The terraform state command is used for advanced state management. Rather than modify the state directly, the terraform state commands can be used in many cases instead. To refresh Terraform state, use the command terraform refresh.

Answer 76

TF_LOG Explanation Terraform has detailed logs that can be enabled by setting the TF_LOG environment variable to any value. This will cause detailed logs to appear on stderr. You can set TF_LOG to one of the log levels TRACE, DEBUG, INFO, WARN or ERROR to change the verbosity of the logs. TRACE is the most verbose and it is the default if TF_LOG is set to something other than a log level name.

Answer 77

- Azure DevOps Server - GitHub - GitHub Enterprise - Bitbucket Cloud

Answer 78

The .terraform/plugins directory in the directory terraform init was executed in.

Answer 79

private module registry Explanation You can use modules from a private registry, like the one provided by Terraform Cloud. Private registry modules have source strings of the form ///. This is the same format as the public registry, but with an added hostname prefix.

Answer 80

True Explanation The persistent data stored in the backend belongs to a workspace. Initially, the backend has only one workspace, called "default", and thus there is only one Terraform state associated with that configuration.

Answer 81

github Explanation GitHub is not a supported backend type. Check out the supported backends using the link below. Remember there is the "local" backend and then there are remote backends that store state elsewhere. Remote backends (and locking) are needed when more than one person is interacting with the same state file.

Answer 82

air-gapped Explanation A Terraform Enterprise install that is provisioned on a network that does not have Internet access is generally known as an air-gapped install. These types of installs require you to pull updates, providers, etc. from external sources vs. being able to download them directly.

Answer 83

PostgreSQL Explanation External Services mode stores the majority of the stateful data used by the instance in an external PostgreSQL database and an external S3-compatible endpoint or Azure blob storage. There is still critical data stored on the instance that must be managed with snapshots. Be sure to check the PostgreSQL Requirements for information that needs to be present for Terraform Enterprise to work. This option is best for users with expertise managing PostgreSQL or users that have access to managed PostgreSQL offerings like AWS RDS. Check out the Pre-requisite document for more information - https://www.terraform.io/docs/enterprise/before-installing/index.html

Answer 84

align their equals signs ami = "abc123" instance_type = "t2.micro" Explanation HashiCorp style conventions suggest you that align the equals sign for consecutive arguments for easing readability for configurations ``` ami = "abc123" instance_type = "t2.micro" ```

Answer 85

terraform plan Explanation It is important to consider that "Terraform reads from data sources during the plan phase and writes the result into the plan." For something like a Vault token which has an explicit TTL, the apply must be run before the data, or token, in this case, expires, otherwise, Terraform will fail during the apply phase. Another example of this is AWS credentials: The token is generated from the moment the configuration retrieves the temporary AWS credentials (on terraform plan or terraform apply). If the apply run is confirmed after the 120 seconds, the run will fail because the credentials used to initialize the Terraform AWS provider has expired. For these instances or large multi-resource configurations, you may need to adjust the default_lease_ttl_seconds. Check out the blue box under this section for more information: https://learn.hashicorp.com/tutorials/terraform/secrets-vault#provision-compute-instance

Answer 86

a sequence of values identified by consecutive whole numbers starting with zero. Explanation A terraform list is a sequence of values identified by consecutive whole numbers starting with zero. https://www.terraform.io/docs/configuration/types.html#structural-types

Answer 87

The EC2 instance labeled web_server Explanation The EC2 instance labeled web_server is the implicit dependency as the aws_eip cannot be created until the aws_instance labeled web_server has been provisioned and the id is available. Note that aws_s3_bucket.example is an explicit dependency. https://learn.hashicorp.com/tutorials/terraform/dependencies

Answer 88

what Explanation lookup retrieves the value of a single element from a map, given its key. If the given key does not exist, the given default value is returned instead. In this case, the function call is searching for the key "c". Because there is no key "c", the default value of "what?" is returned.

Answer 89

resource "aws_security_group" "vault_elb" { name = "${var.name_prefix}-vault-elb" description = "Vault ELB" vpc_id = var.vpc_id } Explanation When assigning a value to an argument, it must be enclosed in quotes ("...") unless it is being generated programmatically. https://www.terraform.io/docs/configuration/syntax.html#arguments-and-blocks

Answer 90

source="git::https://example.com/my_test_module.git?ref=v1.0.4" Explanation By default, Terraform will clone and use the default branch (referenced by HEAD) in the selected repository. You can override this using the ref argument: module "vpc" { source = "git::https://example.com/vpc.git?ref=v1.2.0" } The value of the ref argument can be any reference that would be accepted by the git checkout command, including branch and tag names. https://www.terraform.io/docs/modules/sources.html#selecting-a-revision

Answer 91

terraform console Explanation The terraform console command provides an interactive console for evaluating expressions. https://www.terraform.io/docs/commands/console.html

Answer 92

1. 2.3 1. 2.9 Explanation ~> 1.2.0 will match any non-beta version of the provider between >= 1.2.0 and < 1.3.0. For example, 1.2.X https://www.terraform.io/docs/configuration/modules.html#gt-1-2-0-1

Answer 93

alias Explanation An alias meta-argument is used when using the same provider with different configurations for different resources. https://www.terraform.io/docs/configuration/providers.html#alias-multiple-provider-instances

Answer 94

explicit dependency Explanation Sometimes there are dependencies between resources that are not visible to Terraform. The depends_on argument is accepted by any resource and accepts a list of resources to create explicit dependencies for. https://learn.hashicorp.com/tutorials/terraform/dependencies

Answer 95

use terraform import to import the existing resources under Terraform management Explanation The terraform import command is used to import existing resources into Terraform. This allows you to take resources that you’ve created by some other means and bring them under Terraform management. Note that terraform import DOES NOT generate configuration, it only modifies state. You'll still need to write a configuration block for the resource for which it will be mapped using the terraform import command. https://www.terraform.io/docs/commands/import.html

Answer 96

terraform workspace new stage Explanation The terraform workspace new command is used to create a new workspace. https://www.terraform.io/docs/commands/workspace/new.html

Answer 97

run a terraform plan and validate the changes that will be made Explanation The terraform plan command is used to create an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files. This command is a convenient way to check whether the execution plan for a set of changes matches your expectations without making any changes to real resources or to the state. https://www.terraform.io/docs/commands/plan.html

Answer 98

The registry uses tags to identify module versions. Release tag names must be for the format x.y.z, and can optionally be prefixed with a v Module repositories must use this three-part name format, terraform-- The module must be on GitHub and must be a public repo

Answer 99

count Explanation count is a reserved word. The count parameter on resources can simplify configurations and let you scale resources by simply incrementing a number. https://www.terraform.io/intro/examples/count.html

Answer 100

TF_VAR Explanation Environment variables can be used to set variables. The environment variables must be in the format TF_VAR_name and this will be checked last for a value. For example: export TF_VAR_region=us-west-1 export TF_VAR_ami=ami-049d8641 export TF_VAR_alist='[1,2,3]' export TF_VAR_amap='{ foo = "bar", baz = "qux" }' https://www.terraform.io/docs/commands/environment-variables.html

Answer 101

False Explanation With Terraform 0.13, terraform init can now automatically download community providers. https://www.hashicorp.com/blog/automatic-installation-of-third-party-providers-with-terraform-0-13 In June at HashiConf digital we announced the beta version of HashiCorp Terraform 0.13. Many of the improvements in Terraform 0.13 focus on the diverse, rapidly-growing collection of official, partner, and community providers. With Terraform 0.13, terraform init will automatically download and install partner and community providers in the HashiCorp Terraform Registry, following the same clear workflow as HashiCorp-supported official providers. These improvements to the ecosystem will benefit Terraform users and provider developers alike.

Answer 102

terraform refresh Explanation The terraform refresh command is used to reconcile the state Terraform knows about (via its state file) with the real-world infrastructure. This can be used to detect any drift from the last-known state, and to update the state file. https://www.terraform.io/docs/commands/refresh.html

Answer 103

- code can easily be shared and reused - allows infrastructure to be versioned - creates a blueprint of your data center Explanation Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used. Infrastructure as Code almost always uses parallelism to deploy resources faster. And depending on the solution being used, it doesn't always have access to the latest features and services available on cloud platforms or other solutions. https://www.terraform.io/intro/index.html#infrastructure-as-code

Answer 104

aws_s3_bucket.customer_data Explanation In this example, the only resource that does not have an implicit or an explicit dependency is the aws_s3_bucket.customer_data. Every other resource defined in this configuration has a dependency on another resource. https://learn.hashicorp.com/tutorials/terraform/dependencies

Answer 105

- resource block Explanation Based on the Terraform code provided in the question, the VPC is defined in a resource block, meaning that there is a VPC resource being defined, such as: resource "aws_vpc" "main" { cidr_block = var.base_cidr_block } If it were locals, the resource would be referred to as local.aws_vpc If it were in a data block, it would be referred to as data.aws_vpc.i.main.id = https://www.terraform.io/docs/configuration/resources.html

Answer 106

sentinel Explanation Sentinel is an embedded policy-as-code framework integrated with the HashiCorp Enterprise products. It enables fine-grained, logic-based policy decisions, and can be extended to use information from external sources. https://www.terraform.io/docs/cloud/sentinel/index.html

Answer 107

use the -out parameter -out=FILE Explanation The optional -out argument can be used to save the generated plan to a file for later execution with terraform apply, which can be useful when running Terraform in automation. https://www.terraform.io/docs/commands/plan.html

Answer 108

local ``` Explanation A local value assigns a name to an expression, so you can use it multiple times within a module without repeating it. ``` https://www.terraform.io/docs/configuration/locals.html

Answer 109

enables Terraform to fetch data for use elsewhere in the Terraform configuration Explanation Data sources allow data to be fetched or computed for use elsewhere in Terraform configuration. Use of data sources allows a Terraform configuration to make use of information defined outside of Terraform, or defined by another separate Terraform configuration. https://www.terraform.io/docs/configuration/data-sources.html

Answer 110

create a configuration for the new resource in the Terraform configuration file, such as: ``` resource "aws_instance" "web_app_42" { # (resource arguments) } ``` Explanation The terraform import command is used to import existing resources into Terraform. However, Terraform will not create a configuration for the imported resource. The Terraform operator must create/add a configuration for the resource that will be imported first. Once the configuration is added to the configuration file, the terraform import command can be executed to manage the resource using Terraform. https://www.terraform.io/docs/commands/import.html

Answer 111

aws_instance.web["example"] Explanation The following specifications apply to index values on modules and resources with multiple instances: [N] where N is a 0-based numerical index into a resource with multiple instances specified by the count meta-argument. Omitting an index when addressing a resource where count > 1 means that the address references all instances. ["INDEX"] where INDEX is an alphanumerical key index into a resource with multiple instances specified by the for_each meta-argument. https://www.terraform.io/docs/internals/resource-addressing.html ---------------------------------------------------------------------------------- count Example Given a Terraform config that includes: ``` resource "aws_instance" "web" { # ... count = 4 } An address like this: ``` aws_instance.web[3] Refers to only the last instance in the config, and an address like this: ``` aws_instance.web Refers to all four "web" instances. ---------------------------------------------------------------------------------- »for_each Example Given a Terraform config that includes: ``` ``` resource "aws_instance" "web" { # ... for_each = { "terraform": "value1", "resource": "value2", "indexing": "value3", "example": "value4", } } An address like this: ``` aws_instance.web["example"] Refers to only the "example" instance in the config.

Answer 112

sentinel policies Explanation All of the options are available to open-source users except for Sentinel, which is only available in Terraform Enterprise and Terraform Cloud paid tiers. https://www.hashicorp.com/products/terraform/pricing

Answer 113

the value of an input variable

Answer 114

- integrated services, such as AWS IAM or Azure Managed Service Identity - directly in the provider block by hardcoding or using a variable - use environment variables

Answer 115

the remaining virtual machine was not created by Terraform, therefore Terraform is not aware of the virtual machine and cannot destroy it Explanation The terraform destroy command terminates resources defined in your Terraform configuration. This command is the reverse of terraform apply in that it terminates all the resources specified by the configuration. It does not destroy resources running elsewhere that are not described in the current configuration. https://learn.hashicorp.com/tutorials/terraform/aws-destroy

Answer 116

using the same provider with different configurations for different resources Explanation 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 create multiple configurations for a given provider, include multiple provider blocks with the same provider name. For each additional non-default configuration, use the alias meta-argument to provide an extra name segment. https://www.terraform.io/docs/configuration/providers.html

Answer 117

From a data source that is retrieving credentials from HashiCorp Vault. Vault is dynamically generating the credentials on Terraform's behalf. Explanation In this case, Terraform is using a data source to gather credentials from Vault. The data block would look something like this: data "vault_aws_access_credentials" "creds" { backend = vault_aws_secret_backend.aws.path role = vault_aws_secret_backend_role.role.name } https://www.terraform.io/docs/configuration/data-sources.html

Answer 118

Terraform Cloud for Business Explanation This newer feature is only available on Terraform Cloud for Business https://www.hashicorp.com/products/terraform/pricing

Answer 119

Jeff removed the resource from the state file, "but not the configuration file". Therefore, Terraform is no longer aware of the virtual machine and assumes Jeff wants to create a new one since the virtual machine is still in the Terraform configuration file Explanation: Because Jeff manually deleted the resource from the state file, Terraform was no longer aware of the virtual machine. When Jeff ran a terraform apply, it refreshed the state file and discovered that the configuration file declared a virtual machine but it was not in state, therefore Terraform needed to create a virtual machine so the provisioned infrastructure matched the desired configuration, which is the Terraform configuration file. Hopefully, this isn't a tricky one but I thought it was good to test on, especially since terraform state commands are listed in Objective 4 of the exam. In this case, Jeff should NOT have removed the resource from the state file, but rather remove it from the configuration file and run a terraform plan/apply. In this scenario, Terraform would recognize that the virtual machine was no longer needed and would have destroyed it. https://www.terraform.io/docs/commands/state/list.html

Answer 120

data processing Explanation The syntax of a conditional expression first names the condition. In this example, if var.name is not (!=) empty, assign the var.name value; else, assign the new random_id resource as the name value. Since var.name equals data_processing, then the value of Name will equal data_processing. https://www.terraform.io/docs/configuration/expressions/conditionals.html

Answer 121

terraform refresh Explanation If the state has drifted from the last time Terraform ran, refresh allows that drift to be detected. https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform

Answer 122

.tfvars file 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) https://www.terraform.io/docs/configuration/variables.html

Answer 123

A. Terraform makes infrastructure changes defined in your configuration. E. Terraform updates the state file with configuration changes made during the execution. Explanation The terraform apply command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a terraform plan execution plan. https://www.terraform.io/docs/commands/apply.html

Answer 124

- remote runs - VCS connection - private module registry Explanation Terraform Cloud offers many features, even in the free version, that organizations can quickly take advantage of. This is the best table that compares the features available in Terraform OSS vs. Terraform Cloud and Terraform Enterprise. https://www.datocms-assets.com/2885/1602500234-terraform-full-feature-pricing-tablev2-1.pdf

Answer 125

Terraform can simplify both management and orchestration of deploying large-scale, multi-cloud infrastructure A single Terraform configuration file can be used to manage multiple providers Terraform is cloud-agnostic but requires a specific provider for the cloud platform

Answer 126

- Aaron's configuration file can deploy applications in both AWS and GCP - the configuration file can deploy both QA and Staging infrastructure for applications - the state file can be stored in Azure but provision applications in AWS Explanation There are a ton of benefits of deploying with Terraform and the solution is very capable of managing deployments across multiple clouds. However, state is still required and cannot be disabled. https://www.terraform.io/intro/use-cases.html#multi-cloud-deployment

Answer 127

the directory was not initialized Explanation terraform validate requires an initialized working directory with any referenced plugins and modules installed. If you don't initiate the directory, you will get an error stating you need to run a terraform init https://www.terraform.io/docs/commands/validate.html

Answer 128

- supports versioning to maintain compatibility - supports modules stored locally or remotely - enables code reuse Explanation All of these are examples of the benefits of using Terraform modules "except where they can be stored". Modules can only be supported in certain sources found at the following link: https://www.terraform.io/docs/modules/sources.html

Answer 129

us-east-1 Explanation The resource above will be created in the default region of us-east-1, since the resource does signify an alternative provider configuration. If the resource needs to be created in one of the other declared regions, it should have looked like this, where "aws" signifies the provider name and "west" signifies the alias name as such .: resource "aws_instance" "vault" { provider = aws.west ami = data.aws_ami.amzlinux2.id instance_type = "t3.micro" key_name = "ec2_key" vpc_security_group_ids = var.vault_sg subnet_id = var.vault_subnet user_data = file("vault.sh") ``` tags = { Name = "vault" } } https://www.terraform.io/docs/configuration/providers.html#selecting-alternate-provider-configurations ```

Answer 130

update all previously installed plugins to the newest version that complies with the configuration's version constraints Explanation The -upgrade will upgrade all previously-selected plugins to the newest version that complies with the configuration's version constraints. This will cause Terraform to ignore any selections recorded in the dependency lock file, and to take the newest available version matching the configured version constraints. https://www.terraform.io/docs/commands/init.html#upgrade-1

Answer 131

locally on the instance running Terraform ``` Explanation A local path must begin with either ./ or ../ to indicate that a local path is intended, to distinguish from a module registry address. ``` https://www.terraform.io/docs/modules/sources.html#terraform-registry

Answer 132

using environment variables Explanation The only method list above that will not result in the username/password being written to the state file is environment variables. All of the other options will result in the provider's credentials in the state file. Terraform runs will receive the full text of sensitive variables, and might print the value in logs and state files if the configuration pipes the value through to an output or a resource parameter. Additionally, Sentinel mocks downloaded from runs will contain the sensitive values of Terraform (but not environment) variables. Take care when writing your configurations to avoid unnecessary credential disclosure. Whenever possible, use environment variables since these cannot end up in state files or in Sentinel mocks. (Environment variables can end up in log files if TF_LOG is set to TRACE.) https: //www.terraform.io/docs/cloud/workspaces/variables.html#sensitive-values https: //learn.hashicorp.com/tutorials/terraform/sensitive-variables

Answer 133

Terraform would use the existing module already downloaded ``` Explanation When using modules installed from a module registry, HashiCorp recommends explicitly constraining the acceptable version numbers to avoid unexpected or unwanted changes. The version argument accepts a version constraint string. Terraform will use the newest installed version of the module that meets the constraint; if no acceptable versions are installed, it will download the newest version that meets the constraint. ``` A version number that meets every applicable constraint is considered acceptable. Terraform consults version constraints to determine whether it has acceptable versions of itself, any required provider plugins, and any required modules. For plugins and modules, it will use the newest installed version that meets the applicable constraints. To test this, I ran a terraform init with the code as shown in the file: $ terraform init Initializing modules... Downloading hashicorp/consul/aws 0.0.5 for consul... - consul in .terraform\modules\consul - consul.consul_clients in .terraform\modules\consul\modules\consul-cluster - consul.consul_clients.iam_policies in .terraform\modules\consul\modules\consul-iam-policies - consul.consul_clients.security_group_rules in .terraform\modules\consul\modules\consul-security-group-rules - consul.consul_servers in .terraform\modules\consul\modules\consul-cluster - consul.consul_servers.iam_policies in .terraform\modules\consul\modules\consul-iam-policies - consul.consul_servers.security_group_rules in .terraform\modules\consul\modules\consul-security-group-rules Then I removed the constraint from the configuration file and ran a terraform init again: $ terraform init Initializing modules... Initializing the backend... Initializing provider plugins... - Reusing previous version of hashicorp/aws from the dependency lock file - Reusing previous version of hashicorp/template from the dependency lock file Terraform did not download a newer version of the module. It reused the existing one. https: //www.terraform.io/docs/configuration/blocks/modules/syntax.html#version https: //www.terraform.io/docs/language/expressions/version-constraints.html

Answer 134

False Explanation The ultimate goal of a terraform plan is to compare the configuration file against the current state file and read any outputs related to the current figuration. While a terraform plan does perform a terraform refresh by default, the terraform plan does not actually result in changes to the state file. For additional information, check out this Q&A discussion that I had with another student. https://www.terraform.io/docs/commands/plan.html

Answer 135

3 Explanation The code above will create three subnets. The value of count is determined by the number of strings included in the private_subnet_names variable. https://www.terraform.io/docs/configuration/functions/length.html

Answer 136

Terraform provider Explanation Terraform relies on plugins called "providers" to interact with remote systems. Terraform configurations must declare which providers they require so that Terraform can install and use them. Additionally, some providers require configuration (like endpoint URLs or cloud regions) before they can be used. https://www.terraform.io/docs/configuration/blocks/providers/index.html

Answer 137

- terraform workspace select - terraform show - terraform taint - terraform login - terraform fmt Explanation terraform delete and terraform initialize are not valid Terraform CLI commands. Correct Answers: The terraform taint command manually marks a Terraform-managed resource as tainted, forcing it to be destroyed and recreated on the next apply. The terraform fmt command is used to rewrite Terraform configuration files to a canonical format and style. The terraform workspace select command is used to choose a different workspace to use for further operations. The terraform show command is used to provide human-readable output from a state or plan file. This can be used to inspect a plan to ensure that the planned operations are expected, or to inspect the current state as Terraform sees it. The terraform login command can be used to automatically obtain and save an API token for Terraform Cloud, Terraform Enterprise, or any other host that offers Terraform services. https://www.terraform.io/docs/commands/fmt.html

Answer 138

False Explanation Although main.tf is the standard name, it's not necessarily required. Terraform will look for any file with a .tf or .tf.json extension when running terraform commands. https://www.terraform.io/docs/configuration/index.html#code-organization

Answer 139

reduces the number of outbound traffic by requiring state is stored locally

Answer 140

there is no Terraform state in the current workspace she is working in Explanation Workspaces isolate their state, so if Pam runs a terraform destroy, Terraform will not see any existing state for this configuration. Pam may use the command terraform workspace select to choose the original workspace where the Azure resources were provisioned in order to properly destroy them in Azure. https://www.terraform.io/docs/cli/workspaces/index.html

Answer 141

the resources that were successfully provisioned will remain as deployed. Explanation During a terraform apply, any resources that are successfully provisioned are maintained as deployed. On the other hand, resources that failed during the provisioning process, such as a provisioned, will be tainted to be recreated during the next run. https://www.terraform.io/docs/provisioners/index.html#creation-time-provisioners

Answer 142

the AMI ID for the latest version of the Amazon Linux 2 image Explanation Within the block body (between { and }) are query constraints defined by the data source. Most arguments in this section depend on the data source, and indeed in this example most_recent, owners and tags are all arguments defined specifically for the aws_ami data source. https://www.terraform.io/docs/configuration/data-sources.html#using-data-sources

Answer 143

private module registry Explanation HashiCorp Terraform Enterprise and Cloud offerings deliver a private version of the Module Registry. This allows organizations to safely share private modules with their internal teams. https://www.terraform.io/docs/cloud/registry/index.html

Answer 144

- if the backend does not support locking, the state file could become corrupted - if the backend supports locking, the first terraform apply will lock the file for changes, preventing the second user from running the apply Explanation If the state is configured for remote state, the backend selected will determine what happens. If the backend supports locking, the file will be locked for the first user, and that user's configuration will be applied. The second user's terraform apply will return an error that the state is locked. If the remote backend does not support locking, the state file could become corrupted, since multiple users are trying to make changes at the same time. https://www.terraform.io/docs/state/locking.html

Answer 145

idempotent predictable consistent repeatable Explanation IaC makes changes idempotent, consistent, repeatable, and predictable. Without IaC, scaling up infrastructure to meet increased demand may require an operator to remotely connect to each machine and then manually provision and configure many servers by executing a series of commands/scripts. They might open multiple sessions and move between screens, which often results in skipped steps or slight variations between how work is completed, necessitating rollbacks. Perhaps a command was run incorrectly on one instance and reverted before being re-run correctly. https://www.hashicorp.com/blog/infrastructure-as-code-in-a-private-or-public-cloud

Answer 146

public Terraform registry Explanation Modules on the public Terraform Registry can be referenced using a registry source address of the form //, with each module's information page on the registry site including the exact address to use. https://www.terraform.io/docs/modules/sources.html#terraform-registry

Answer 147

True Explanation Any values that are retrieved in a data block or referenced as variables will show up in the state file. https://www.terraform.io/docs/state/sensitive-data.html

Answer 148

False Explanation This is false. If you don't provide a backend configuration, Terraform will use the local default backend. Remote Backends are completely optional. You can successfully use Terraform without ever having to learn or use a remote backend. However, they do solve pain points that afflict teams at a certain scale. If you're an individual, you can likely get away with never using backends. https://www.terraform.io/docs/backends

Answer 149

Terraform will destroy all of the resources Explanation In this case, since there is a state file with resources, Terraform will match the desired state of no resources since the configuration file doesn't include any resources. Therefore, all resources defined in the state file will be destroyed. https://www.terraform.io/docs/state/purpose.html

Answer 150

- Terraform Cloud maintains the state version and run history for each workspace - Terraform Cloud manages infrastructure collections with a workspace whereas CLI manages collections of infrastructure resources with a persistent working directory- - CLI workspaces are alternative state files in the same working directory

Answer 151

- multiple provider blocks using an 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. ``` https://www.terraform.io/docs/configuration/providers.html#alias-multiple-provider-configurations

Answer 152

Terraform Cloud - Business Terraform Enterprise (self-hosted) Terraform Cloud - Team & Governance Terraform Cloud - Free Explanation The Private Module Registry is available in all versions of Terraform except for Open Source. https://www.datocms-assets.com/2885/1602500234-terraform-full-feature-pricing-tablev2-1.pdf

Answer 153

True Explanation Validation requires an initialized working directory with any referenced plugins and modules installed. If the directory is NOT initialized, it will result in an error. $ terraform validate Error: Could not load plugin Plugin reinitialization required. Please run "terraform init". Plugins are external binaries that Terraform uses to access and manipulate resources. The configuration provided requires plugins which can't be located, don't satisfy the version constraints, or are otherwise incompatible. Terraform automatically discovers provider requirements from your configuration, including providers used in child modules. To see the requirements and constraints, run "terraform providers". Failed to instantiate provider "registry.terraform.io/hashicorp/aws" to obtain schema: unknown provider "registry.terraform.io/hashicorp/aws" https: //www.terraform.io/docs/commands/validate.html

Answer 154

Since there is no state file associated with this configuration file, the defined resources will be created on the VMware infrastructure. Explanation If there is no state file associated with a Terraform configuration file, a terraform apply will create the resources defined in the configuration file. This is a normal workflow during the first terraform apply that is executed against a configuration file. This, of course, assumes that the directory has been initialized using a terraform init https://www.terraform.io/docs/state/purpose.html

Answer 155

terraform fmt Explanation The terraform fmt command is used to rewrite Terraform configuration files to a canonical format and style. This command applies a subset of the Terraform language style conventions, along with other minor adjustments for readability. https://www.terraform.io/docs/commands/fmt.html

Answer 156

You write and execute the code to define, deploy, update, and destroy your infrastructure

Answer 157

a. Automation We can bring up the servers with one script and scale up and down based on our load with the same script. b. Reusability of the code We can reuse the same code c. Versioning We can check it into version control and we get versioning. Now we can see an incremental history of who changed what, how is our infrastructure actually defined at any given point of time, and we have this transparency of documentation IaC makes changes idempotent, consistent, repeatable, and predictable.

Answer 158

IaC makes it easy to provision and apply infrastructure configurations, saving time. It standardizes workflows across different infrastructure providers (e.g., VMware, AWS, Azure, GCP, etc.) by using a common syntax across all of them.

Answer 159

The idempotent characteristic provided by IaC tools ensures that, even if the same code is applied multiple times, the result remains the same.

Answer 160

IaC can be applied throughout the lifecycle, both on the initial build, as well as throughout the life of the infrastructure. Commonly, these are referred to as Day 0 and Day 1 activities. “Day 0” code provisions and configures your initial infrastructure. (initial build) “Day 1” refers to OS and application configurations you apply after you’ve initially built your infrastructure. (OS/App)

Answer 161

``` Heroku App Setup Multi-Tier Applications Self-Service Clusters Software Demos Disposable Environments Software Defined Networking Resource Schedulers Multi-Cloud Deployment https://www.terraform.io/intro/use-cases.html ```

Answer 162

Platform Agnostic State Management Operator Confidence https://learn.hashicorp.com/terraform/getting-started/intro

Answer 163

Configuration files ends with *.tf

Answer 164

- Terraform builds a graph of all your resources, - Parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.

Answer 165

Provisoning your infrastrcutire into multiple cloud providers to increase the fault-tolerance of your applications.

Answer 166

By using only a single region or cloud provider, fault tolerance is limited by the availability of that provider. Having a multi-cloud deployment allows for more graceful recovery of the loss of a region or entire provider.

Answer 167

cloud-agnostic and allows a single configuration to be used to manage multiple providers, and to even handle cross-cloud dependencies.

Answer 168

It simplifies management and orchestration, helping operators build large-scale multi-cloud infrastructures.

Answer 169

Every time you run Terraform, it records information about what infrastructure it created in a Terraform state file. By default, when you run Terraform in the folder /some/folder, Terraform creates the file /some/folder/terraform.tfstate This file contains a custom JSON format that records a mapping from the Terraform resources in your configuration files to the representation of those resources in the real world.

Answer 170

terraform plan | terraform apply

Answer 171

- Terraform makes any infrastructure changes defined in your configuration - Terraform updates the state file with any configuration changes it made

Answer 172

-h -help --help --h terraform plan -h terraform plan --h terraform plan -help terraform -h plan pan -h plan --h

Answer 173

Providers downloaded by terraform init are only installed for the current working directory; other working directories can have their own installed provider versions. Note that terraform init cannot automatically download providers that are not distributed by HashiCorp. See Third-party Plugins below for installation instructions.

Answer 174

To constrain the provider version as suggested, add a required_providers block inside a terraform block: ``` terraform { required_providers { aws = "~> 1.0" } } ```

Answer 175

terraform init -upgrade It upgrade to the latest acceptable version of each provider This command also upgrades to the latest versions of all Terraform modules.

Answer 176

``` 1. With required_providers blocks under terraform block terraform { required_providers { aws = "~> 1.0" } } ``` 2. Provider version constraints can also be specified using a version argument within a provider block provider { version= "1.0" }

Answer 177

``` alias You can optionally define multiple configurations for the same provider, and select which one to use on a per-resource or per-module basis. ```

Answer 178

Some of the example scenarios: a. multiple regions for a cloud platform b. targeting multiple Docker hosts c. multiple Consul hosts, etc.

Answer 179

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. ``` # 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" } ```

Answer 180

By default, resources use a default provider configuration inferred from the first word of the resource type name. For example, a resource of type aws_instance uses the default (un-aliased) aws provider configuration unless otherwise stated. resource "aws_instance" "foo" { provider = aws.west ``` # ... } ```

Answer 181

Windows %APPDATA%\terraform.d\plugins | All other systems ~/.terraform.d/plugins

Answer 182

True Install third-party providers by placing their plugin executables in the user plugins directory. The user plugins directory is in one of the following locations, depending on the host operating system Once a plugin is installed, terraform init can initialize it normally. You must run this command from the directory where the configuration files are located.

Answer 183

terraform-provider-_vX.Y.Z

Answer 184

The CLI configuration file configures per-user settings for CLI behaviors, which apply across all Terraform working directories. It is named either .terraformrc or terraform.rc

Answer 185

On Windows, the file must be named named terraform.rc and placed in the relevant user's %APPDATA% directory. On all other systems, the file must be named .terraformrc (note the leading period) and placed directly in the home directory of the relevant user. The location of the Terraform CLI configuration file can also be specified using the TF_CLI_CONFIG_FILE environment variable.

Answer 186

To enable the plugin cache, use the plugin_cache_dir setting in the CLI configuration file. plugin_cache_dir = "$HOME/.terraform.d/plugin-cache" Alternatively, the TF_PLUGIN_CACHE_DIR environment variable can be used to enable caching or to override an existing cache directory within a particular shell session: export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"

Answer 187

User Terraform will never itself delete a plugin from the plugin cache once it's been placed there. Over time, as plugins are upgraded, the cache directory may grow to contain several unused versions which must be manually deleted.

Answer 188

``` When you create a new configuration — or check out an existing configuration from version control — you need to initialize the directory // Example provider "aws" { profile = "default" region = "us-east-1" } ``` ``` resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" } Initializing a configuration directory downloads and installs providers used in the configuration, which in this case is the aws provider. Subsequent commands will use local settings and data during initialization. ```

Answer 189

terraform init

Answer 190

terraform fmt | This command automatically updates configurations in the current directory for easy readability and consistency.

Answer 191

terraform validate This command will check and report errors within modules, attribute names, and value types. Validate your configuration. If your configuration is valid, Terraform will return a success message.

Answer 192

terraform apply

Answer 193

terraform plan

Answer 194

terraform show When you applied your configuration, Terraform wrote data into a file called terraform.tfstate. This file now contains the IDs and properties of the resources Terraform created so that it can manage or destroy those resources going forward.

Answer 195

terraform state list | https://learn.hashicorp.com/terraform/getting-started/build#manually-managing-state

Answer 196

Defining additional features as plugins to your core platform or core application. This provides extensibility, flexibility and isolation

Answer 197

If you need to do some initial setup on your instances, then provisioners let you upload files, run shell scripts, or install and trigger other software like configuration management tools, etc.

Answer 198

resource "aws_instance" "example" { ami = "ami-b374d5a5" instance_type = "t2.micro" provisioner "local-exec" { command = "echo hello > hello.txt" } } Provisioner block within the resource block. Multiple provisioner blocks can be added to define multiple provisioning steps. Terraform supports multiple provisioners https://learn.hashicorp.com/terraform/getting-started/provision

Answer 199

local-exec | remote-exec

Answer 200

The local-exec provisioner executing command locally on your machine running Terraform. We use this when we need to do something on our local machine without needing any external URL

Answer 201

Another useful provisioner is remote-exec which invokes a script on a remote resource after it is created. This can be used to run a configuration management tool, bootstrap into a cluster, etc.

Answer 202

Provisioners are only run when a resource is created or destroyed. Provisioners that are run while destroying are Destroy provisioners. They are not a replacement for configuration management and changing the software of an already-running server, and are instead just meant as a way to bootstrap a server.

Answer 203

In order to use a remote-exec provisioner, you must choose an "ssh or winrm" connection in the form of a "connection block" within the provisioner. ``` Here is an example provider "aws" { profile = "default" region = "us-west-2" } resource "aws_key_pair" "example" { key_name = "examplekey" public_key = file("~/.ssh/terraform.pub") } resource "aws_instance" "example" { key_name = aws_key_pair.example.key_name ami = "ami-04590e7389a6e577c" instance_type = "t2.micro" connection { type = "ssh" user = "ec2-user" private_key = file("~/.ssh/terraform") host = self.public_ip } provisioner "remote-exec" { inline = [ "sudo amazon-linux-extras enable nginx1.12", "sudo yum -y install nginx", "sudo systemctl start nginx" ] } } ```

Answer 204

If a resource successfully creates but fails during provisioning, Terraform will error and mark the resource as "tainted". A resource that is tainted has been physically created, but can't be considered safe to use since provisioning failed.

Answer 205

When you generate your next execution plan, Terraform will not attempt to restart provisioning on the same resource because it isn't guaranteed to be safe. Instead, Terraform will remove any tainted resources and create new resources, attempting to provision them again after creation. https://learn.hashicorp.com/terraform/getting-started/provision

Answer 206

Terraform also does not automatically roll back and destroy the resource during the apply when the failure happens because that would go against the execution plan: the execution plan would've said a resource will be created but does not say it will ever be deleted. If you create an execution plan with a tainted resource, however, the plan will clearly state that the resource will be destroyed because it is tainted. https://learn.hashicorp.com/terraform/getting-started/provision

Answer 207

terraform taint resource.id

Answer 208

terraform taint resource.id This command will not modify infrastructure Modifies the state file in order to mark a resource as tainted. Once a resource is marked as tainted, the next plan will show that the resource will be destroyed and recreated and the next apply will implement this change.

Answer 209

The on_failure setting can be used to change this. The allowed values are: continue: Ignore the error and continue with creation or destruction. fial: Raise an error and stop applying (the default behavior). If this is a creation provisioner, taint the resource. ``` // Example resource "aws_instance" "web" { # ... ``` ``` provisioner "local-exec" { command = "echo The server's IP address is ${self.private_ip}" on_failure = "continue" } } ```

Answer 210

You can define destroy provisioner with the parameter when provisioner "remote-exec" { when = "destroy" # }

Answer 211

No You also need to export the variable TF_LOG and set it to one of the log levels.

Answer 212

``` The required_providers setting is a map specifying a version constraint for each provider required by your configuration. terraform { required_providers { aws = ">= 2.7.0" } } ```

Answer 213

``` ~> terraform { required_providers { aws = "~> 2.7.0" } } ```

Answer 214

In releases where experimental features are available, you can enable them on a per-module basis by setting the experiments argument inside a terraform block: terraform { experiments = [example] }

Answer 215

- Passing data into virtual machines and other compute resources - Running configuration management software https: //www.terraform.io/docs/provisioners/#passing-data-into-virtual-machines-and-other-compute-resources https: //www.terraform.io/docs/provisioners/#running-configuration-management-software

Answer 216

True The self object represents the provisioner's parent resource, and has all of that resource's attributes. For example, use self.public_ip to reference an aws_instance's public_ip attribute.

Answer 217

Any version more than 1.0 and less than 2.0

Answer 218

The required_version setting can be used to constrain which versions of the Terraform CLI can be used with your configuration. If the running version of Terraform doesn't match the constraints specified, Terraform will produce an error and exit without taking any further actions.

Answer 219

False HashiCorp recommends that you never hard-code credentials into *.tf configuration files. We are explicitly defining the default AWS config profile here to illustrate how Terraform should access sensitive credentials. If you leave out your AWS credentials, Terraform will automatically search for saved API credentials (for example, in ~/.aws/credentials) or IAM instance profile credentials. This is cleaner when .tf files are checked into source control or if there is more than one admin user

Answer 220

You can taint the resource and the next apply will destroy the resource terraform taint

Answer 221

The terraform fmt command is used to rewrite Terraform configuration files to a canonical format and style. This command applies a subset of the Terraform language style conventions, along with other minor adjustments for readability.

Answer 222

The canonical format may change in minor ways between Terraform versions, so after upgrading Terraform we recommend to proactively run terraform fmt on your modules along with any other changes you are making to adopt the new version.

Answer 223

terraform fmt [options] [DIR]

Answer 224

True By default, fmt scans the current directory for configuration files. If the dir argument is provided then it will scan that given directory instead. If dir is a single dash (-) then fmt will read from standard input (STDIN).

Answer 225

terraform fmt -diff

Answer 226

terraform fmt -recursive

Answer 227

terraform fmt -list=false

Answer 228

The terraform taint command manually marks a Terraform-managed resource as tainted, forcing it to be destroyed and recreated on the next apply. This command will not modify infrastructure, but does modify the state file in order to mark a resource as tainted. Once a resource is marked as tainted, the next plan will show that the resource will be destroyed and recreated and the next apply will implement this change.

Answer 229

terraform taint [options] address The address argument is the address of the resource to mark as tainted. The address is in the resource address syntax syntax

Answer 230

terraform taint -state=/path

Answer 231

``` terraform taint aws_security_group.allow_all The resource aws_security_group.allow_all in the module root has been marked as tainted. ```

Answer 232

terraform taint "module.couchbase.aws_instance.cb_node[9]" | Resource instance module.couchbase.aws_instance.cb_node[9] has been marked as tainted.

Answer 233

The terraform import command is used to import existing resources into Terraform. Terraform is able to import existing infrastructure. This allows you take resources you've created by some other means and bring it under Terraform management. This is a great way to slowly transition infrastructure to Terraform, or to be able to be confident that you can use Terraform in the future if it potentially doesn't support every feature you need today.

Answer 234

terraform import [options] ADDRESS ID

Answer 235

Each Terraform configuration has an associated backend that defines how operations are executed and where persistent data such as the Terraform state are stored. The persistent data stored in the backend belongs to a workspace. Initially, the backend has only one workspace, called "default", and thus there is only one Terraform state associated with that configuration. Certain backends support multiple named workspaces, allowing multiple states to be associated with a single configuration.

Answer 236

terraform workspace list

Answer 237

terraform workspace new

Answer 238

terraform workspace show

Answer 239

terraform workspace select

Answer 240

terraform workspace delete

Answer 241

No. You can't ever delete the default workspace

Answer 242

resource "aws_instance" "example" { count = "${terraform.workspace == "default" ? 5 : 1}" ``` # ... other arguments } ```

Answer 243

resource "aws_instance" "example" { tags = { Name = "web - ${terraform.workspace}" } ``` # ... other arguments } ```

Answer 244

Workspaces

Answer 245

The terraform state command is used for advanced state management. As your Terraform usage becomes more advanced, there are some cases where you may need to modify the Terraform state. Rather than modify the state directly, the terraform state commands can be used in many cases instead. https://www.terraform.io/docs/commands/state/index.html

Answer 246

terraform state [options] [args]

Answer 247

terraform state list

Answer 248

terraform state list

Answer 249

terraform state show 'resource name'

Answer 250

Terraform has detailed logs which can be enabled by setting the TF_LOG environment variable to any value. This will cause detailed logs to appear on stderr. You can set TF_LOG to one of the log levels TRACE, DEBUG, INFO, WARN or ERROR to change the verbosity of the logs. TRACE is the most verbose and it is the default if TF_LOG is set to something other than a log level name. To persist logged output you can set TF_LOG_PATH in order to force the log to always be appended to a specific file when logging is enabled. Note that even when TF_LOG_PATH is set, TF_LOG must be set in order for any logging to be enabled. https://www.terraform.io/docs/internals/debugging.html

Answer 251

"crash.log" If Terraform ever crashes (a "panic" in the Go runtime), it saves a log file with the debug logs from the session as well as the panic message and backtrace to crash.log. https://www.terraform.io/docs/internals/debugging.html

Answer 252

panic message The most interesting part of a crash log is the panic message itself and the backtrace immediately following. So the first thing to do is to search the file for panic https://www.terraform.io/docs/internals/debugging.html

Answer 253

There are two primary methods to separate state between environments: - directories - workspaces

Answer 254

"Directory separated" environments rely on "duplicate Terraform code", which may be useful if your deployments need to differ, for example, to test infrastructure changes in development. But they can run the risk of creating drift between the environments over time. (UAT Testing) "Workspace-separated" environments use the same Terraform code but have "different state files", which is useful if you want your environments to stay as similar to each other as possible, for example, if you are providing development infrastructure to a team that wants to simulate running in production. (Promoting an environment)

Answer 255

terraform state pull This command will download the state from its current location and output the raw format to stdout. https://www.terraform.io/docs/commands/state/pull.html

Answer 256

terraform state push The terraform state push command is used to manually upload a local state file to remote state. This command also works with local state. https://www.terraform.io/docs/commands/state/push.html

Answer 257

True This command will not modify infrastructure, but does modify the state file in order to mark a resource as tainted. Once a resource is marked as tainted, the next plan will show that the resource will be destroyed and recreated and the next apply will implement this change.

Answer 258

You should use terraform import and modify the infrastructure in the terraform files and do the terraform workflow (init, plan, apply)

Answer 259

${terraform.workspace}

Answer 260

terraform.tfstate.d | For local state, Terraform stores the workspace states in a directory called terraform.tfstate.d.

Answer 261

For remote state, the workspaces are stored directly in the configured backend.

Answer 262

terraform state rm 'packet_device.worker' The terraform state rm command is used to remove items from the Terraform state. This command can remove single resources, single instances of a resource, entire modules, and more. https://www.terraform.io/docs/commands/state/rm.html

Answer 263

terraform state mv 'module.app' 'module.parent.module.app' The terraform state mv command is used to move items in a Terraform state. This command can move single resources, single instances of a resource, entire modules, and more. This command can also move items to a completely different state file, enabling efficient refactoring. https://www.terraform.io/docs/commands/state/mv.html

Answer 264

terraform state mv 'packet_device.worker' 'packet_device.helper' The above example renames the packet_device resource named worker to helper:

Answer 265

``` The "Terraform Registry" makes it simple to find and use modules. The search query will look at module name, provider, and description to match your search terms. On the results page, filters can be used to further refine search results. ```

Answer 266

By default, only verified modules are shown in search results. Verified modules are reviewed by HashiCorp to ensure stability and compatibility. By using the filters, you can view unverified modules as well.

Answer 267

``` You need to add any module in the configuration file like below module "consul" { source = "hashicorp/consul/aws" version = "0.1.0" } ``` terraform init command will download and cache any modules referenced by a configuration.

Answer 268

``` // // for example module "consul" { source = "hashicorp/consul/aws" version = "0.1.0" } ```

Answer 269

``` /// // for example module "vpc" { source = "app.terraform.io/example_corp/vpc/aws" version = "0.9.3" } ```

Answer 270

A Terraform module is a set of Terraform configuration files in a single directory. Even a simple configuration consisting of a single directory with: "one or more .tf files is a module."

Answer 271

* Organize configuration * Encapsulate configuration * Re-use configuration * Provide consistency and ensure best practices https: //learn.hashicorp.com/terraform/modules/modules-overview

Answer 272

``` Your configuration can use "module blocks" to call modules in other directories. When Terraform encounters a module block, it loads and processes that module's configuration files. ```

Answer 273

- Local - Remote ``` Modules can either be loaded from the local filesystem or from a remote source. Terraform supports a variety of remote sources, including the Terraform Registry, most version control systems, HTTP URLs, and Terraform Cloud or Terraform Enterprise private module registries. ```

Answer 274

1. Start writing your configuration with modules in mind. Even for modestly complex Terraform configurations managed by a single person, you'll find the benefits of using modules outweigh the time it takes to use them properly. 2. Use local modules to organize and encapsulate your code. Even if you aren't using or publishing remote modules, organizing your configuration in terms of modules from the beginning will significantly reduce the burden of maintaining and updating your configuration as your infrastructure grows in complexity. 3. Use the public Terraform Registry to find useful modules. This way you can more quickly and confidently implement your configuration by relying on the work of others to implement common infrastructure scenarios. 4. Publish and share modules with your team. Most infrastructure is managed by a team of people, and modules are important way that teams can work together to create and maintain infrastructure. As mentioned earlier, you can publish modules either publicly or privately. We will see how to do this in a future guide in this series. https: //learn.hashicorp.com/terraform/modules/modules-overview#module-best-practices

Answer 275

``` Local paths Terraform Registry GitHub Generic Git, Mercurial repositories Bitbucket HTTP URLs S3 buckets GCS buckets https://www.terraform.io/docs/modules/sources.html ```

Answer 276

``` source and version // example module "consul" { source = "hashicorp/consul/aws" version = "0.1.0" } ```

Answer 277

``` The configuration that calls a module is responsible for setting its input values, which are passed as arguments in the module block. Aside from source and version, most of the arguments to a module block will set variable values. On the Terraform registry page for the AWS VPC module, you will see an Inputs tab that describes all of the input variables that module supports. ``` For example, we have defined a lot of input variables for the modules such as ads, cidr, name, etc provider "aws" { region = "us-west-2" } module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "2.21.0" name = var.vpc_name cidr = var.vpc_cidr azs = var.vpc_azs private_subnets = var.vpc_private_subnets public_subnets = var.vpc_public_subnets enable_nat_gateway = var.vpc_enable_nat_gateway tags = var.vpc_tags } module "ec2_instances" { source = "terraform-aws-modules/ec2-instance/aws" version = "2.12.0" name = "my-ec2-cluster" instance_count = 2 ami = "ami-0c5204531f799e0c6" instance_type = "t2.micro" vpc_security_group_ids = [module.vpc.default_security_group_id] subnet_id = module.vpc.public_subnets[0] ``` tags = { Terraform = "true" Environment = "dev" } } ```

Answer 278

You can access them by referring | module..

Answer 279

Module outputs are usually either passed to other parts of your configuration or defined as outputs in your root module. You will see both uses in this guide. Inside your configuration's directory, outputs.tf will need to contain: output "vpc_public_subnets" { description = "IDs of the VPC's public subnets" value = module.vpc.public_subnets } output "ec2_instance_public_ips" { description = "Public IP addresses of EC2 instances" value = module.ec2_instances.public_ip }

Answer 280

``` You can define variables.tf in the root folder variable "vpc_name" { description = "Name of VPC" type = string default = "example-vpc" } ``` Then you can access these varibles in the configuration like this module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "2.21.0" name = var.vpc_name cidr = var.vpc_cidr azs = var.vpc_azs private_subnets = var.vpc_private_subnets public_subnets = var.vpc_public_subnets enable_nat_gateway = var.vpc_enable_nat_gateway tags = var.vpc_tags }

Answer 281

A module that is called by another configuration is sometimes referred to as a "child module" of that configuration.

Answer 282

When installing a local module, Terraform will instead refer directly to the source directory. Because of this, Terraform will automatically notice changes to local modules without having to re-run terraform init or terraform get.

Answer 283

When installing a remote module, Terraform will download it into the .terraform directory in your configuration's root directory. You should initialize with terraform init

Answer 284

``` .terraform/modules // Example .terraform/modules ├── ec2_instances │ └── terraform-aws-modules-terraform-aws-ec2-instance-ed6dcd9 ├── modules.json └── vpc └── terraform-aws-modules-terraform-aws-vpc-2417f60 ```

Answer 285

"source" All modules require a source argument, which is a meta-argument defined by Terraform CLI. Its value is either the path to a local directory of the module's configuration files, or a remote module source that Terraform should download and use. This value must be a literal string with no template sequences; arbitrary expressions are not allowed. For more information on possible values for this argument, see Module Sources.

Answer 286

"version" - (Optional) A version constraint string that specifies which versions of the referenced module are acceptable. The newest version matching the constraint will be used. version is supported only for modules retrieved from module registries. "providers" - (Optional) A map whose keys are provider configuration names that are expected by child module and whose values are corresponding provider names in the calling module. This allows provider configurations to be passed explicitly to child modules. If not specified, the child module inherits all of the default (un-aliased) provider configurations from the calling module.

Answer 287

The core Terraform workflow has three steps: 1. Write - Author infrastructure as code. 2. Plan - Preview changes before applying. 3. Apply - Provision reproducible infrastructure.

Answer 288

https://www.terraform.io/guides/core-workflow.html#working-as-an-individual-practitioner

Answer 289

https://www.terraform.io/guides/core-workflow.html#working-as-a-team

Answer 290

https://www.terraform.io/guides/core-workflow.html#the-core-workflow-enhanced-by-terraform-cloud

Answer 291

The terraform init command is used to initialize 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. It is safe to run this command multiple times.

Answer 292

terraform init This command performs several different initialization steps in order to prepare a working directory for use. This command is always safe to run multiple times, to bring the working directory up to date with changes in the configuration. Though subsequent runs may give errors, this command will never delete your existing configuration or state. If no arguments are given, the configuration in the current working directory is initialized. It is recommended to run Terraform with the current working directory set to the root directory of the configuration, and omit the DIR argument. https://www.terraform.io/docs/commands/init.html

Answer 293

upgrade | terraform init -upgrade

Answer 294

terraform init -get=false

Answer 295

On most operationg systems : ~/.terraform.d/plugins | on Windows : %APPDATA%\terraform.d\plugins

Answer 296

terraform init -get-plugins=false Skips plugin installation. Terraform will use plugins installed in the user plugins directory, and any plugins already installed for the current working directory. If the installed plugins aren't sufficient for the configuration, init fails.

Answer 297

The terraform validate command validates the configuration files in a directory, referring only to the configuration and not accessing any remote services such as remote state, provider APIs, etc. Validate runs checks that verify whether a configuration is syntactically valid and internally consistent, regardless of any provided variables or existing state. It is thus primarily useful for general verification of reusable modules, including the correctness of attribute names and value types. https://www.terraform.io/docs/commands/validate.html

Answer 298

The terraform plan command is used to create an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files.

Answer 299

The terraform apply command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a terraform plan execution plan. https://www.terraform.io/docs/commands/apply.html

Answer 300

terraform apply -auto-approve | https://www.terraform.io/docs/commands/apply.html

Answer 301

The terraform destroy command is used to destroy the Terraform-managed infrastructure.

Answer 302

terraform plan -destroy

Answer 303

"Implicit dependency:" By studying the resource attributes used in interpolation expressions, Terraform can automatically infer when one resource depends on another. Terraform uses this dependency information to determine the correct order in which to create the different resources. Implicit dependencies via interpolation expressions are the primary way to inform Terraform about these relationships and should be used whenever possible. "Explicit dependency:" Sometimes there are dependencies between resources that are not visible to Terraform. The **depends_on** argument is accepted by any resource and accepts a list of resources to create explicit dependencies for.

Answer 304

``` In the example below, the reference to aws_instance.example.id creates an implicit dependency on the aws_instance named example. provider "aws" { profile = "default" region = "us-east-1" } ``` ``` resource "aws_instance" "example" { ami = "ami-b374d5a5" instance_type = "t2.micro" } resource "aws_eip" "ip" { vpc = true instance = aws_instance.example.id } ```

Answer 305

``` In the example below, an application we will run on our EC2 instance expects to use a specific Amazon S3 bucket, but that dependency is configured inside the application code and thus not visible to Terraform. In that case, we can use depends_on to explicitly declare the dependency resource "aws_s3_bucket" "example" { bucket = "some_bucket" acl = "private" } resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" ``` depends_on = [aws_s3_bucket.example] }

Answer 306

terraform plan -out=tfplan you can use that file with apply terraform apply tfplan

Answer 307

terraform init -from-module=MODULE-SOURCE | https://www.terraform.io/docs/commands/init.html#copy-a-source-module

Answer 308

terraform plan -detailed-exitcode Return a detailed exit code when the command exits. When provided, this argument changes the exit codes and their meanings to provide more granular information about what the resulting plan contains: * 0 = Succeeded with empty diff (no changes) * 1 = Error * 2 = Succeeded with non-empty diff (changes present)

Answer 309

-target=resource - A Resource Address to target. This flag can be used multiple times. See below for more information.

Answer 310

terraform plan -refresh=true

Answer 311

resource "docker_image" "nginx" { name = "nginx:latest" keep_locally = false } ``` resource "docker_container" "nginx" { image = docker_image.nginx.latest name = "nginxtutorial" ports { internal = 80 external = 8080 } upload { source = "${abspath(path.root)}/files/index.html" file = "/usr/share/nginx/html/index.html" } } ``` Yes. Terraform creates the resource again since the execution plan says two resources and the terraform always maintains the desired state

Answer 312

It creates the instance again

Answer 313

resource "docker_image" "nginx" { name = "nginx:latest" keep_locally = false } ``` resource "docker_container" "nginx" { image = docker_image.nginx.latest name = "nginxtutorial" ports { internal = 80 external = 8080 } upload { source = "${abspath(path.root)}/files/index.html" file = "/usr/share/nginx/html/index.html" } } ``` ``` Terraform will perform the following actions: # docker_container.nginx will be created Plan: 1 to add, 0 to change, 0 to destroy. ```

Answer 314

A "backend" in Terraform determines how the state is loaded and how an operation such as apply is executed. This abstraction enables non-local file state storage, remote execution, etc. By default, Terraform uses the "local" backend, which is the normal behavior of Terraform

Answer 315

The local backend stores state on the local filesystem, locks that state using system APIs, and performs operations locally. ``` // Example terraform { backend "local" { path = "relative/path/to/terraform.tfstate" } } ```

Answer 316

This defaults to "terraform.tfstate" relative to the root module by default.

Answer 317

If supported by your backend, Terraform will lock your state for all operations that could write state. This prevents others from acquiring the lock and potentially corrupting your state. State locking happens automatically on all operations that could write state. You won't see any message that it is happening. If state locking fails, Terraform will not continue.

Answer 318

No. | If state locking fails, Terraform will not continue.

Answer 319

Yes. | You can disable state locking for most commands with the -lock flag but it is not recommended.

Answer 320

- Standard - Enhanced Backend Types Terraform's backends are divided into two main types, according to how they handle state and operations: Enhanced backends can both store state and perform operations. There are only two enhanced backends: local and remote. Standard backends only store state, and rely on the local backend for performing operations.

Answer 321

Remote backends allow Terraform to use a "shared storage space" for "state data", so any member of your team can use Terraform to manage the same infrastructure.

Answer 322

Remote state storage: - Makes collaboration easier - State and secret information off your local disk. - "loaded only in memory"

Answer 323

If you want to move back to local state, you can - "remove the backend configuration block from your configuration" - run terraform init again. Terraform will once again ask if you want to migrate your state back to local.

Answer 324

The "terraform refresh" command is used to reconcile the state Terraform knows about (via its state file) with the real-world infrastructure. This can be used to detect any "drift" from the last-known state, and to update the state file.

Answer 325

No: The command "terraform refresh" does not modify infrastructure but it does modify the state file. If the state is changed, this may cause changes to occur during the next plan or apply.

Answer 326

1. When configuring a backend for the first time (moving from no defined backend to explicitly configuring one), Terraform will give you the option to migrate your state to the new backend. This lets you adopt backends without losing any existing state. 2. To be extra careful, we always recommend manually backing up your state as well. You can do this by simply copying your terraform.tfstate file to another location.

Answer 327

You do not need to specify every required argument in the backend configuration. Omitting certain arguments may be desirable to avoid storing secrets, such as access keys, within the main configuration. "When some or all of the arguments are omitted, we call this a "partial" configuration."

Answer 328

"Interactively:" Terraform will interactively ask you for the required values unless interactive input is disabled. Terraform will not prompt for optional values. "File:" A configuration file may be specified via the init command line. To specify a file, use the "-backend-config=PATH" option when running terraform init. If the file contains secrets it may be kept in a secure data store, such as Vault, in which case it must be downloaded to the local disk before running Terraform. "Command-line key/value pairs:" Key/value pairs can be specified via the init command line. Note that many shells retain command-line flags in a history file, so this isn't recommended for secrets. To specify a single key/value pair, use the -backend-config="KEY=VALUE" option when running terraform init. https://www.terraform.io/docs/backends/config.html

Answer 329

When using partial configuration, Terraform requires at a minimum that an "empty backend" configuration is specified in one of the root Terraform configuration files, to specify the backend type ``` // Example terraform { backend "consul" {} } ```

Answer 330

terraform init \ - backend-config="address=demo.consul.io" \ - backend-config="path=example_app/terraform_state" \ - backend-config="scheme=https"

Answer 331

If you no longer want to use any backend, you can simply remove the configuration from the file. Terraform will detect this like any other change and prompt you to reinitialize. As part of the reinitialization, Terraform will ask if you'd like to migrate your state back down to a normal local state. Once this is complete then Terraform is back to behaving as it does by default.

Answer 332

Terraform Cloud always encrypts state at rest and protects it with TLS in transit. Terraform Cloud also knows the identity of the user requesting state and maintains a history of state changes. This can be used to control access and track activity. Terraform Enterprise also supports detailed audit logging. The S3 backend supports encryption at rest when the encrypt option is enabled. IAM policies and logging can be used to identify any invalid access. Requests for the state go over a TLS connection.

Answer 333

Backends are completely optional. You can successfully use Terraform without ever having to learn or use backends. However, they do solve pain points that afflict teams at a certain scale. If you're an individual, you can likely get away with never using backends.

Answer 334

"Working in a team:" Backends can store their state remotely and protect that state with locks to prevent corruption. Some backends such as Terraform Cloud even automatically store a history of all state revisions. "Keeping sensitive information off disk:" State is retrieved from backends on demand and only stored in memory. If you’re using a backend such as Amazon S3, the only location the state ever is persisted is in S3. "Remote operations:" For larger infrastructures or certain changes, terraform apply can take a long, long time. Some backends support remote operations which enable the operation to execute remotely. You can then turn off your computer and your operation will still complete. Paired with remote state storage and locking above, this also helps in team environments.

Answer 335

Terraform has a force-unlock command to manually unlock the state if unlocking failed. Be very careful with this command. If you unlock the state when someone else is holding the lock it could cause multiple writers. Force unlock should only be used to unlock your own lock in the situation where automatic unlocking failed. To protect you, the force-unlock command requires a unique lock ID. Terraform will output this lock ID if unlocking fails. This lock ID acts as a nonce, ensuring that locks and unlocks target the correct lock.

Answer 336

variable "region" { default = "us-east-1" } This defines the region variable within your Terraform configuration.

Answer 337

``` // accessing a variable provider "aws" { region = var.region } ```

Answer 338

``` (1) "Command-line flags" terraform apply -var 'region=us-east-1' From a file To persist variable values, create a file and assign variables within this file. Create a file named terraform.tfvars with the following contents: region = "us-east-1" terraform apply \ -var-file="secret.tfvars" \ -var-file="production.tfvars" ``` (2) "From environment varibles" Terraform will read environment variables in the form of TF_VAR_name to find the value for a variable. For example, the TF_VAR_region variable can be set in the shell to set the region variable in Terraform. (3) "UI input" If you execute terraform apply with any variable unspecified, Terraform will ask you to input the values "interactively". These values are not saved, but this provides a convenient workflow when getting started with Terraform. UI input is not recommended for everyday use of Terraform.

Answer 339

No Environment variables can only populate "string-type variables". List and map type variables must be populated via one of the other mechanisms.

Answer 340

``` You can use different varible files with the same configuration: // Example ``` ``` // For development terraform apply -var-file="dev.tfvars" ``` ``` // For test terraform apply -var-file="test.tfvars" ```

Answer 341

If no value is assigned to a variable via any of these methods and the variable has a default key in its declaration, that value will be used for the variable. variable "region" { default = "us-east-1" }

Answer 342

``` string number bool list() set() map() object({ = , ... }) tuple([, ...]) ```

Answer 343

``` Lists are defined either explicitly or implicitly. variable "availability_zone_names" { type = list(string) default = ["us-west-1a"] } ```

Answer 344

``` variable "region" {} variable "amis" { type = map(string) } amis = { "us-east-1" = "ami-abc123" "us-west-2" = "ami-def456" } // accessing resource "aws_instance" "example" { ami = var.amis[var.region] instance_type = "t2.micro" } ```

Answer 345

The above mechanisms for setting variables can be used together in any combination. If the same variable is assigned multiple values, Terraform uses the last value it finds, overriding any previous values. Note that the same variable cannot be assigned multiple values within a single source. Terraform loads variables in the following order, with later sources taking precedence over earlier ones: * Environment variables * The terraform.tfvars file, if present. * The terraform.tfvars.json file, if present. * Any *.auto.tfvars or *.auto.tfvars.json files, processed in lexical order of their filenames. * Any -var and -var-file options on the command line, in the order they are provided. (This includes variables set by a Terraform Cloud workspace.)

Answer 346

output variables as a way to organize data to be easily queried and shown back to the Terraform user. Outputs are a way to tell Terraform what data is important. This data is outputted when apply is called can be queried using the terraform output command.

Answer 347

output "ip" { value = aws_eip.ip.public_ip } Multiple output blocks can be defined to specify multiple output variables.

Answer 348

You will see the output when you run the following command terraform apply You can query the output with the following command terraform output ip

Answer 349

some resource types include repeatable nested blocks in their arguments, which do not accept expressions You can dynamically construct repeatable nested blocks like setting using a special dynamic block type, which is supported inside resource, data, provider, and provisioner blocks: A dynamic block acts much like a for expression but produces nested blocks instead of a complex typed value. It "iterates over a given complex value, and generates a nested block for each element of that complex value." https://www.terraform.io/docs/configuration/expressions.html#dynamic-blocks resource "aws_elastic_beanstalk_environment" "tfenvtest" { name = "tf-test-name" application = "${aws_elastic_beanstalk_application.tftest.name}" solution_stack_name = "64bit Amazon Linux 2018.03 v2.11.4 running Go 1.12.6" ``` dynamic "setting" { for_each = var.settings content { namespace = setting.value["namespace"] name = setting.value["name"] value = setting.value["value"] } } } ```

Answer 350

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.

Answer 351

The Terraform language includes a number of built-in functions that you can call from within expressions to transform and combine values. max(5, 12, 9)

Answer 352

No The Terraform language does not support user-defined functions, and so only the functions built into the language are available for use.

Answer 353

parseint parses the given string as a representation of an integer in the specified base and returns the resulting number. The base must be between 2 and 62 inclusive. > parseint("100", 10) 100 More Number Functions here https://www.terraform.io/docs/configuration/functions/abs.html

Answer 354

can condition = can(formatdate("", var.timestamp)) https://www.terraform.io/docs/configuration/functions/can.html

Answer 355

``` try locals { example = try( [tostring(var.example)], tolist(var.example), ) } ```

Answer 356

``` A Resource Address is a string that references a specific resource in a larger infrastructure. An address is made up of two parts: [module path][resource spec] ```

Answer 357

``` A module path addresses a module within the tree of modules. It takes the form: module.A.module.B.module.C... Multiple modules in a path indicate nesting. If a module path is specified without a resource spec, the address applies to every resource within the module. If the module path is omitted, this addresses the root module. ```

Answer 358

A resource spec addresses a specific resource in the config. It takes the form: resource_type.resource_name[resource index] * resource_type - Type of the resource being addressed. * resource_name - User-defined name of the resource. * [resource index] - an optional index into a resource with multiple instances, surrounded by square brace characters ([ and ]). // Examples resource "aws_instance" "web" { # ... count = 4 } aws_instance.web[3] // Refers to only last instance aws_instance.web // Refers to all four "web" instances. resource "aws_instance" "web" { # ... for_each = { "terraform": "value1", "resource": "value2", "indexing": "value3", "example": "value4", } } aws_instance.web["example"] // Refers to only the "example" instance in the config.

Answer 359

``` A complex type is a type that groups multiple values into a single value. There are two categories of complex types: collection types (for grouping similar values) * list(...): a sequence of values identified by consecutive whole numbers starting with zero. * map(...): a collection of values where each is identified by a string label. * set(...): a collection of unique values that do not have any secondary identifiers or ordering. structural types (for grouping potentially dissimilar values). * object(...): a collection of named attributes that each have their own type. * tuple(...): a sequence of elements identified by consecutive whole numbers starting with zero, where each element has its own type. ```

Answer 360

Terraform makes several kinds of named values available. Each of these names is an expression that references the associated value; you can use them as standalone expressions, or combine them with other expressions to compute new values. * . is an object representing a managed resource of the given type and name. The attributes of the resource can be accessed using dot or square bracket notation. * var. is the value of the input variable of the given name. * local. is the value of the local value of the given name. * module.. is the value of the specified output value from a child module called by the current module. * data.. is an object representing a data resource of the given data source type and name. If the resource has the count argument set, the value is a list of objects representing its instances. If the resource has the for_each argument set, the value is a map of objects representing its instances. * path.module is the filesystem path of the module where the expression is placed. * path.root is the filesystem path of the root module of the configuration. * path.cwd is the filesystem path of the current working directory. In normal use of Terraform this is the same as path.root, but some advanced uses of Terraform run it from a directory other than the root module directory, causing these paths to be different. * terraform.workspace is the name of the currently selected workspace.

Answer 361

filebase64(path) | https://www.terraform.io/docs/configuration/functions/filebase64.html

Answer 362

formatdate(spec, timestamp) | https://www.terraform.io/docs/configuration/functions/formatdate.html

Answer 363

jsonencode({"hello"="world"}) | https://www.terraform.io/docs/configuration/functions/jsonencode.html

Answer 364

> cidrhost("10.12.127.0/20", 16) 10. 12.112.16 https: //www.terraform.io/docs/configuration/functions/cidrhost.html

Answer 365

Sentinel is an embedded policy-as-code framework integrated with the HashiCorp Enterprise products. It enables fine-grained, logic-based policy decisions, and can be extended to use information from external sources.

Answer 366

- Codifying policy removes the need for ticketing queues , without sacrificing enforcement. One of the other benefits of Sentinel is that it also has a fullull testing framework. Avoiding a ticketing workflow allows organizations to provide more self-service capabilities and end-to-end automation, minimizing the friction for developers and operators. https://www.hashicorp.com/blog/why-policy-as-code/

Answer 367

Terraform Cloud's private module registry helps you share Terraform modules across your organization. It includes support for module versioning, a searchable and filterable list of available modules, and a configuration designer to help you build new workspaces faster.

Answer 368

The public registry: 3-part // format private modules: 4-part /// format ``` // example module "vpc" { source = "app.terraform.io/example_corp/vpc/aws" version = "1.0.4" } ```

Answer 369

https://registry.terraform.io/

Answer 370

A workspace contains everything Terraform needs to manage a given collection of infrastructure, and separate workspaces function like completely separate working directories.

Answer 371

https://www.hashicorp.com/resources/terraform-enterprise-understanding-workspaces-and-modules/

Answer 372

While the organization defined in the backend stanza must already exist,

Answer 373

Terraform Cloud will create it if necessary. If you opt to use a workspace that already exists, the workspace must not have any existing states.

Answer 374

If you are familiar with running Terraform using the CLI, you may have used Terraform workspaces. Terraform Cloud workspaces behave differently than Terraform CLI workspaces. Terraform CLI workspaces allow multiple state files to exist within a single directory, enabling you to use one configuration for multiple environments. Terraform Cloud workspaces contain everything needed to manage a given set of infrastructure and function like separate working directories.

Answer 375

Newer Versions: 1. terraform login 2. it will open the terraform cloud and generate the token 3. paste that token back in the CLI https://learn.hashicorp.com/terraform/tfc/tfc_login Older versions: keep the following token in the CLI configuration file credentials "app.terraform.io" { token = "xxxxxx.atlasv1.zzzzzzzzzzzzz" } https://www.terraform.io/docs/commands/cli-config.html#credentials

Answer 376

terraform init Once you have authenticated the remote backend, you're ready to migrate your local state file to Terraform Cloud. To begin the migration, reinitialize. This causes Terraform to recognize your changed backend configuration. During reinitialization, Terraform presents a prompt saying that it will copy the state file to the new backend. Enter "yes" and Terraform will migrate the state from your local machine to Terraform Cloud. https://learn.hashicorp.com/terraform/tfc/tfc_migration#migrate-the-state-file

Answer 377

``` You need to configure in the terraform block terraform { backend "remote" { hostname = "app.terraform.io" organization = "" ``` ``` workspaces { name = "state-migration" } } } ```

Answer 378

Terraform Cloud’s run triggers allow you to link workspaces so that a successful apply in a source workspace will queue a run in the workspace linked to it with a run trigger. For example, adding new subnets to your network configuration could trigger an update to your application configuration to rebalance servers across the new subnets.

Answer 379

When managing complex infrastructure with Terraform Cloud, organizing your configuration into different workspaces helps you to better manage and design your infrastructure. Configuring run triggers between workspaces allows you to set up infrastructure pipelines as part of your overall deployment strategy.

Answer 380

Terraform Cloud teams can have: - read - plan - write - admin Permissions on individual workspaces

Answer 381

"Organization owners" grant permissions by grouping users into teams and giving those teams privileges based on their need for access to individual workspaces.

Answer 382

You can add users to an organization by inviting them using their email addresses. Even if your team member has not signed up for Terraform Cloud yet, they can still accept the invitation and create a new account.

Answer 383

Yes. The Terraform Cloud Team plan is charged on a per-user basis so adding new users to your organization incurs cost.

Answer 384

- A built-in version control similar to GitHub Terraform does not have version control built-in.

Answer 385

Open-source Terraform workspaces can automatically back up your configuration to Terraform Cloud. Terraform does not automatically back up your configuration to Terraform Cloud. If you are running Terraform locally, it stores the configuration in the designated directory on your machine.

Answer 386

A repository of publicly available Terraform: 1) . providers 2) . modules

Answer 387

- Provides short-lived, temporary credentials for users with only the permissions needed for infrastructure creation. - Allows you to store sensitive data securely that can be used for your Terraform configurations. - A secure place to manage access to the secrets to your Terraform configurations, in addition to integrating with other popular cloud vendors.

Answer 388

- It helps teams use Terraform together. | - Easy access to shared state and secret data

Answer 389

- Publicly available Terraform providers | - Publicly available modules

Answer 390

- It can store your long-lived credentials in a secure way and dynamically inject short-lived, temporary keys to Terraform at deployment

Answer 391

A plugin that enables Terraform to interface with the API layer of various cloud platforms and environments

Answer 392

- They can be included in the command-line options. - They can be predetermined in a file - They can be pulled down from Terraform Cloud and referenced in your code

Answer 393

True terraform provisioners can help execute custom scripts and commands on resources. The best practice is to avoid using them if a built-in mechanism is provided by the resource API itself.

Answer 394

terraform.tfstate

Answer 395

- A child module can use outputs to expose a subset of its resource attributes to a parent module. - A root module can use outputs to print certain values in the CLI output after running terraform apply - When using remote state, root module outputs can be accessed by other configurations via a terraform_remote_state

Answer 396

- By default, Terraform looks for providers in the Terraform provider registry. - You can reference providers from an internal registry in your Terraform code - You can reference providers locally in your Terraform Configuration

Answer 397

Structural A structural variable type allows multiple values of various primitive types to be grouped together as a single value. In this case, the variable training has 2 separate types of values within it, namely a string and a number.

Answer 398

lifecycle blocks Dynamic blocks CANNOT be used with lifecycle blocks, as Terraform must process this type of block before it is safe to evaluate expressions.

Answer 399

True Per the definition, a collection type allows multiple values of one other type to be grouped together as a single value

Answer 400

Terraform comes pre-packaged with a number of built-in functions. Users cannot create their own functions like in a programming language

Answer 401

A method of writing human-readable code to deploy resources in the cloud and elsewhere. IaC is basically code that deploys your infrastructure resources onto various platforms instead of managing them manually through a user interface.

Answer 402

- Automate software-defined networks. - Interacts and takes care of the communication with control-layer APIs with ease. - Tracks state of each resource deployed

Answer 403

Presents a plan of the actions that will be taken during deployment for review prior to execution. The terraform plan command goes through the code and creates a plan of execution on which the apply command acts.

Answer 404

False The terraform init does in fact help configure and set up the backend which will store the state file.

Answer 405

In the terraform block, using the backend attribute.

Answer 406

It provides granular access, integrity, security, availability, collaboration.

Answer 407

It maps real-world resources to Terraform configuration/code. It's basically a map between real-world resource IDs and configurations to logical resources in your Terraform code.

Answer 408

The inclusion of list with the terraform state command will list all of the resources in the Terraform state.

Answer 409

resource "aws_iam_user" "cloud" { name = split(":",var.cloud_users)[count.index] count = length(split(":",var.cloud_users)) }

Answer 410

echo 'aws_iam_user.cloud[6].name' | terraform console

Answer 411

Use terraform console and check index(var.sf,"oni") OR to use a one liner: echo "index(var.sf,\"oni\")" | terraform console

Answer 412

set(string)

Answer 413

resource "aws_instance" "mario_servers" { ami = var.ami instance_type = var.name == "tiny" ? var.small : var.large tags = { Name = var.name } }

Answer 414

- Terraform can mange cross-cloud dependencies- Terraform can mange cross-cloud dependencies - Terraform simplifies management and orchestration, helping operators build large-scale, multi-cloud infrastructure - Terraform can help businesses deploy applications on multiple clouds and on-premises infrastructure

Answer 415

- Provide reusable modules for easy sharing and collaboration - Safely test modifications using a "dry run" before applying any actual changes - Easily change and update existing infrastructure - Easily integrate with application workflows (GitLab Actions, Azure DevOps, CI/CD tools)

Answer 416

- applies the change required in the target infrastructure in order to reach the desired configuration

Answer 417

- operations teams only need to learn and manage a single tool to manage infrastructure, regardless of where the infrastructure is deployed - can be used across major cloud providers and VM hypervisors Using a tool like Terraform can be advantageous for organizations deploying workloads across multiple public and private cloud environments. Operations teams only need to learn a single tool, a single language, and can use the same tooling to enable a DevOps-like experience and workflows. https://www.terraform.io/intro/use-cases.html#multi-cloud-deployment

Answer 418

- configure an output value in the application module in order to use that value for the DNS module Output values are like the return values of a Terraform module and have several uses such as a child module using those outputs to expose a subset of its resource attributes to a parent module. https://www.terraform.io/docs/configuration/expressions.html#references-to-named-values

Answer 419

- Traditional deployment methods are not able to meet the demands of the modern business where resources tend to live days to weeks, rather than months to years - Requests for infrastructure or hardware required a ticket, increasing the time required to deploy applications - Traditionally managed infrastructure can't keep up with the cyclic or elastic applications Explanation Businesses are making a transition where traditionally-managed infrastructure can no longer meet the demands of today's businesses. IT organizations are quickly adopting the public cloud, which is predominantly API-driven. To meet customer demands and save costs, application teams are architecting their applications to support a much higher level of elasticity, supporting technology like containers and public cloud resources. These resources may only live for a matter of hours; therefore the traditional method of raising a ticket to request resources is no longer a viable option Pointing and clicking in a management console is NOT scale and increases the change of human error. https://www.terraform.io/intro/index.html#infrastructure-as-code

Answer 420

Clustering - Clustering is the ONLY answer that is available ONLY in Terraform Enterprise. You can't cluster Terraform open-source, and the other options are hosted solutions. This makes clustering the only correct answer. Note that Clustering was available for Enterprise for a while, then HashiCorp removed it. As of January 15, 2021, it's back and you can read more about it at this link.

Answer 421

- consul - gcs - manta

Answer 422

terraform providers The terraform providers command shows information about the provider requirements of the configuration in the current working directory, as an aid to understanding where each requirement was detected from.

Answer 423

If you need to run provisioners that aren't directly associated with a specific resource, you can associate them with a null_resource. Instances of null_resource are treated like normal resources, but they don't do anything. Like with any other resource, you can configure provisioners and connection details on a null_resource. You can also use its triggers argument and any meta-arguments to control exactly where in the dependency graph its provisioners will run. Example usage resource "aws_instance" "cluster" { count = 3 ``` # ... } ``` ``` resource "null_resource" "cluster" { # Changes to any instance of the cluster requires re-provisioning triggers = { cluster_instance_ids = "${join(",", aws_instance.cluster.*.id)}" } ``` ``` # Bootstrap script can run on any instance of the cluster # So we just choose the first in this case connection { host = "${element(aws_instance.cluster.*.public_ip, 0)}" } ``` ``` provisioner "remote-exec" { # Bootstrap script called with private_ip of each node in the cluster inline = [ "bootstrap-cluster.sh ${join(" ", aws_instance.cluster.*.private_ip)}", ] } } ```

Answer 424

- SAML/SSO - Audit Logging - ServiceNow Integration

Answer 425

- consul - DynamoDB - azurerm

Answer 426

terraform fmt -check This command checks if the input is formatted. Exit status will be 0 if all input is properly formatted and non-zero otherwise.

Answer 427

Explanation: Answer: C + Option A is INCORRECT because this will destroy resources but will not recreate. + Option B is INCORRECT because this command will not destroy anything or recreate resources as it only plans what has to be changed. + Option C is CORRECT because taint manually marks a Terraform-managed resource as tainted, forcing it to be destroyed and recreated on the next apply. + Option D is INCORRECT because this option will destroy the resource but will not recreate it. If we want to just recreate a resource that is managed by terraform then, we can use the taint command, this will mark the resource as tainted and will destroy and recreate a similar resource in the next apply. Once taint is applied It only changes the state file. It marks the resource status as tainted. « https///wwwterraformio/docs/commands/tainthtml

Answer 428

Explanation: Answer:B Option A is INCORRECT because taint will not destroy resources but marks the resource for recreation in the next apply. Option B is CORRECT because taint marks the resource for recreation in the state file. It marks the status as tainted in the state file. Option C is INCORRECT because taint command alone can't destroy and recreate a file. Option D is INCORRECT because taint only recreates a resource mentioned in the command. It will not recreate all resources in the state file. The terraform taint command manually marks a Terraform-managed resource as tainted, forcing it to be destroyed and recreated on the next apply. it command is applied it only marks the status as tainted in the state file. To recreate a resource terraform apply should be executed. « https///wwwterraformio/docs/commands/tainthtml

Answer 429

Explanation: Answer:D + Option A Is INCORRECT because this will destroy the resource and then creates a new resource with variable name webapp + Option Bis INCORRECT because this will only change in state file, but will not get reflected in the configuration file + Option C is INCORRECT because this will change in the state file, but when terraform apply is applied it will recreate a resource with resource variable web + Option D is CORRECT this option will change in the state file and if we want the change to be applied in the configuration file then we need to manually do it. The terraform state mv command is used to move items in a Terraform state. This command can move single resources, single instances of a resource, entire modules, and more. This command can also move items to a completely different state file, enabling efficient refactoring. + https//wwwterraformio/doos/eommands/state/mv.html

Answer 430

True If a value is already set in the child module, then it can be overwritten by the root module.

Answer 431

nswer:E + Options A, 8, C and D are INCORRECT because these are valid source options for a module. + Option Eis CORRECT because we cannot use BLOB storage as module source option The source argument in a module block tells Terraform where to find the source code for the desired child module.Terraform uses this during the module installation step of terraform The module installer supports installation from a number of different source types, as listed below. Local paths Terraform Registry GitHub Bitbucket Generic Git, Mercurial repositories HTTP URLs S3 buckets GCS buckets + https//wnwterratormio/does/modiules/sourceshtmL

Answer 432

Explanation: Answer:B Specifying module version is not mandatory for the public module. When using modules installed from a module registry, we recommend explicitly constraining the acceptable version numbers to avoid unexpected or unwanted changes https://www.terraform.io/docs/configuration/modules.html#module-versions

Answer 433

Explanation: Answer: A + Option A is CORRECT plugin-dir option Skips plugin installation and loads plugins only from the specified directory. + Option Bis INCORRECT because plugin-path option is not present in nit command + Option C is INCORRECT because get-plugins accepts value a Boolean value. Skips plugin installation, Terraform will use plugins installed in the user plugins directory. and any plugins already installed for the current working directory. Ifthe installed plugins aren't sufficient for the configuration, init fal + Option Dis INCORRECT plugin-fil is not a valid option for init command, ~plugin-dir=PATH Skips plugin installation and loads plugins only from the specified directory. This ignores the user plugins directory and any plugins already installed in the current working directory. To restore the default behavior after using this option, run init again and pass an empty string to -plugin-dir https: //www.terraform.io/docs/commands/init.html#plugin-installation https: //www.terraform.io/docs/commands/init.html

Answer 434

Explanation: Answers: B and E + Option A is INCORRECT third-party plugins should be manually downloaded. + Option B is CORRECT third-party plugins can be manually installed in the user's plugin directory + Option C is INCORRECT third-party plugins can be manually installed in any directory but we need to specify its path using -plugin-cir=PATH option during initialization. + Option D is INCORRECT anyone can freely write and distribute plugins without HashiCorp approval + Option E is CORRECT plugins that can only be written in GO language as of now. Third-party plugins should be manually downloaded and installed. They can be installed in any directory. As of now, Plugins can only be written in the GO language. https: //www.terraform.io/docs/plugins/basics.html https: //www.terraform.io/docs/configuration/providers.html#third-party-plugins

Answer 435

Explanation: ‘Answers: A and C + Option A is CORRECT auto-approve option is used to skip interactive approval + Option Bi s INCORRECT -yes is not a valid option in terraform + Option C is CORRECT to apply will not ask for approval if plans is supplied as an argument, + Option Dis INCORRECT -auto-approve will not ask for value. We can skip interactive approval in 2 ways. + “and" operator is specific to Operating System on which this command is executed, If the OS is"Linux’ then “and” command will be used as conjunction and if the OS is Windows, then (semicolon) is used for conjunction as terraform plan ~out="test.fplan’; terraform apply test.fplan + Using ~auto-approve option along with terraform apply + When terraform apply runs on execution plan. It will net ask for approval This is useful when terraform is used in automation. https://www.terraform.io/docs/commands/apply.html

Answer 436

Explanation: Answer: C + Option A is INCORRECT because terraform will not create destroy and create as size, is already 4GB. + Option B is INCORRECT to terraform will not create a new resource as already resource is already present + Option C is CORRECT because as already server has reached the desired state terraform will not do any changes. + Option D is INCORRECT because ais already server has reached desired state terraform will not do any changes. Terraform uses the concept of the desired and current state. Whenever it tries to apply any changes it refreshes the state and sees what the current state is. Then it compares the current state to desired state present in the configuration file. hen it decides what changes to do.

Answer 437

Explanation Answer: B Til Terraform version 016, terraform destroy is the only command to destroy the infrastructure, but in terraform 015.2 and above versions, terraform apply -destroy is also used to destroy the infrastructure. For more information, see the links below:

Answer 438

Correct Answer: B Explanation: Workspaces are the main tool for Terraform to delegating access between different environments. The recommendations by Hashicorp have always been to create a workspace per environment. + Option A is incorrect when using workspaces in Terraform Cloud. On Terraform OpenSource an approach could be mybucket/dev/dev.tfstate mybucket/stg/stg.tfstate mybucket/prod/prod.tfstate but you are missing the permissions control + Option C is incorrect as we don't have segmentation between the different environments. + Option D is incorrect as A and C don't suit the best practices Reference: https://www.terraform.io/docs/cloud/guides/recommended-practices/part1.html#the-recommended-terraform-workspace-structure

Answer 439

D.Github, GitLab, BitBucket, Azure DevOps Supported VCS Providers Terraform Cloud supports the following VCS providers: ``` GitHub.com GitHub.com (OAuth) GitHub Enterprise GitLab.com GitLab EE and CE Bitbucket Cloud Bitbucket Server Azure DevOps Server Azure DevOps Services Use the links above to see details on configuring VCS access for each supported provider. If you use another VCS that is not supported, you can build an integration via the API-driven run workflow. ``` https://www.terraform.io/docs/cloud/vcs/index.html#supported-vcs-providers

Answer 440

Make a backup of your terraform.tfstate file and .terraform directory before using Terraform import on a real Terraform project, and store them securely.

Answer 441

Fixed permission sets Custom permissions Additionally, there is a special "admin" permission set that grants the highest level of permissions on a workspace. https://www.terraform.io/docs/cloud/users-teams-organizations/permissions.html#workspace-permissions

Answer 442

- Collection types: for grouping similar values | - Structural types: for grouping potentially dissimilar values