Getting Terraform Certified

Over the last 3+ years I have been working in the cloud. Most of this time has been spent in Azure, with about a year in GCP and Azure. Because of the need to operate in both of these clouds, I did not want to rely too much on tools dedicated to one specific cloud provider, like Azure Resource Manager or Cloud Deployment Manager.

Enter Terraform.

Terraform is a cloud agnostic Infrastructure as Code language developed by HashiCorp to simplify resource configuration and allow the code for infrastructure to be stored in GitHub or another source control solution.

Terraform is more multi-cloud ready than specifically cloud agnostic, simply pointing an existing terraform file for Azure at GCP will not generate resources, but Terraform can operate in any of the major public cloud providers and in On-Premises VMware environments as well.

The Certification process

When I first started with Terraform, there was a good amount of review of the documentation ( and even more trial and error.

Working with terraform in small bite-sized chunks to do simple tasks was definitely helpful.

For example, the first bit of terraform I ever tried was simply to create a resource group in Azure. Something that wouldn’t be a big deal to play with and also would not cost a load of money to build and rebuild.

Keep things simple at first

Building resource groups was something I used to get used to the syntax and I put everything in a single file just to see what things looked like.

terraform {
required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=2.46.0"

Provider "Azurerm" {
	Features {}

Variable "rg_name" {
	Default = "my_resource_group"

Variable "rg_location" {
	Default = "eastus"

Resource "azurerm_resource_group" "rg" {
	Name = var.rg_name
	Location = var.rg_location

After building this out a few times, the next problem to solve was to split up the single file into three files:

  • terraform { required_providers { azurerm = { source = “hashicorp/azurerm” version = “=2.46.0” } } }

    Provider “Azurerm” { Features {} }

  • Resource “azurerm_resource_group” “rg” { Name = var.rg_name Location = var.rg_location }
  • Variable “rg_name” { Default = “my_resource_group” }

    Variable “rg_location” { Default = “eastus” }

This was more along the lines of what the documentation suggested. Keeping providers and backends for state in the file, the resources being created in the file and then any variables used in

Note: Now that I have been using terraform a bit, I tend to create a file for each resource I am going to build. I like to keep my code short and easier to review/maintain in the event others need to assist. Having a file for each resource helps keep things clean. Generally, I use for locals keeping them separate from resources being created. This is not a requirement, but is a personal preference for me.

Once the files were split up, the planning and apply process started again - build a resource group and destroy it to make sure that your code still works after the changes being made.

More useful things

As time went on, I started building Azure Key Vault resources within resource groups. Because I was working on other cloud items and supporting teams as well, I think I built and rebuilt and rebuilt a key vault script in terraform more times than I care to admit. Interruptions were something that caused me a good deal of stress for a while because I was trying to get the hang of something new and it was taking forever.

Note: Repetition is good, but repetition with little progress can just be disheartening. Do yourself a favor and store your code somewhere - in git or on a network drive for reuse later.

At this time I had not thought much about certification in terraform, just wanted to get an entire solution to build from front to back that was useful.

I was using it every day, mostly in Azure and a little bit in GCP, but spent more time working on things outside of IaC - as this went on, I got away from terraform.

This was a good break

I did not see it at the time, because I was frustrated that I couldn’t seem to learn terraform fast enough. Take your time when learning Terraform  is the lesson there. The break kept me interested enough where I did not get burned out, even though I did not think so at the time.

As time went on, I got more time to focus on terraform and one cloud (Azure). This moved me into a position of writing terraform code everyday and building real things with Infrastructure as code.

My code was landing in infrastructure specific repositories in GitHub and then I was leveraging terraform cloud to watch these repositories and build new things as files were changed. This made code repeatable from a deployment standpoint, but I was still creating resources for projects.

More practice and modules

To reduce the time it took to create things in terraform I started creating modules for resources - some simple, like resource groups and some not so simple, App Services and App Service Scale settings.

Modules were golden for me - they helped cement learning the more I wrote them and reduced the write/re-write things I had been experiencing because they were reusable.

All of this work brought confidence to my terraform skills and helped me to decide that maybe certification was within reach.

Rather than taking a course and reading all the documentation again and again, using the language more and more before any official studying was a good thing.

Once the exam was booked, I wanted to make sure I was not missing anything, I took a course on Pluralsight and a course on to just see if there was anything I did not know. Once I took that course all that was left was the exam and the bit of nerves that come along with testing.

Test Day

With the onslaught of Covid and the closing of many things, I had to take the terraform exam via a proctored session. I think Hashicorp does a lot of their certifications online, and the actual exam was fine, but the lead up on the morning of the test was not the greatest.

There were about 50 questions on the test when it finally got going, after a room scan and a late start from the proctor within the testing app. I believe I spent about 37 minutes answering questions. They were challenging but not impossible and as long as you review the guidelines as far as which versions of terraform will be covered on the test you will do just fine if you are comfortable with your terraform skills.


  • work with terraform doing both simple and less simple things
  • work with source control to build your skills with the tool and ensure your terraform code is kept somewhere
  • use the documentation as a reference to lookup concepts you might need to learn - reading it end to end is not required
  • ask others on your team or in your network for help if you need it
  • take your time and get comfortable with the tech before scheduling the test
  • once you are mostly comfortable, schedule the test
  • review content online, in the documentation, or from others on your team covering things you need to shore up before the test

If you take your time and prepare you can pass the terraform exam with most of your prep coming from everyday use.

Also - this is the process that I used to get certified, you may need to modify this approach somewhat to find something that works for you.

Good Luck!

Written on August 28, 2021