Understand Terraform basics

Question 1

How do you install terraform on different OS?

Answer 1

// Mac OS
brew install terraform

// Windows
choco install terraform

https://learn.hashicorp.com/terraform/getting-started/install

Question 2

How do you manually install terraform?

Answer 2

step 1: Download the zip fille

step 2: mv ~/Downloads/terraform /usr/local/bin/terraform

Question 3

Where do you put terraform configurations so that you can configure some behaviors of Terraform itself?

Answer 3

The special terraform configuration block type is used to configure some behaviors of Terraform itself, such as requiring a minimum Terraform version to apply your configuration.
terraform {
  # ...
}

Question 4

Only constants are allowed inside the terraform block. Is this correct?

Answer 4

Yes
Within a terraform block, only constant values can be used; arguments may not refer to named objects such as resources, input variables, etc, and may not use any of the Terraform language built-in functions.

Question 5

What are the Providers?

Answer 5

A provider is a plugin that Terraform uses to translate the API interactions with the service. A provider is responsible for understanding API interactions and exposing resources. Because Terraform can interact with any API, you can represent almost any infrastructure type as a resource in Terraform.
https://www.terraform.io/docs/configuration/providers.html

Question 6

How do you configure a Provider?

Answer 6

provider “google” {
project = “acme-app”
region = “us-central1”
}

The name given in the block header (“google” in this example) is the name of the provider to configure. Terraform associates each resource type with a provider by taking the first word of the resource type name (separated by underscores), and so the “google” provider is assumed to be the provider for the resource type name google_compute_instance.

The body of the block (between { and }) contains configuration arguments for the provider itself. Most arguments in this section are specified by the provider itself; in this example both project and region are specific to the google provider.

Question 7

What are the meta-arguments that are defined by Terraform itself and available for all provider blocks?

Answer 7

version: Constraining the allowed provider versions
alias: using the same provider with different configurations for different resources

Question 8

What is Provider initialization and why do we need?

Answer 8

Each time a new provider is added to configuration – either explicitly via a provider block or by adding a resource from that provider – Terraform must initialize the provider before it can be used.
Initialization downloads and installs the provider’s plugin so that it can later be executed.

Question 9

How do you initialize any Provider?

Answer 9

Provider initialization is one of the actions of terraform init. Running this command will download and initialize any providers that are not already initialized.

Question 10

When you run terraform init command, all the providers are installed in the current working directory. Is this true?

Answer 10

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.

Question 11

How do you constrain the provider version?

Answer 11

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

Question 12

How do you upgrade to the latest acceptable version of the provider?

Answer 12

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.

Question 13

How many ways you can configure provider versions?

Answer 13

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"
}

Question 14

How do you configure Multiple Provider Instances?

Answer 14

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.

Question 15

Why do we need Multiple Provider instances?

Answer 15

Some of the example scenarios:

a. multiple regions for a cloud platform
b. targeting multiple Docker hosts
c. multiple Consul hosts, etc.

Question 16

How do we define multiple Provider configurations?

Answer 16

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"
}

Question 17

How do you select alternate providers?

Answer 17

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

  # ...
}

Question 18

What is the location of the user plugins directory?

Answer 18

Windows %APPDATA%\terraform.d\plugins

All other systems ~/.terraform.d/plugins

Question 19

Third-party plugins should be manually installed. Is that true?

Answer 19

True

Question 20

The command terraform init cannot install third-party plugins? True or false?

Answer 20

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.

Question 21

What is the naming scheme for provider plugins?

Answer 21

terraform-provider-_vX.Y.Z

Question 22

What is the CLI configuration File?

Answer 22

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

Question 23

Where is the location of the CLI configuration File?

Answer 23

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

Question 24

What is Provider Plugin Cache?

Answer 24

By default, terraform init downloads plugins into a subdirectory of the working directory so that each working directory is self-contained. As a consequence, if you have multiple configurations that use the same provider then a separate copy of its plugin will be downloaded for each configuration.
Given that provider plugins can be quite large (on the order of hundreds of megabytes), this default behavior can be inconvenient for those with slow or metered Internet connections.
Therefore Terraform optionally allows the use of a local directory as a shared plugin cache, which then allows each distinct plugin binary to be downloaded only once.

Question 25

How do you enable Provider Plugin Cache?

Answer 25

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:

Question 26

When you are using plugin cache you end up growing cache directory with different versions. Whose responsibility to clean it?

Answer 26

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.

Question 27

Why do we need to initialize the directory?

Answer 27

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.

Question 28

What is the command to initialize the directory?

Answer 28

terraform init

Question 29

If different teams are working on the same configuration. How do you make files to have consistent formatting?

Answer 29

terraform fmt

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

Question 30

If different teams are working on the same configuration. How do you make files to have syntactically valid and internally consistent?

Answer 30

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.

Question 31

What is the command to create infrastructure?

Answer 31

terraform apply

Question 32

What is the command to show the execution plan and not apply?

Answer 32

terraform plan

Question 33

How do you inspect the current state of the infrastructure applied?

Answer 33

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.

Question 34

If your state file is too big and you want to list the resources from your state. What is the command?

Answer 34

terraform state list

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

Question 35

What is plug-in based architecture?

Answer 35

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

Question 36

What are Provisioners?

Answer 36

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.

Question 37

How do you define provisioners?

Answer 37

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

Question 38

What are the types of provisioners?

Answer 38

local-exec

remote-exec

Question 39

What is a local-exec provisioner and when do we use it?

Answer 39

The local-exec provisioner executing a 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

Question 40

What is a remote-exec provisioner and when do we use it?

Answer 40

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.

Question 41

Are provisioners runs only when the resource is created or destroyed?

Answer 41

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.

Question 42

What do we need to use a remote-exec?

Answer 42

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"
    ]
  }
}

Question 43

When terraform mark the resources are tainted?

Answer 43

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.

Question 44

You applied the infrastructure with terraform apply and you have some tainted resources. You run an execution plan now what happens to those tainted resources?

Answer 44

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

Question 45

Terraform also does not automatically roll back and destroy the resource during the apply when the failure happens. Why?

Answer 45

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

Question 46

How do you manually taint a resource?

Answer 46

terraform taint resource.id

Question 47

Does the taint command modify the infrastructure?

Answer 47

terraform taint resource.id
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.

Question 48

By default, provisioners that fail will also cause the Terraform apply itself to fail. Is this true?

Answer 48

True

Question 49

By default, provisioners that fail will also cause the Terraform apply itself to fail. How do you change this?

Answer 49

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"
  }
}

Question 50

How do you define destroy provisioner and give an example?

Answer 50

You can define destroy provisioner with the parameter when
provisioner “remote-exec” {
when = “destroy”

# 

}

Question 51

How do you apply constraints for the provider versions?

Answer 51

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"
  }
}

Question 52

What should you use to set both a lower and upper bound on versions for each provider?

Answer 52

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

Question 53

How do you try experimental features?

Answer 53

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]
}

Question 54

When does the terraform does not recommend using provisions?

Answer 54

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

Question 55

Expressions in provisioner blocks cannot refer to their parent resource by name. Is this true?

Answer 55

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.

Question 56

What does this symbol version = “~> 1.0” mean when defining versions?

Answer 56

Any version more than 1.0 and less than 2.0

Question 57

Terraform supports both cloud and on-premises infrastructure platforms. Is this true?

Answer 57

True

Question 58

Terraform assumes an empty default configuration for any provider that is not explicitly configured. A provider block can be empty. Is this true?

Answer 58

True

Question 59

How do you configure the required version of Terraform CLI can be used with your configuration?

Answer 59

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.

Question 60

Terraform CLI versions and provider versions are independent of each other. Is this true?

Answer 60

True

Question 61

You are configuring aws provider and it is always recommended to hard code aws credentials in *.tf files. Is this true?

Answer 61

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

Question 62

You are provisioning the infrastructure with the command terraform apply and you noticed one of the resources failed. How do you remove that resource without affecting the whole infrastructure?

Answer 62

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