Terraform Associate Certification Guide & Notes

Cloud engineering teams are increasingly using infrastructure-as-code (IaC) tools to deploy, operate, and update their cloud infrastructure. HashiCorp’s Terraform is one of the most widely used IaC tools on the market today. HashiCorp offers the Terraform Associate certificate to cloud professionals looking to show their proficiency with this awesome tool. 

This guide is for everyone who wants to pass the Terraform Associate certification exam. The guide contains the following contents:

• Exam Details

• Certification Prep Resources

• Certification Requirements and My Notes

Exam Details

You can find full details for the exam on HashiCorp’s site. Here is a high level summary of the exam details:

• Assessment Type: Multiple choice

• Format: Online proctored

• Duration: 1 hour

• Price: $70.50 USD (Plus local taxes and fees. No retake included)

• Language: English

• Expiration: 2 years

Certification Prep Resources

There are many good certification prep resources online. This site, skillmix.io, has an excellent Terraform certification course that covers all of the exam contents. It also provides real AWS account lab environments for you to practice on.

Aside from Skillmix, Udemy has a collection of reputable courses you can search through. Bryan Krausen’s courses are always rated well!

Certification Requirements & My Notes

On HashiCorp’s Terraform Associate exam page, they have a table that defines 9 major sections and subtopics. This is a great place to start. Below are my notes for each major section and subtopics. 

1. Understand infrastructure as code (IaC) concepts

You should be able to explain what Terraform is, and the core value proposition of infrastructure as code (IaC) tools like Terraform. 

Terraform is an IaC tool that lets you define cloud and on-prem resources in human readable confg files. You can then use a workflow using the Terraform CLI to provision and manage infrastructure.

The benefits of Terraform are:

• Manage any infrastructure: Find providers for clouds like AWS and Azure, and hundreds more on the registry. Create your own provider as well.

• Track your infrastructure: Generate a change plan and review before committing changes. Terraform tracks infrastructure in a local or remote state file, that is the single source of truth. 

• Automate changes: Terraform configs are declarative; they define the end state of infrastructure. Terraform handles the underlying logic to create the defined infra. It also create a resource graph to handle dependencies (a create/update order).

• Standard configurations: Easily create modules that define one or more collections of infra resources. Save and use many times.

• Collaborate: Configuration files can be saved to version control or online services like Terraform Cloud. State can also be saved in a remote location for multiple editors to use.

• Community: Terraform is open source and has a robust developer community.

2. Understand Terraform's purpose (vs other IaC)

You need to understand Terraform’s purpose within the IaC and other automation tools landscape. Here are some notes for this requirement:

• With Terraform, you learn one language (HCL) and one CLI (Terraform CLI) and you can work with multiple clouds

• Terraform is provider agnostic; there’s support for all major clouds and many SaaS and API products

• Terraform is a declarative language for infra resources; it is not an all purpose automation tool

• Tools like Chef and Puppet are better are some tasks than Terraform, like installing applications and running scripts

• You should use Terraform to define infrastructure, and other tools to automate post-resource creation activities

• Terraform state is useful because it provides a point in time copy of the real-world infrastructure that the tool can manage

3. Understand Terraform basics

Here are my notes about the “Understanding Terraform basics” requirement:

• Terraform configurations are written in HashiCorp Configuration Language (HCL)

• Terraform configurations are evaluated, managed, and applied using the Terraform CLI

• Terraform saves a real world infrastructure mapping in a state file. The state file can be local or remote

• Terraform has a provider plugin model. A provider is something like a cloud platform, like AWS or Azure. Can also be SaaS providers and other APIs. Providers define resource types and possibly data sources that Terraform can manage

• There are a large number of providers in the public Terraform registry. Providers are installed if they are defined in a project. You have to specify the version of the provider

• Terraform is split into Terraform Core, and Terraform Plugins. Anyone can write a provider plugin. Terraform Core communicates with Plugins via Remote Procedure Calls (RPC). Plugins are written in Go lang. Plugins expose an interface for a service, such as AWS. There is a defined plugin protocol for writing them

• Terraform reads the plugins in the configuration files when running terraform init command, and will download them locally for use

• Terraform has the concept of provisioners. Terraform now says “Provisioners are a last resort”. It recommends against them because they can have side effects that aren’t represented in the Terraform config and state

• That said, there are the local-exec and remote-exec provisioners. The local-exec provisioner invokes a local executable on the machine running Terraform (not on the remote machine). The remote-exec invokes a script on the remote resource after it is created

4. Using the Terraform CLI (outside of core workflow)

Terraform has what’s called the “core workflow”. The core workflow is “write, plan, and create”. There is another exam requirement that dives deep on this workflow.

For this exam requirement, it is expected you understand several other Terraform CLI commands that are not part of the core workflow. 

Those commands are:

• terraform fmt: This command will format any file ending in .tf with a common format and style. By default it only works on files in the current directory. Can run terraform fmt -recursive to process files in subdirectories

• terraform taint: This is a deprecated command. It was used to manually mark a resource as “bad”. Terraform might also automatically detect a resource is tainted and mark it as bad. Starting with v0.15.2 and later, Terraform recommends using the terraform -apply -replace=”resource.name” command to replace a resource that is “bad”

• terraform import: This command can import an existing resource into a Terraform project. This command will only import to state; you have to also write the configuration of the resource in your config files

• terraform workspace: This command lets you create separate instances of state inside the same Terraform working directory. It’s like having multiple instances of the same Terraform project. You can use workspaces to create a parallel copy of resources to test changes on before deploying to production. Not suitable for everything; complex projects, or environments with strong controls between lifecycles like dev, staging, prod might need a different solution. 

• terraform state: Used for advanced state management. In some instances you might need to modify it. Don’t edit the state file. Use the CLI command. There are two branches of this command: read subcommands like list and show, and change commands like mv and rm. 

• Understand and configure logging: Enabling detailed logs in Terraform can be done by setting the TF_LOG environment variable to any value. This will cause the logs to be displayed on stderr

5. Interact with Terraform modules

Terraform modules are containers for multiple resources used together. They are a way to package and reuse configurations. You can create your own modules, or use third party modules. They can be a way to streamline your Terraform projects.

Here are some notes:

• Modules can be sourced from different locations (docs):

  • On the Terraform Registry. Free to use. Anyone can publish if they follow certain guidelines

  • Local paths e.g. path within the directory of your Terraform project

  • Hosted git services GitHub, Bitbucket

  • Generic git and Mercurial repos

  • HTTP URLs

  • S3 buckets

  • GCS buckets

• Modules can take in inputs and define outputs

  • Inputs are variables that need to be passed into the module

  • Outputs can be defined to pass resource attributes up to the parent module

• Module version can be set using the version attribute

6. Navigate Terraform workflow

You’ll see the “Terraform workflow” referenced in their docs and on the exam. It is the process of:

1. Writing terraform configuration files (and initializing a project on first go)

2. Running terraform plan to see what the proposed changes are

3. Running terraform apply to apply the changes

Some additional notes:

• To initialize a directory, run terraform init. Any time you add a provider you have to run this again to download the provider

• Run terraform validate to check if your code is valid Terraform code. Checks if the configuration is syntactically valid and internally consistent.

• Run terraform plan to generate and review an execution plan. Shows a list of resources, changes to be made such as additions, deletions, ec.

• Run terraform apply to execute changes on the provider and configuration 

• Run terraform destroy to destroy managed infrastructure

7. Implement and maintain state

Must have knowledge of Terraform state. Here are the exam requirements notes:

• The local backend is the default. It saves the state file in the working directory of your project. You can also specify a path to the local state file (Docs).

• If supported by your backend type, Terraform will lock the state file to prevent multiple people (or automations) from writing to it at the same time. State locking happens automatically on operations that could write state (e.g. terraform apply, terraform state mv, terraform state rm). You can override with -lock, but not recommended. The local and Consul backends support state locking (not all remote states do)

• There is a long list of remote backends you can find here. Be familiar with this list. Common ones are s3, azurerm, consul, gcs, http, pg, kubernetes, oss

• When using a remote backend, there is no local state file in your directory. All state is saved at the remote location

• The terraform refresh will reads current state of all remote managed resources and updates the Terraform state to match. This command is deprecated. Instead, you should use terraform apply -refresh-only

• State file can be stored remote as well. You specify what kind of backend you want within the terraform { backend {} } block. A Terraform project can have only one backend

• If you do use a remote backend, you have to still ensure that a locking mechanism is in place. If the remote backend type doesn’t support it, you’ll need to create another method

• Remote state files will likely require credentials to access the remote system. It is recommended that you use environment variables to reference these credentials. If you put them in the Terraform configuration, they could be leaked

• If you change a project’s backend, you have to run terraform init again

• Terraform state files can store sensitive data such as resource IDs, attributes, and even database passwords.

  • Local state files are saved in plain text

  • Remote state files can be encrypted; depends on the remote type

  • If you store any sensitive data in the state file, treat the state file as sensitive data

  • Storing state remotely can help secure it (if you set proper security measures)

8. Read, generate, and modify configuration

You must know how to create, read, and update Terraform configuration files. Here are some notes and references on the matter:

• Variables are parameters passed into a Terraform module. This could be the root module, or child module. These are different types of variables. They can have default values, or be set at runtime. Block is: variable “name” { type = “” default = “” }

• Output values are values from your infrastructure and are made available on the command line output. You can also use output values in other parts of your code. You can also reference output values in remote state files. Block is output “name” { value = “” }

• You can suppress variable output to the CLI using the sensitive = true argument in the variable block.

• Variables have different types. The simple types are: “string”, “number”, and “bool”. There are also complex types: “list”, “set”, “map”, “object”, “tuple”. Should be familiar working with these

• The resource block is used to define infrastructure resources like virtual servers and storage. The provider defines which resources are available, and what the configuration options for them are. Refer to docs to see how to create a resource. You should be extremely familiar with writing and configuring resources. (source)

• The data block is used to read information defined outside of Terraform. For example, if you already have a VPC configured on an account you can read the values of it and use it in your project. The provider also has to determine what data sources are available, and what their configuration is. (source)

• Terraform has a resource address scheme:

  • A resource addresses is a string that identifies the resource in your configuration

  • The address has two parts: [module path][resource spec]

  • The [module path] part: module.module_name[module index]

  • The [resource spec] part: resource_type.resource_name[instance index]

  • The [module index] and [instance index] are used if the is more than one instance of the module or resource you’re deploying

  • You use these addresses a lot to connect resources together

• Terraform has a lot of built-in functions. There are function sets for: number, string, collection, encoding, filesystem, dat and time, hash and crypto, IP network, type conversion. You can’t write your own functions. Be familiar with them. (source)

• Some resources have repeatable nested blocks, like settings blocks. You can use the dynamic block to iterate over a complex value to generate one or more nested blocks. (source)

• Terraform maintains a dependency graph. This graph is used to determine which resources in a project should be created or updated first. This is done automatically. You can also use the depends_on argument to manually set a dependency

9. Understand Terraform Cloud and Enterprise capabilities

Terraform has an open source version which is free. They also have paid-for products. It’s expected you understand some basic info about the paid for products:

• Sentinel

  • Create policy rules that are enforced on Terraform runs

  • Uses the Sentinel policy language (source)

  • Can be configured on Terraform Cloud

• Terraform Cloud

  • Automatic backup of your state files

  • Version control, keeping track of all the changes to your config file and allowing you to revert to a previous version in case something goes wrong

  • Access Control, allowing you to control who has access to run actions that can modify the state file

  • Visibility into who applied what changes to the configuration

  • Also has the concept of workspaces. This is not to be confused with the Terraform CLI workspaces

• Terraform Enterprise

  • Control access to configuration files

  • Set up a private instance of Terraform Cloud with dedicated support from HashiCorp

  • Advanced security compliance and role-based access control

  • Dedicated support

If you like this guide, please follow me on Twitter at @tobias_on_cloud