Below is my ultimate resource for learning Terraform via a written tutorial.

It is everything that is
needed to get anyone up and running on Terraform in a quick, easy manner and immediately
jumps into the building of resources (the fun part).

Additionally it contains pretty much everything you would require as knowledge for the
Hashicorp Terraform Associate Exam, so it doubles up as pretty good exam notes as well! Do
note that while this guide is focussed on building AWS resources, the core concepts are the key
takeaway and Terraform is designed to easily switch between providers (AWS, GCP etc.).

Lastly if you are looking for a good video course on Terraform I cannot recommend Zeal Vora’s
Udemy Course enough. In fact a lot of my notes from the course are included in this guide.

The Guide

Key
Purple - Phrases and Terms used specifically in Terraform and Terraform Code.
Blue- Highlights General Important Terms and Phrases.
Red - Command Line Arguments.

Important to note that purple terms will often be terms that are both used within
Terraform and outside of it. They aren't always terms ONLY used in Terraform. For
example an AMI on AWS is referred to as an AMI within Terraform as well.

Infrastructure as Code - Tools Overview

There are a lot of tools that allow you to deploy infrastructure as code:
​ Terraform
​ CloudFormation
​ Heat
​ Ansible
​ SaltStack
Chef, Puppet, Others

Not all of these tools are targeted for the same purpose. It is important to understand
the difference between Configuration Management and Infrastructure Orchestration:
 ​ Ansible, Chef and Puppet are configuration management tools which means they
are primarily designed to install and manage software on existing servers
​ Terraform and CloudFormation are infrastructure orchestration tools which are
designed to provision servers and infrastructure themselves.

You can use infrastructure orchestration tools and configuration management tools in
tandem. For example you could use Terraform to create a new EC2 instance on AWS,
Terraform can then call Ansible to install and configure software and applications on the
EC2 instance.

Terraform Simple Benefits Overview

​ Terraform supports multiple platforms - AWS, GCP, Azure etc.
​ Terraform has a simple language and a fast learning curve. The syntax is easy to
read and understand.
​ Terraform is easy to integrate with configuration management tools like Ansible.
​ It is easily extensible with plugins.
​ It is free.

Creating a Simple EC2 Instance with Terraform

When launching a resource in AWS there are 3 things to consider:
​ How will you authenticate to AWS?
​ Which region will the resource be launched in?
​ Which resource do you want to launch?

There are various ways to authenticate to AWS but the easiest when first using
Terraform is static credentials. These consist of a Key-Pair.
To use this you create a key pair for an AWS IAM User which Terraform will use to
authenticate to AWS.
It is important to note that while static credentials in your main file is an easy method
and useful as a tutorial or for hobby use it is not considered best practice.

First create a .tf file in this case I will use first_ec2.tf

Now you can edit the file to add Terraform code.

Example code for a simple EC2 instance:

provider "aws" {
region = "us-west-2"
access_key = "ExAmpLEKey21fjwljsfjkrf"
secret_key = "EXamPLeSECreTKEySDAHhhhsJJn23Ksda"
}
resource "aws_instance" "my_ec2" {
ami = "ami-05b622b5fa0269787"
instance_type = "t2.micro"
}

As you can see in this example code we have included answers to the "3 important
things to consider". Lets run through the code step-by-step:

Statement 1 (defines what platform, where to launch and method of authentication):

provider - In this case it is "aws", the provider has to be specified and it is simply the
platform that terraform will be provisioning infrastructure on.
region - This is the AWS Region we want to launch our EC2 instance into. In this case we
have chosen "us-west-2"
access_key - This is the 'access key' from the key pair we created for our AWS IAM
User, it is part of what allows Terraform to authenticate to AWS.
secret_key - This is the 'secret key' from the key pair we created for our AWS IAM User.

Statement 2 (defines resource specfications):

resource - In this case we have specified "aws_instance" the terraform name for an AWS
EC2 Instance and secondly "my_ec2" which is what we want to name the instance. Two
resource blocks cannot have the same name "my_ec2" will be a unique name in the file.
ami - Specifies the Amazon Machine Image, ie. what image (OS specifics) we want to
load on the EC2 Instance.
instance_type - In this case we have specified "t2.micro" this specifies what type of
Amazon EC2 we want our instance to be. (How much memory, storage etc.)

Every AWS resource has mandatory elements and optional elements to include in a
Terraform resource statement. For EC2 you need to specify the resource, ami and
instance type.
However there are far more elements that optionally can be specified. They are not
included here as this is as simple as it gets for launching an EC2.

You can view the requirements for each AWS resource at the Terraform Registry
Documentation.

Now we have written our code and saved it with a .tf file type we can run the code with
Terraform.

Step 1: Run "terraform init" on the command line in the folder containing your tf
file - This will initialise Terraform and install any dependencies your file requires.

Step 2: Run "terraform plan" this will generate a plan of the infrastructure your file
will create.
Notice how the ami and instance_type are specified but a whole load of other options
are "known after apply". These could have been specified but were optional. Bear in
mind these options run a lot longer than this screenshot shows.

Step 3: If you are happy with the plan, run "terraform apply" to create the
infrastructure.

Step 4: Terraform will show you the plan again and ask if you want to perform these
actions. Say 'yes'.
Provided there are no errors during apply if you check your management console there
will now be an EC2 Instance running.

Providers
Terraform supports multiple providers:

Dependant on what type of infrastructure you want to launch you will have to use the
appropriate provider in Terraform.

This is important for the initialisation phase:

Whenever you add a provider it is important to run "terraform init" which will
download plugins associated with the provider.
This is from the EC2 example above, notice how Terraform has realised we are using the
AWS provider and has downloaded the associated AWS plugins.

In Terraform there are certain providers that are either "Hashicorp Maintained" (AWS,
Azure etc.) or "Non-Hashicorp Maintained". Below is best practice syntax for
establishing providers in your Terraform, notice how there are two blocks, one for what
providers are required and another for each provider specific config.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "3.33.0"
}
}
}

provider "aws" {
# Configuration options
}

In Terraform v13+ this provider syntax is actually deemed best practice for all providers.
You can get this code block ready made from the Terraform Registry website.

If you are comfortable in Terraform in one provider it is easy to switch between

providers as the overall Terraform syntax is the same and only provider specific terms
and resources change.
Resources
Resources are references to individual services a particular provider offers.
Eg. in AWS for an EC2 instance the Terraform resource is aws_instance

Resources in terraform can get very specific, below is a snapshot from the Terraform
Registry of some AWS EC2 resource options:

You can see aws_instance which we used in the example in this list. However there are
so many more resource options which can be used.

Using a Non-AWS Provider (Example)

In this example we will create a simple GitHub repository with terraform. Information on
the provider code block and syntax is easily found at the GitHub TF Registry

Below is the Terraform code to create a GitHub RepositoryCode:

You can see in the above we are using a separate code block to define the provider. As
discussed this is actually now best practice and the simpler form used in the earlier EC2
AWS example is now slightly outdated.
The provider block can just be copied from the provider documentation on the TF
Registry, click the "Use Provider" button to get the block with the above syntax. You can
do this for any provider.
Note in the above example GitHub authentication is a "token" rather than access keys.
The authentication method does change between providers and you can check what is
needed in the TF Documentation. In this case all you have to do is request a token from
your GitHub account in your browser and use it in Terraform.

To run this code and create a new GitHub repo we simply have to use:
​ terraform init - This downloads the necessary packages for the GitHub
provider
​ terraform plan - Create a plan for what infrastructure will be changed
​ terraform apply - Create the infrastructure
Destroying Resources With Terraform

terraform destroy - allows us to destroy all resources created within the folder.

But what if I don't want to destroy all resources? Currently I have the EC2 Instance I
created as well as a GitHub Repo. terraform destroy will just destroy both of these.
Let's say I only want to destroy the EC2 Instance.
In this case we can make use of a "target flag" to direct Terraform on what resources to
destroy:
terraform destroy -target aws_instance.my_ec2

The target option can be used to focus Terraform's attention on only a subset of
resources. You use a combination of Resource Type + Local Resource Name.
These are the Resource Types and LRNs we have created so far:

Resource Type Local Resource Name

aws_instance my_ec2

github_repository example

Below is the code where Resource Type and Local Resource Name are defined:

​ Resource Type - An unchangeable resource type used by Terraform that refers to

a specific resource type for a provider
 ​ Local Resource Name - The name you give to the resource you create, it is a
custom value and can be anything you want. Do note this name only applies
locally within your terraform code as a reference, it is not the name given to the
resource itself.

So when using terraform destroy -target aws_instance.my_ec2 - the

"aws_instance.my_ec2" at the end tells Terraform exactly what resource to destroy. The
syntax being "resource_type.local_resource_name".

When we run the destroy command with the target flag. Terraform will let us know it is
specifically going to destroy only the resources we flagged:

Next we say "yes" please do destroy this.

It will run the destroy which may take a minute. Now if we check AWS there will no
longer be an instance running. It's that easy!

It is important to note that while we have destroyed this resource we have not removed
the code to create the aws_instance from our first_ec2.tf config file.
Due to this if we now ran terraform plan again then Terraform will plan to create the
aws_instance we just destroyed again.

If you don't want this to be the case then you can remove the code creating the
aws_instance from the config file entirely or you could just comment it out.
Terraform State Files
Terraform stores the state of the infrastructure that are created in the .tf files in the
Terraform State File.

This state file allows Terraform to map real world resources to your configuration files.

When we first ran terraform init on our initial first_ec2.tf file it created a state file
within the folder.

Once we used terraform apply to bring up the EC2 instance Terraform then added
the state of that EC2 Instance to the state file.

This is how Terraform knows what needs creating and what doesn't when subsequent
changes are made in the folder. For example when we then created the GitHub repo,
Terraform didn't also try to spin up another EC2 instance when we ran terraform
apply. That is because while we had first_ec2.tf and github.tf in the same folder, all the
resources in first_ec2.tf had already been created and were up and running, this
information was stored in the state file. So Terraform checked this file and said "Oh the
EC2 instance is already here, no need to create that. But the GitHub repo is not in the
state file so I must still need to create that".

Once the GitHub repository was created its state was stored in the state file. So if we
tried to run terraform plan it would say no changes need to be made as Terraform
can see that all the requested infrastructure in the config files is up and running in the
exact way the config files want it to be.

However when we destroyed the EC2 Instance, Terraform removed it from the state file.
This is why if we tried to run terraform plan after this destruction Terraform would
plan to recreate the EC2 instance. The code to create the AWS instance is still in the
first_ec2.tf config file but its state is no longer in the state file so Terraform assumes it
still needs to create it.
The state file is maintained by Terraform itself is not something you should ever really
be directly editing.

Terraform Desired & Current State

Terraform's primary function is to create, modify, and destroy infrastructure resources to
match the desired state described in a Terraform configuration.
The current state is the actual state of a resource that is currently deployed. Terraform
will try to make sure that the deployed infrastructure is always based on the desired
state defined by the .tf config files.

If there is a difference between the desired state and current state then terraform
plan will present a description of the changes necessary to bring the current state in
line with the desired state.

If the current state and desired state match then terraform plan will output that no
changes are needed.

An important thing to note is that if something is not specified in the .tf config file then
it is not part of the desired state.

For example in our AWS EC2 instance created at the start we have specified only the
aspects that are mandatory to specify:

We have not for example specified what security group this should be part of. As such
Terraform has put it in the default security group. However if I went on to the AWS
Browser Console and manually changed the security group then the current state of the
EC2 Instance would differ from what was in the state file. The state file will still show
that the security group is default while the actual, physical current state of the EC2
security group is that it's a custom one (not default).

So you might think that if we now run terraform plan that Terraform will pick this
change up and plan to change the security group back to the default. However that is
not the case, even though the EC2 instance would differ from the state file it doesn't
actually differ from the desired state. We have not specified the security group in the
config file so there is not a "desired state" for the security group.

As such all terraform will do when we run terraform Plan is request the current
state of the EC2 see that it doesn't differ from the desired state and so not plan any
changes, however it will see that it does differ from the state file so Terraform will
update the state file to show the EC2 instance has a custom security group rather than
the default.

Provider Versioning
During terraform init, if the version argument is not specified in the config file, the
most recent provider plugin will be downloaded during initialisation.

For production use you should constrain the acceptable provider versions via
configuration, this ensures that new versions with breaking changes will not be
installed.

You specify this in the tf config file in the version field for the provider:
There is syntax for describing versions:
>=1.0 - Greater than or equal to the version
<=1.0 - Less than or equal to the version
~>2.0 - Any version in the 2.X range
>=2.10, <=2.30 - Any version between 2.10 and 2.30

Dependency Lock File:

The Terraform dependency lock file (terraform.lock.hcl) allows us to lock to a specific
version of the provider.
If a particular provider already has a version selection recorded in the lock file then
Terraform will always re-select that version for installation, even if a newer version
becomes available.

You can override that behaviour by adding -upgrade when you run terraform init

Attributes & Output Values

Note that the code written in this section is now in a separate folder to the EC2 and
GitHub examples above.
Terraform can output the attributes of a resource that has been created.

Outputted attributes can be used as input for other resources being created by
Terraform.

For instance lets say you are creating an Elastic IP Address with Terraform.
Once Terraform creates that EIP it can output the IP Address attribute and feed it into
Terraform code that whitelists that IP within a security group.

In the below Terraform code we create both an EIP and an s3 bucket with outputs:
(Bare in mind this code is preceded by an AWS provider block)

Here you can see we create an EIP with aws_eip and call it lb
Then we have the output block instructing Terraform to output the Public IP of the EIP
we created. You can see that because we gave our EIP a terraform name of lb, we can
reference that name with aws_eip.lb when asking for output of that particular resource.
This comes in handy when you have multiple aws_eip resources in the script and want
the output of one of them.

Next we create an s3 bucket with aws_s3_bucket and call it mys3, now we also specify
a globally unique name for the s3 bucket within AWS.
Important to note that mys3 is the name we have given to this s3 bucket within our
Terraform code but the buckets actual name on AWS will be zeal-tf-tutorial-hk112j.
Following on from the s3 resource block is the s3 output block. This is written to output
the domain name of the bucket.

In the output blocks for the s3 bucket .bucket_domain_name is the attribute we want to
output and .public_ip is the attribute to output for the EIP. If we don't specify a particular
attribute at the end of the line then it would output all of the attributes for that resource.

So the structure of the output will be the key we gave for the output blocks "eip" and
"mys3bucket" (these are custom and can be whatever you want). One on each line
followed by the actual output.

When we run terraform apply on this code we get the following output:

So the Terraform creates the EIP and s3 buckets as expected. Then it outputs the
attributes we asked for.

You can find the attributes you can request to be outputted for a particular resource in
the Terraform registry.

Referencing Cross-Account Attributes

Outputted attributes of resources can not only be used for user reference but also as
inputs for other resources being created by Terraform.

In the below example we create an AWS Elastic IP and and an EC2 instance, we will use
the outputted attributes of these two resources to allocate the EIP to the EC2.

Bear in mind that as always this was preceded by an AWS provider block. In the above
code the first block we create is a very basic EC2 and we give it the name "my_ec2".
Second block we create the EIP and give it the name "lb".

The third block is what we want to look at here. We are creating a "resource" which is an
aws_eip_assocation. This can be found in the AWS Documentation on the Terraform
registry.
It will essentially allow us to automatically allocate the EIP to the EC2 we have created.

You can see the standard syntax of resource "resource_type"

"resource_name" in the first line of the block.

In the next line instance_id we are clarifying the resource we want the EIP to attach to
aws_instance.my_ec2 this refers to the instance we have created, however it requires
the instance id, this is an attribute outputted once the EC2 is created. We can call this by
adding the .id attribute reference at the end. So aws_instance.my_ec2.id
The final line allocation_id we are specifying exactly which EIP we want to allocate by its
id. So aws_eip.lb.id, lb being the name we gave to the resource.

Run terraform apply on this and we now have an EIP and an EC2 running in AWS and the
EIP is allocated to the EC2.

Terraform Variables Basics

Just like in any language repeated static values can create work in future if they need
changing.
Lets say in you have a few Terraform projects that reference that same IP address
116.30.45.50 say this IP comes up 8 times across your Terraform projects.

That is fine when you are first writing it, but what happens a few months down the line
and this IP needs changing? You have to go back in and change it 8 separate times
which is effort spent and opens the door for human error.

Instead of repeating the IP value over and over again. When you first need it you can put
the value in a central source from which you can import values in Terraform projects.
Now if you needed to update the value you can just update it in the central source and it
will update in all your projects.
Here we are creating a simple AWS security group. The syntax to construct it isn't overly
relevant, what is important is repetition of the IP address in the CIDR block. In
production this might be repeated 10 or 20 times in various projects.

So what we do is create a separate .tf file to use as a central source for variables. In this
case I have created a file called variables.tf and created a variable for this IP value.

No we can reference that variable directly in our cidr_blocks value with the syntax
var.variable_name.
Terraform is smart enough to look for the vpn_ip variable and insert it where we have
referenced it.

Now if we run terraform plan you can see that Terraform replaces the variable with
the value we want (look at + cidr_blocks) :

Now if you wanted to change the IP Address, instead of changing in multiple places in
multiple projects you can just change it in the one variable file.
Various Ways to Assign Variables
There are multiple ways to assign values to variables:

​ Environment Variables
​ Command Line Flags
​ From a File
​ Variable Defaults

Variable Defaults:
Variable Defaults are exactly as we have used in the IP example above, they are the
default value you give to a variable when you create it.
Another example of this is the code below creating a very simple EC2 (as always this is
preceded by a provider block):

As you can see we have used a variable that we have called instancetype (though it
could be called anything) and assigned it to the instance_type.
We have defined this variable as "t2.micro" in a separate file (t2.micro is a type of EC2 in
AWS):
We have given the value "t2.micro" as the default value for the "instancetype" variable.
Unless explicitly told otherwise, when Terraform sees a reference to this variable it will
supplement the default value we have specified above: "t2.micro"

A terraform plan on this code shows that Terraform does indeed swap
var.instancetype for t2.micro:

This value t2.micro is the default value for the variable, we can override this in a couple
of ways:

Overriding defaults directly in the Terraform commands:

This method uses command line flags:
terraform plan -var="instancetype=t2.small"

if we use this command for the code above here is the output:
You can see we have changed the value for the instancetype variable and now the EC2
will be created as type t2.small

If we ran terraform plan by itself again it would plan to create a t2.micro as that is
still the default value of the variable.

This method is not best practice for overriding defaults

Overriding defaults with a terraform.tfvars file:

You can create a separate file called terraform.tfvars - it is always called exactly that.

Within this file you can specify different values from the default values you have already
put in your variables file:
Note that the syntax is different to defining the variable. This is closer to reassigning it,
it still needs to have been initially defined though.

Now if we run terraform plan:

Terraform realises there is a terraform.tfvars file and looks there first for the
instancetype variable value. If it weren't there it would use the default value "t2.micro"
we defined in another file.

The terraform.tfvars file is not a replacement for the file where you define variables and
give them default values, it is additional and allows you to specify values other than the
default.

It is possible to pass a .tfvars file to use on the command line when you run terraform
apply.

This is often used in production environments to have one config file that can be applied
to multiple environments (UAT, PreProd, Prod). You would have your one config file and
in order to provision or make changes to Prod you would pass the prod.tfvars file.

The command line syntax for this is as follows:

terraform apply -var-file="prod.tfvars"
Finally Environment Variables:
You can define a variable within your environment with the linux syntax:
export TF_VAR_variablename="value"

eg. export TF_VAR_instancetype="t2.nano"

Environment variables is the first place Terraform will look for values. So if instancetype
has a value set in the environment that is the value Terraform will use even if it is also
specified in the terraform.tfvars file.

Best Practice for variables in production is to define defaults in a variables.tf file and
then put any necessary overrides in a terraform.tfvars file.

Data Types for Variables

Variable Types:
​ string: a sequence of Unicode characters representing some text, like "hello".
​ number: a numeric value. The number type can represent both whole numbers
like 15 and fractional values like 6.283185.
​ bool: a boolean value, either true or false. bool values can be used in conditional
logic.
​ list (or tuple): a sequence of values, like ["us-west-1a", "us-west-1c"]. Elements in
a list or tuple are identified by consecutive whole numbers, starting with zero.
​ map (or object): a group of values identified by named labels, like {name =
"Mabel", age = 52}.
The type argument in a variable block allows you to restrict the type of value that can be
assigned to the variable.

For example:
Now the above variable my_id will only ever accept values with a type of string.

It is considered best practice to always specify the type that a variable will expect.

Using Maps and Lists with Variables

In the below code we are creating an EC2 and have two different variables we can use to
choose the instance_type.
There is the "list" variable, a list of 3 instance types. There is also the "types" variable, a
map of 3 more instance types.
Currently you can see at the top instance_type is set to var.types but this corelates to
the entire types map, 3 different instance types.
So when referring to a list or map how can we choose a specific value?

With Maps you can specifically choose a value by using its key with the following
syntax:

This will make the instance_type equal to the us-east-1 value in the types map. If you
look at the code with the map itself, us-east-1 is the key for the "t2.micro" value.
As such instance_type in this case will be equal to t2.micro.

With Lists you can choose the value by index, exactly like Python.

Index starts at 0 so in this case the instance_type will be set to the first item in our list
"m5.large". Please note that the syntax we have used here var.list is because we have
named the list of 3 instance types "list". This could easily be var.mylist or var.list1.

Terraform Count
The count parameter on resources can simplify configurations and let you scale
resources by simply incrementing a number.

If you wanted to create two identical EC2 instances, one approach you could take is to
use two separate resource blocks:

This approach can certainly be painful once you need lots of the same resource. What if
we needed 5 EC2 instances? We don't want to copy and paste the block 5 times,
especially if we will be changing anything in the instances, then we will have to make
any changes to 5 different blocks.

What we can do is make use of the count parameter:

This simple addition tells Terraform to create 5 of this resource. If we now run
terraform plan it will indeed plan to create 5 EC2 Instances of Type "t2.micro"

An important thing to note is that we have still only specified one name "instance-1" but
terraform will create 5 resources. What it will do is append an indexing number to the
given name for each resource it plans to create, so in this case the 5 EC2 instances in
Terraform would be named: instance-1[0], instance-1[1], instance-1[2], instance-1[3] and
instance-1[4].
The names above (instance-1[0] etc.) are just Terraform references so you can refer to a
specific instance within Terraform. These names will not actually appear in the AWS
console once they have been made. However it is important to note that some
resources require actual names in AWS.

If a resource requires a unique value / identifier and you want to use the count
parameter to build multiple of them, then you can use count index to make them unique.

Below is an example using Terraform to create multiple IAM Users:

The ${count.index} syntax will append a number to the name of each IAM User
created by that block.

Here we can see the first two outputs of a terraform plan on the above code:
Notice how the name in each is unique: user.0 and user.1 the full output carries on for
all 5 IAM Users created.

You can probably already see that there will be some occasions where it would be far
more useful to have more specific names than user.1, user.2 etc. Well Count Index can
help with that as well. We can do this using a list variable, which I have put in the same
file for ease of screenshotting:

Here you can see in the first block we have a list "iam_users" and it has 3 values in it. We
use these values as the names for our IAM Users we create in the next block.
In the second block we are creating the IAM Users, we give them the terraform
reference name of "user" but we give each one an actual name with:
name = var.iam_users[count.index]

Remember that specific items in lists can be referred to in Terraform via their index. So
in the list iam_users above we have ["dev-user", "staging-user", "prod-user"] so
var.iam_users[0] is equal to the first item in the list "dev-user".

With this in mind think that for each resource created count.index iterates once starting
at zero. So the first IAM User created will have a name equivalent to var.iam_users[0]
which as we have just seen equates to "dev-user". The next resource count.index will be
equal to 1 so this IAM User will have a name equivalent to var.iam_users[1] or
"staging-user".

Conditional Expressions
Conditional expressions select one of two Boolean values (true or false).

Structure of a conditional expression:

condition ? value_if_true : value_if_false

An example of when you might use this is having two resource blocks one for Dev and
one for Prod, but you only need one depending on the environment you are building.
You can use a variable called "istest" and when the variable is set to true Terraform
should build from the Dev resource block and when it is set to false Terraform should
build from the Prod resource block.
This is shown in the code below:

This looks kind of complicated but it really isn't.

First we have defined a variable called "istest", but currently it doesn't have a set value.

The first resource block is a standard block. Things are normal until the line beginning
with count. Lets go over it:
count = var.istest == true ? 1 : 0

Remember the count parameter tells Terraform how many of the resource to make.
So line this essentially says if the istest variable is equal to true then count equals 1,
else count equals 0. If istest is true make one of this resource, else make none.

The line has the exact same meaning as this python syntax:
Bare in mind though that unlike Python, Terraform does not capitalise Boolean
expressions it's true & false not True & False

The second resource block has the same conditional expression just switched around.
If the istest variable is set to false then this isn't a test environment and the prod
environment should be built so count will be set to 1 in that resource block.

Now we will set the value of istest in a terraform.tfvars file to be true and run
terraform plan:

You can see that as "istest" is set to true Terraform is planning to create the Dev AWS
instance and won't create the Prod one at all.

You can use higher numbers just like you normally would with count:
count = var.istest == true ? 4 : 0
If is test = true then make 4 of this resource.

Local Values
Local values assign a name to an expression, allowing it to be used multiple times
within a module without repeating it.
In the code below we have defined the common_tags local value and have then used
that in the following two resource blocks to minimise repetition with the syntax tags =
local.common_tags
Note you define local values with the locals block but you call a local value with "local."
(no S).

This is cool but it doesn't seem all that different to a standard variable. One of the main
benefits of locals is that you can use expressions within them. Standard variables only
take static values.

An example of using expressions to define a local value:

The expression here means If var.name does not equal an empty string, then
name_prefix is equal to var.name, else name_prefix is equal to var.default.
Notice here how the expression is referring to two standard variables of var.name and
var.default within the conditional expression. These two standard variables would be
variables we have defined elsewhere.

This is really useful as without the ability to assign conditional expressions to a value
we would have to hard code that expression into every block we need it in. With this we
can just use the "name_prefix" local value instead.
Locals can also use Terraform Functions to define values (we haven't gone through
them yet).

Terraform Functions
Terraform includes built-in functions that can be used to transform and combine values.

The general syntax for functions is a function name followed by comma separated
arguments in parentheses:
function(argument1, argument2)

A specific example of this:

> max(5, 12, 9)
> Output: 12
The max function outputs the largest argument.

Terraform doesn't support user defined functions. Only those that are built-in to the
language.
A complete list of supported functions can be found here: Terraform Registry -
Functions

You can test out functions before using them in your Terraform files with the use of the
terraform console command.

Type the command into your terminal and then you can test out functions to see how
they operate and what their outputs will be.
Above we have tested both the max and the min functions.

Data Sources
Data sources allow data to be fetched or computed for use elsewhere in the Terraform
configuration.

The best way to understand this is through example.

Every aws_instance resource block we have used so far has used a hardcoded ami.
Notice how the AMI (Amazon machine image) is hardcoded specifically to one AMI
code.

This is the AMI for Ubuntu in the us-west-2 region. AMI codes change between regions
even for the same type of AMI. So if we wanted to use the Ubuntu AMI in the us-east-1
region it would be a completely different code.

Remember that the region to deploy into is defined in the provider block:

So what will happen to our code if someone comes in and wants to change the region to
us-east-1? Well they'd also need to change all of the references to region specific AMIs.
They would also have to change any other region specific references for resources.

Data sources give us a work around for this:

You define the data source within the data block. So the data source is "aws_ami" and
we have named the data source "app_ami".

The code within the data block is to specify which AMI type you want to call. For
instance in this case we always want the Amazon Ubuntu AMI no matter the region (the
AMI code will change between regions).

most_recent = true - we want the most recent version of the AMI we are
requesting.

owners = ["Amazon"] - Specifies the 'owner' of the AMI. Basically the entity which
created it, Amazon produce some of their own AMIs and we are using one of them.

filter { - Where you can filter the type down further eg. the exact instance type we
want (Amazon Ubuntu).

values = ["amzn2-ami-hvm*] - specifying the exact instance type we want (you

can find the AMI ID needed in the AWS docs)
We have then called this data source within the aws_instance resource block to get the
correct AMI for whatever region we have specified in the provider block.

Now no matter what region we select Terraform will always pull the correct AMI for that
region from the "aws_ami" data source.

Terraform Debugging
There are detailed logs in terraform which can be enabled by setting the TF_LOG
environment variable to any value.
You can set TF_LOG to one of TRACE, DEBUG, INFO, WARN or ERROR to change the
verbosity of the logs.

For instance in Linux you would set this variable on the Command Line to TRACE with:
TF_LOG=TRACE

This will print logs to the terminal and the different levels of verbosity will allow you
choose the detail you would like to see the logs in.

You can output the logs to a file rather than output to terminal with the following
command:
export TF_LOG_PATH=/path/to-log-file

TRACE is the most verbose, it is the default if TF_LOG is set to something other than a
log level name.
To disable logging set the TF_LOG variable to empty:
export TF_LOG=

Terraform Formatting

You can use the terraform fmt command to rewrite your Terraform configuration
files with best practice formatting.

Here is some example code for a simple EC2 instance in a file called my_ec2.tf before
using terraform fmt
Now here is the same code after inputting terraform fmt my_ec2.tf in the
command line:
You can just use terraform fmt on it's own and not specify the file. This will format
all config files in the directory.

Terraform Validate
terraform validate checks whether a configuration file is syntactically valid. It can
check for issues including unsupported arguments, undeclared variables etc.

Here is some code with an invalid argument of "cheese":

If we now run terraform validate on this file we get the following output:

This allows you to quickly identify if there are any errors in your Terraform code.

Note that when you run terraform plan the command will also perform a validate to
check that your code is valid before it makes the plan.

Load Order and File Structure

Terraform generally loads all config files within a directory in alphabetical order.
It will only load files ending with either .tf or .tf.json (this specifies the format in use).

When using Terraform in production generally you will have a few different config files
for different aspects of the code.

Lets say we have the following code all in one config file called test.tf:
In this test.tf file we have:
​ Two provider blocks
​ A variable block
​ An EC2 resource block
​ An IAM resource block
What we should do is split these blocks into their own relevant files:
​ We will put the provider blocks into a file called providers.tf (all provider blocks
would go here)
​ We will put the variable block into a file called variables.tf (all variables would go
here)
​ We will put the EC2 resource block into a file called ec2.tf (all EC2 resource
blocks could go in here)
​ We will put the IAM resource block into a file called iam_user.tf (all IAM resource
blocks could go in here)
​ We will remove the initial semantics.tf file

This leaves us with the below structure:

So if tomorrow there was a requirement to add another IAM User we could simply open
up iam_user.tf and add the code in.

This is good practice if you are not using modules. However if you are using modules
within you terraform config (as you should in most production cases) there is a different
practice.

Dynamic Blocks
These allow us to dynamically construct repeatable nested blocks, this is supported
within resource, data, provider and provisioner blocks.
What we mean by nested blocks is that these are not top level, for instance in the
example below the ingress blocks are nested within an AWS Security Group resource
block.

Let's say we are defining a security group and we need to define multiple ingress rules:

Here we only have two, but what if we needed 40 ingress rules to cover different ports?
That would require 40 different blocks with the current syntax/structure of the code.

So we can use a dynamic block instead:

You can see in the first block we have defined the variable "ingress_ports" this is a list of
ports.

The second block is a resource block for an AWS Security Group. Within that we have a
nested dynamic block of type "ingress".

Within the dynamic block we have "for_each = var.ingress_ports"

This syntax is basically saying "for each item in the list ingress_ports" which is the list
variable we have defined at the top.

So for each item in ingress_ports construct a new ingress inbound rule for the security
group with the following values defined with in content {}

from_port = ingress.value
to_port = ingress.value
These are dynamic values, an ingress resource will be created for every item in the
ingress_ports list. This ingress.value will represent each item in that list as it is iterated
through.
So for the first iteration ingress.value will be 8200, next it will be 8201, then 8300 and so
on for all the items in the list.

It might seem confusing that it is ingress.value and not ingress_ports.value. Doesn't the
value refer to the name of the list variable we have created? So why isn't it referred to
directly in the code?

Well the for_each = var.ingress_ports syntax essentially assigns the value on

each iteration through ingress_ports to the Dynamic ingress block itself, so the ingress
in ingress.value refers to the actual dynamic block the code is in rather than the variable
the value is pulled from.

You can change this through the use of iterator.

Notice how we define the iterator as port now instead of being ingress.value it is
port.value. This can make dynamic blocks easier to read and understand.
Finally the protocol and cidr _blocks will be the same for every ingress resource created
by the dynamic block so these can stay as static values.

So now if we ran terraform plan this one dynamic block will lead to 5 separate
ingress resources appearing in the plan. One for each port value in the ingress_ports list
variable.

What if you want multiple different dynamic values in one dynamic block? For instance
say we wanted to alter the port value and cidr_blocks value. We couldn't use a simple
list, but we could use a list of maps:

This way we can define the values like:

from_port = ingress.value["port"]
to_port = ingress.value["port"]
protocol = "tcp"
cidr_blocks = ingress.value["cidr"]

Terraform Taint
Lets say we create a new EC2 resource in Terraform then users make a lot of manual
changes both to the infrastructure and inside the server.
Now the EC2 resource will not match the Terraform code.

There are two ways to handle this:

​ Import the changes to Terraform
 ​ Delete and Recreate the resource

With the terraform taint command we can manually mark a Terraform-managed

resource as tainted, this will force it to be destroyed and recreated on the next apply.

eg. terraform taint aws_instance.my_ec2 note how this applies to a specific

resource rather than a whole template.

The terraform taint command does modify the infrastructure, it merely alters its
status in the state file to be 'tainted'. This marks it for destruction and recreation on the
next terraform apply.

Why use taint?

When a resource declaration is modified, Terraform usually attempts to update the
existing resource in place (although some changes can require destruction and
re-creation, usually due to upstream API limitations).
In some cases, you might want a resource to be destroyed and re-created even when
Terraform doesn't think it's necessary.

Note that Terraform Taint has been deprecated in v0.15.2 onwards, now the best
practice is considered to be using terraform apply with the "-replace" tag.

eg. terraform apply -replace aws_instance.my_ec2

Splat Expressions

Splat expressions (*) allow us to output attributes of multiple resources created by a

single block.

The code below creates 3 IAM Users through the use of count and "count.index".

Remember count specifies how many of a resource to make. "count.index" merely

represents the number of iterations so far : [0, 1, 2] in this case, so the AWS name for the
3 IAM resources will be iamuser.1, iamuser.2 & iamuser.3.

While the name in AWS will be iamuser.1 etc., the name we have given the resources in
Terraform is lb. So to refer to each IAM resource created by this block individually within
the Terraform code we would use lb[0], lb[1] & lb[2].
The second block of this code is the output block and this contains the splat
expression. We have 3 IAM resources created by the first block all with the name "lb". In
order to get the ARN (Amazon Resource Name) attribute for all three we could do:

value = aws_iam_user.lb[0].arn

value = aws_iam_user.lb[1].arn

value = aws_iam_user.lb[2].arn

Each line individually asks for the ARN of one of the IAM User resources we created.
However this is quite repetitive, and if we needed 3 or 4 attributes the number of lines
required would really add up.

So instead in the code we have used the splat expression * to essentially say give me
ARN of all the IAM User resources with the name lb.

value = aws_iam_user.lb[*].arn
No when we apply the code we will receive an output to terminal with the ARNs of all
three IAM resources we created in the first block.

Terraform Graph

The terraform graph command allows us to generate a visual representation of a

configuration or execution plan.

The output of this command is in DOT format which can be converted into an image.

Once you have your code written you can use terraform graph >
filnename.dot

You can then use graphviz to convert that file into an image.
Ubuntu graphviz installation: sudo apt install graphviz

You can also download it directly from the graphviz website on windows.

Example output of terraform graph in image format:

Saving Terraform Plan to File

You can save the output of terraform plan to a file.

Then you can specify this file when using terraform apply to be certain that only the
changes shown in the plan file will be made and no others.

Syntax:

terraform plan -out=filepath

Then to use the file with apply, be in the directory with your plan file:

terraform apply filename

Where "filename" is replaced with whatever you named your plan file.

This feature is very useful and often used in production when working with Terraform in
conjuction with CI/CD.
Terraform Output

The terraform output command is used to extract the value of an output variable
from the state file.

Lets use the splat expression example again:

When you run terraform apply on this it will create the resources but due to the
output block it will also output to terminal:

iam_arn = [

"arn:aws:iam::795574780076:user/system/iamuser.0"

"arn:aws:iam::795574780076:user/system/iamuser.1"

"arn:aws:iam::795574780076:user/system/iamuser.2"

]
Now what if you wanted to see this output again a few days later? Well for that you can
use terraform output:

terraform output iam_arn

This will print to terminal the exact same output as above.

Alternatives:

Alternatively to see the output again you could run another terraform apply as
even if there are no changes to make this command will still provide the outputs
specified in the code. Or you could directly look at the state file.

Terraform Settings

There is a special terraform configuration block type which is used to configure

behaviours of Terraform itself.
Terraform settings are gathered into terraform blocks:

The required_version setting specifies which versions of Terraform can be used with
your configuration. This means if the Terraform version used to run this code is not
compatible with this setting then Terraform will produce an error and exit without taking
any action.

Another useful setting is required_providers, you will have seen this one in this guide
multiple times already:
This specifies all of the providers required by the current module and maps each local
provider name to a source address and version constraint.

Handling Large Infrastructure

When you have a large infrastructure you will inevitably face issues related to API limits
for a provider.

To help solve this you can switch to smaller configurations which can each be applied
independently.

So instead of having one file containing all your VMs, DBs and Security Groups,
Networking infrastructure etc.

You can actually split this out into separate .tf files where each can be independently
applied.
Example of smaller config benefits:

For example when you use terraform plan the command has to refresh the state of
each physical resource in the config file from your provider's API to see if any changes
need to be made.

Now say you have all of your infrastructure in one big .tf file. You make some changes
to the EC2 instances and nothing else, well now when you use terraform plan
Terraform still has to request the state of every resource in that file from the provider
API, not just the EC2 instances.

If instead you had split out all the resources into appropriate files and the needed to
make EC2 changes. Then you can go into ec2.tf (or whatever you named it) and make
those changes, now when you can run terraform plan ec2.tf and Terraform will
only have to request the state of the resources in ec2.tf, which is far less API calls.

Specify the target resource type to update:

If you do have a really large config file then you can use the target flag to specify the
resources you want refreshed:
Syntax: -target=resource

For example:

terraform plan -target=ec2

This will allow you to operate on an isolated portion of a very large config file. With this
flag the terraform plan command will only refresh the state of the EC2 instances.

Prevent refresh altogether:

You can use the refresh flag to prevent terraform plan refreshing the state of
resources when making a plan. This will do an "update in place"

syntax:

terraform plan -refresh=false

You can use this when you want a plan but don't need to refresh the state of the
resources.
Important for the exam to note is that when you do this the resources in the plan will be
preceded by a yellow tilde mark ~

This tilde mark lets you know that the resources have been updated in place and not
refreshed.

Zipmap Function

The zipmap function constructs a map from a list of keys and a corresponding list of
values.

List of Keys List of Values Zipmap

pineapple yellow pineapple=yellow

orange orange orange=orange

strawberry red strawberry=red

An example of this in action:

Here you can see we are making use of the terraform console command which
allows us to test Terraform functions in the terminal.

We have provided zipmap with two lists as in the table above. It has then "zipped" those
two lists into a map of key-value pairs.

Example of real usage:

1. We have the below code which constructs 3 IAM Users and then outputs the ARN and
Name for each of them:
2. When we run terraform apply we get the following output:
As you can see this gives us two lists, one list of the IAM Users ARNs and a second list
of IAM Users Names

3. What we can do instead is combine these outputs into a Map with zipmap:

Notice how we have replace the two original output blocks with just one. Where we have
used zipmap on the original two values.

4. The output of this is:

Now we have both the ARNs and Names of each resource mapped to each other in one
simple output.

Terraform Provisioners

Up until now all examples and information have centred around creation and destruction
of infrastructure scenarios.

Lets say we create an EC2 instance with Terraform, it is just an instance and nothing
else. What if we want to have software installed on it automatically?

Provisioners are used to execute scripts on a local or remote machine as part of

resource creation or destruction.

For example:
We can code in our config file that when we create a new EC2 instance, Terraform
should also execute a script which installs Nginx web-server.

Types of Provisioners:

There are two main types of provisioners: local-exec and remote-exec.

Local Exec:

These allow us to invoke local executable after a resource is created, what this means is
that a local-exec provisioner can run an executable (command) on the machine that is
applying the Terraform (local):

In this code we are creating an EC2 instance and within the EC2 resource block we have
a Provisioner block. This is a local-exec provisioner that will run a command that places
the Private IP of the instance created by the resource block in a file on the local machine
called private_ips.txt

This is what a local-exec does, it allows Terraform to run commands on the machine
that is applying the Terraform.

Local provisioners are really powerful and one of their most important uses is to run
ansible playbooks once resources have been created.

Remote Exec:

Remote-exec provisioners function very similarly and allow us to invoke scripts directly
on a remote server.
Implementing Remote-Exec Provisioners

Below is an example of the code you would use to have a remote-exec install Nginx on
an EC2:

This code has 3 blocks: A resource block, a nested provisioner block and a nested
connection block. Nested meaning that they are within the resource block.

​ Resource Block - This is pretty standard from what we've seen so far. It does
however have the addition of key_name. This is because remote exec requires
access to the EC2 being created, it can either do this with a user, password or via
 an access key pair over SSH. We are using the latter and so the resource block
needs to know the key name we are using. This is just the name of the key pair
within AWS:

​ Provisioner Block (nested) - We have specified this as a "remote-exec" provisioner

block, this is the block that will run our remote commands. Then we are using
"inline []" this allows us to specify a list of commands to be run by the provisioner
on the EC2 we are creating. These commands should be listed in order and you
can see we have 2 commands: 1 to install Nginx and 2 to start Nginx.

​ Connection Block (nested) - This is the block that specifies how the provisioner
block should connect to the EC2 instance. Within this we have 4 elements
defined:
​ type = "ssh" - We want to use SSH to connect
​ user = "ec2-user" - Every Amazon Machine Image has a
default user. With the Linux AMI we are using the default is
"ec2-user", it defines what user the remote-exec should run
commands from.
​ private_key = file("./TF-keys.pem") - We use this to
tell the connection block what the access key is to the EC2. When
you create a key pair within AWS it automatically gives you .pem file
with your keys. We have put a copy of this file in the same directory
with our TF config files. Now we can use the file command with the
 filepath of "./TF-keys.pem". This access key is used for all EC2s on
the AWS account.
​ host = self.public_ip - This tells the provisioner the
address of the instance we want to connect to. Connection blocks
can use the method self to refer to the parent resource block. So
this basically says the host address is the public IP of the parent
resource of the connection block.

If you run terraform apply with the above code it will create an AWS EC2 Instance
and then proceed to install Nginx and start Nginx up. If it loops when "connecting to
remote host via SSH" and never connects this is likely because you haven't configured
SSH on port 22 to be open in your EC2s security group, you can do this manually in the
AWS console if just trying to get this example to work.

Creation Time & Destroy Time Provisioners

Creation-time provisioners are only run during creations, not during updating or any
other lifecycle. If a creation-time provisioner fails, the resource is marked as tainted.
This means that the next time you run terraform apply the resource parent of the
provisioner will be destroyed and recreated to try and fix the issue.
Destroy-time provisioners are run before the resource is destroyed.

The code below shows an example:

Here we are creating an EC2 resource with two remote-exec provisioner blocks. One is a
standard creation-time and the other is destroy-time. Upon running terraform apply
this EC2 resource will be created and then the provisioner block will install Nano on the
EC2 instance.
The when within the destroy provisioner allows us to specify that it is a destroy-time
provisioner. If this is not included it is assume the provisioner is creation-time.

When we then run terraform destroy it will first remove Nano before destroying the
instance.

Note that below these two provisioner blocks is also a connection block that isn't
shown.

On failure:

You can use on failure in creation time provisioners. It essentially gives the code
instructions on what to do if the command fails:

on_failure can either be set to continue or fail. If it is set to continue then even if this
code failed to install Nano the resource will not be marked as tainted and will carry on
as normal. If it is set to fail then the normal behaviour of marking the resource as
tainted will occur, fail is the default if not specified.

The DRY Principle & Modules

In software engineering don't repeat yourself (DRY) is a principle of software

development aimed at reducing repetition of software patterns.

Terraform helps us be DRY by using modules. Modules allow us to centralise the

structure of resources so we can call them into our config files easily. For instance you
will have seen in this guide that we have used the same EC2 resource block many times
in different files.

Here is an example EC2 resource block with tags and a security group specified:
Rather than including the above in every single config file we create we can instead put
this code in a central location and call it in a module to be used in any tf file we want.

Lets say we put the above code in a directory called ec2 and that in a directory called
modules (the names aren't relevant). Then we can call it in another file like so:

Modules are just a centralised source where code is defined for resource blocks. These
can then be used in multiple Terraform projects. In this way we don't have to write out
the same resource blocks over and over again in each project.
This is different to count as count allows us to avoid repeating ourselves within a config
file and modules allow us to avoid repeating ourselves between two or more different
projects (different sets of infrastructure or environments).

When you use modules in a project you will need to use terraform init to install
those modules in the project. This is because the modules you create you will store in a
central source which is a separate directory or remote repository to the project you'll be
working on.

Variables and Terraform Modules

It is common in infrastructure management to build multiple environments, eg. one for

staging, production, testing etc. With these you will want a similar setup but will want to
change some variables.
For example in your staging environment you may want a small EC2 instance, but in
your production you may want a large EC2 instance.

If you have hardcoded details in your module you will not be able to change it within a
project you use it in:

Lets say we have 'Project A' and in Project A we use the above module. This EC2 module
is a t2.micro, within Project A there is nothing we can do to change that. We can not
specify a different instance size as it is hard coded into the module.

However we can use variables within modules which we can then alter from within
Project A:
Here you can see we have now changed the EC2 module to have instance_type set to a
variable called type_of_instance.

We have also created a separate file within the same directory as the EC2 module called
variables.tf. Within that we have given a default value to the type_of_instance variable in
case the user does not specify:

Now within Project A when the user calls this EC2 Module they can specify the variable
value within the module block:
Now if we ran terraform plan we would get a plan output for an EC2 instance of
type t2.large but where all other details specified in the EC2 module are the same.

Terraform Registry & Modules

The Terraform Registry has a library of pre written modules that you can browse. So
rather than writing one from scratch you can look for a module on the registry that is a
close fit and alter it to your liking. The majority of these are community modules written
by the community.

The registry also has verified modules which are maintained by third party providers like
AWS, Azure etc.
Terraform Workspace

Terraform allows us to have multiple workspaces, within each workspace we can have a
different set of variable values. You can have the same infrastructure in two different
workspaces and each workspace would be isolated with its own variable values.

For instance you could have the variable type_of_instance.

Then if you have two environments put in two workspaces:

Workspace A - Staging Environment: type_of_instance = t2.micro

Workspace B - Production Environment: type_of_instance = t2.large

Workspaces allow you to have the same variable set to different values dependent on
the workspace you are in. In the above example the value of type_of_instance changes
dependent on the workspace that it is in. So if we were in Workspace A , then when we
ran terraform plan it would plan to create an EC2 of type t2.micro. Whereas in
Workspace B it would create one of type t2.large.
Terraform Collaboration | Remote Repositories

Most enterprise usage of terraform will involve collaboration through a central GIT
repository like GitHub or GitLab.

When sharing Terraform code it is never a good idea to push your .tfstate files to a
remote repository as they often contain sensitive information.

Source Argument:

You can use Modules collaboratively through remote repositories using the source
argument of the module block:
The source argument can either be for a remote or local module. In the above code the
source we are using is for a remote GitHub repository. Note that when using a git
repository URL whether via SSH or HTTPS the full format is for the URL to be preceded
by git::. However Terraform is smart enough to understand it is a git repo even if
this is left out.

Ref Argument to pull specific branch:

When using a git repository it is also possible to specify which branch you want to pull
as a source through the ref argument:

Terraform & .gitignore:

You may want to ignore the following files when adding your Terraform code to Git:

​ Terraform directory itself as this is created when terraform init is run.

​ terraform.tfvars which is likely to contain sensitive informaiton. However this is
dependent on how you have set it up.
​ terraform.tfstate secrets (passwords, keys) are stored in plain text in the tfstate
file so you don't want to commit them.
​ crash.log
Terraform Remote Backend

Terraform has a feature called remote backend which can be used to store a tf state file
if you need to do remote state management. This will allow you to refer to a remote TF
State file within your terraform code. For example you can store your state file in an S3
Bucket.

This is useful as it means that everyone in a team can work with the same state file.
This prevents unwanted issues like two people working with slightly different state files
or trying to perform a Terraform Apply at the exact same time and breaking the
infrastructure.

With one shared state file every time an apply is done the state file is locked so two
apply processes can not be run at the same time.

Using a remote backend for state files is the recommended process for collaborative
environments. Nearly all businesses using Terraform use remote backend for state files.
Below is an example of the code you might use to establish an s3 remote backend for
your Terraform state files.

State Locking

Whenever you are performing a write operation Terraform locks the state file. This is
extremely useful when collaborating on Terraform in a team.

This is important as during an ongoing terraform apply if others also do an apply it

can corrupt your state file.
 ​ For example Person A is terminating an RDS resource which has an associated
rds.tfstate file
​ Person B is also at the same time trying to resize the RDS resource.

This will cause issues in the tfstate file which may lead to corruptions. For this exact
reason during a terraform apply the state files are locked so two contradictory
actions cannot be run at the same time.

This is also why it is important to have a shared remote backend for state files when
working as a team. This way everyone works off the same state files rather than local
copies, so if an apply is occurring the one state file the entire team uses is locked until
the apply is done.

When using a remote backend you will need to create a lock for the Terraform to use.
This can be done in AWS with DynamoDB, if this lock is not created then there can still
be issues with simultaneous applies and corruptions
Terraform State Management

There may be some cases where we need to modify the Terraform state. It is important
to never modify the state file directly, instead we can make use of the terraform
state command.

The terraform state command has multiple sub commands:

Sub Command Description

list List resources within the Terraform state file

mv Moves item with terraform state (can use for renaming)

pull Manually download and output the state from remote state

push Manually upload a local state file to remote state

rm Remove items from the terraform state

show Show the attributes of a single resource in the state

Using Terraform Import

There may be a time when there is a resource which has already been created manually
and not in Terraform. If we wanted to change something in that resource we would have
to do it manually.

Ideally we can bring that existing resource into infrastructure as code.

To do this we can use terraform import

However this command will only create a state file for the manual resource it will not
create the .tf file so we can edit the code in future.

To use terraform import correctly we have to write the Terraform code for the manual
resource in a tf file ourselves and then link that code to the manual resource when we
use terraform import.
Terraform Cloud

Terraform Cloud manages "Terraform runs" in a consistent and reliable environment

with various features like access controls, private registry for sharing modules, policy
controls and others.