The terraform certified study guide

As I mentioned in a previous post, HashiCorp has officially announced the availability of two certifications, Terraform Certified Associate and Vault Certified Associate. In that post I detailed a bunch of different resources to help you study for the Terraform exam. One of those resources was a study guide that Adin Ermie and I put together called the HashiCorp Terraform Certified Associate Preparation Guide, which does not lend itself well to an acronym - HTCAPG? I guess we could go with Hat Cap? Nah. Anyway, I thought I would give you an idea of what is in the guide, and a free sample of a few pages.

The Guide

The certification is broken into a list of high-level objectives. Each of the high-level objectives is composed of enabling objectives. There are nine high-level objectives in total, and so Adin and I chose to dedicate a chapter to each objective. Within each chapter is an introduction, and then a section dedicated to each enabling objective. At the end of each section is a Key Takeaway for that enabling objective to help you focus on what was most important. At the end of each chapter is a list of the Key Takeaways for each section, so you can quickly reference them when preparing for the exam.

The whole point of the guide is to help prepare you to take the exam. It is not meant to teach you Terraform from the ground up. We assumed that the reader would already have a passing familiarity with Terraform, and was looking for a resource that would help them focus their studying on what would actually be in the exam. I think we were fortunate that HashiCorp chose topics that were practical and useful in day-to-day Terraform operations and not esoteric arcana pushed by a marketing group with an agenda. This was an exam clearly steered by SMEs and boots on the ground operations people. I know since I was a contributor to the exam.

Let’s take a closer look at a typical chapter, starting with a favorite of mine - chapter 5, which deals with the high-level objective: Understand Terraform Basics.

Introduction

Here’s the intro to the chapter:

Before you can get started with Terraform, you’ll need to install it somewhere. You also can’t do a whole lot without using the various and sundry providers that enable Terraform to talk to cloud providers, platform services, datacenter applications, and more. We’ll also touch on provisioners, and when to use them. You might find the answer counterintuitive!

Solid. We get an overview of what’s in the chapter. If you’re feeling pretty competent in this topic, you could skip it. But what about that mention of provisioners? You might decide to jump to the section entitled: Explain When to Use and Not Use Provisioners and When to Use Local-Exec or Remote-Exec.

Enabling Objective

Let’s see what’s in that provisioners section:

When a resource is created, you may have some scripts or operations you would like to be performed locally or on the remote resource. Terraform provisioners are used to accomplish this goal. To a certain degree, they break the declarative and idempotent model of Terraform. For this reason, HashiCorp recommends using provisioners as a last resort only.

That probably bears repeating, because HashiCorp has changed their stance over time on using provisioners. We can’t guarantee any particular question will be on the exam, but HashiCorp seems to feel passionately about this. To repeat:

Don’t use provisioners unless there is absolutely no other way to accomplish your goal.

Use cases

What are the use cases for a provisioner anyway? There’s probably three that you’ve already encountered, or will in the near future.

• Loading data into a virtual machine
• Bootstrapping a VM for a config manager
• Saving data locally on your system

The remote-exec provisioner allows you to connect to a remote machine via WinRM or SSH and run a script remotely. Note that this requires the machine to accept a remote connection. Instead of using remote-exec to pass data to a VM, use the tools in your cloud provider of choice to pass data. That could be the user_data argument in AWS or custom_data in Azure. All of the public cloud support some type of data exchange that doesn’t require remote access to the machine.

In addition to the remote-exec provisioner, there are also provisioners for Chef, Puppet, Salt, and other configuration managers. They allow you to bootstrap the VM to use your config manager of choice. A better alternative is to create a custom image with the config manager software already installed and register it with your config management server at boot up using one of the data loading options mentioned in the previous paragraph.

You may wish to run a script locally as part of your Terraform configuration using the local-exec provisioner. In some cases there is a provider that already has the functionality you’re looking for. For instance the the Local provider can interact with files on your local system. Still there may be situations where a local script is the only option.

Provisioner details

Despite your best efforts, you’ve decided that you need to use a provisioner after all. A provisioner is part of a resource configuration, and it can be fired off when a resource is created or destroyed. It cannot be fired off when a resource is altered.

When a creation-time provisioner fails, it sets the resource as tainted because it has no way of knowing how to remediate the issue outside of deleting the resource and trying again. This behavior can be altered using the on_failure argument. When a destroy-time provisioner fails, Terraform does not destroy the resource and tries to run the provisioner again during the next apply.

A single resource can have multiple provisioners described within its configuration block. The provisioners will be run in the order they appear.

Of course you can avoid all this nonsense by not using provisioners in the first place. We’re just sayin'.

Supplemental Information * https://www.terraform.io/docs/provisioners/index.html * https://www.terraform.io/docs/provisioners/local-exec.html * https://www.terraform.io/docs/provisioners/remote-exec.html

Key Takeaways: Provisioners are a measure of last resort. Remote-exec will run a script on the remote machine through WinRM or ssh, and local-exec will run a script on your local machine.

Wow. That’s good to know. If I see a question about provisioners on the exam, the answer is probably not to use them unless they match one of the use cases.

Summary

I hope you’ve enjoyed this sneak peak into what is in the guide and how it is constructed. If you’re interested in picking up a copy, head on over to the Leanpub page. If you’re looking for a physical copy, let me know! Right now the guide is entirely digital, but if enough people ask I will get it set up with a physical publisher as well.