Gain insights into Infrastructure as Code with Terraform, sharpen your skills, and prepare for the HashiCorp Terraform Associate certification in a cloud-agnostic way.

HashiCorp Terraform Certified Associate Preparation Guide.png

Terraform_e.tar.gz

access_key_id

secret_access_key

init

validate

config

needed-copy

not-needed-copy

needed-copy-copy

This course is designed to help learners obtain the Terraform Associate certification from HashiCorp. 

You’ve likely picked up this course because you dabbled in Terraform as a hobbyist or in a
development environment, and you’re excited about the possibilities of deploying Infrastructure 
as Code (IaC). It will enable you to sharpen your skills and prove your knowledge with a certification from HashiCorp. Terraform is an amazing tool to deploy Infrastructure as Code in a cloud-agnostic way. We’re excited to share our accumulated knowledge with you through this course.

HashiCorp Terraform Certified Associate Preparation Guide

HashiCorp has identified a core workflow composed of three parts:


* **Write**: Author infrastructure as code
* **Plan**: Preview changes before applying
* **Apply**: Provision reproducible infrastructure



# Write

## Editor

Writing IaC is just like writing any other piece of code. Typically, we write in some type of integrated development environment (IDE) or advanced text editor. The purpose of those applications is to provide us with syntax checking, source control integration, and perhaps even shortcuts for creating common Terraform constructs.

## Language

The code we’re writing for Terraform is either in HashiCorp Configuration Language (HCL) or in JavaScript Object Notation (JSON). It’s far more common to write in HCL because it’s simpler for a human to write and read.

## Source control management

The code we write will often be checked into some type of source control management (SCM) repository, where it can be versioned and changes are tracked. This isn’t a strict requirement, but it is a best practice. Whenever we start a new project in Terraform, we first create a source code repository to commit our code. This tracks changes, backs the code up outside of our computers, and versions so that we can roll back when we mess something up. Using source control becomes even more important when working on a project as a team. Different team members may be working on different parts of the same configuration, and they can use branching and pull requests to prevent the main branch from being corrupted.

## Code validation

Terraform code can be validated for syntax and formatted properly before reaching the plan stage. Doing so ensures that simple syntax and logic errors are caught and that our code is formatted consistently with other existing code. It sounds minor, but consistent formatting is very important.

# Plan

## Purpose

During the planning process, we check to see what changes our code will make in the target environment. We might know the desired end result, but few of us get it right the first time. The planning process allows us to test our changes and ensure that the changes we had in mind match up with the reality of what Terraform will do.

## Change management

During the writing process, we often run `terraform plan` to preview changes and make sure we’re on the right track. By doing so iteratively, we can ensure our configuration remains valid through each small change. Attempting to write a big change into a configuration is a common mistake, often resulting in hours of extra troubleshooting. We can save ourselves a lot of time by keeping our changes small and making sure that the plan is valid on a rolling basis.

Each time we run a plan, we have the option to save the proposed plan to a file. We’ll review that option when we dig deeper into the `terraform plan` command. When we’re sure that our configuration is ready to deploy, we can run `terraform apply`, which shows the proposed changes once more and asks for approval to implement the change.

# Apply

The last step in the workflow is to apply the updated configuration to the target environment.

## Commit changes

With a successful application of the new configuration, it’s also a good time to commit changes to source control to ensure they’re not lost.

## Reiterate

Then, it’s time to begin the process anew! Infrastructure requirements are constantly changing, and we need to keep altering the configuration, planning its changes, and applying them to the target environment. It’s a cycle of continuous improvement, just like any other software development lifecycle.

# Key takeaways

To deploy IaC and keep it up to date with requirements, the workflow in Terraform follows these three stages in succession: write, plan, and apply.


Introduction to the Course

Introduction to Infrastructure as Code

Basics of Terraform

Outside the Workflow: Using the Terraform CLI

Terraform Modules

Navigate Terraform Workflow

Implement and Maintain State

Read, Generate, and Modify Configuration

Understand Terraform Enterprise Capabilities

Conclusion

Terraform Workflow

Write

Editor

Language