I’ve just recertified my Terraform Associate certification. Why? One set of reasons relates to my employer – I understand it’s useful for our relationship with Hashicorp, may look good to our customers, and it’s certainly good for my KPIs. So what?
Are there other reasons? Should other people bother with this? Is it really worth looking at as employer? Yes, yes and yes. And here I begin, followed by some exam tips and next steps…
Terraform Associate value
The syllabus covers a load of domains, but basically if you cover it sufficiently through a course (or following the exam guides) you’ll have knowledge of:
- Basic IaC and how Terraform works – what we want (our config), what terraform thinks we have (state) and what’s in place in AWS (etc) – and how he keep this all together.
- Terraform providers – how the core system does the basics, but plugins (providers) let you work with CSPs or… well, I’ve used it for GitHub repos and I found a not-quite-mature-enough plugin for LogicMonitor.
- Terraform language, variables, functions, and how to use modules to make life simpler.
- Terraform commands – so how to make it actually do something with the config you’ve written, also how to play games with the state file.
- Terraform workspaces and Terraform Cloud – neither of which I’ve used, but you need these for the exam, and I’ve no doubt they’re good to know.
Terraform Associate value as a developer
So the syllabus covers the essentials of Terraform. So what? Well, if you abide by the syllabus coupled with experience or a decent course then you’ll understand some key areas:
- Basic use
Seems obvious, but you do need to get to grips with the language and commands. Sadly I reckon it’d be possible to pass the exam without playing with code, but I think it’d be faster to learn by doing. Follow the syllabus and any tutorials and you’ll end up with a good grasp of the basics – this’ll help you past the exam, but also give you confidence to use the tool in real life. - State
Okay, I was petrified of playing with state for ages, because I first encountered Terraform in a very large and complex environment where there were sometimes state issues – in particular resulting from removing a resource from the middle of a bunch provisioned through a list, also through only running Terraform through Jenkins, and when that went wrong we’d be left with a stale lock which I couldn’t undo. The Assoc cert doesn’t cover state in massive depth, but does teach the basics of reading state and manipulating resources. Just do make sure your state file is versioned 😉 - for_each
This is a god-send. Count still has its place of course, but I mainly expect this to be 0 or 1 now – it’s just for conditional creation of a resource as far as I’m concerned. What’s wrong with count? Creating resources based on a count results in an ordered list with integer index. The integer index is only an issue in that it’s slightly harder to see what’s what in state (and plan/apply). The biggie is that ordered nature. If you remove an item from the middle of the list then all the items after will need to have a destroy/create as they shift up. The alternative could be some funky state games which could be scripted, but are probably best avoided.
for_each instead gives us a nicely named bunch of resources, we can insert and remove as we wish. - Dynamic blocks
I don’t think they were in the Assoc cert I passed in 2021. They confused me when I first encountered them, but now they’re just normal. The Assoc syllabus might not make you an expert, but it’ll be a good introduction, and this is something you want to get your head around. - Modules
Love modules. They’re awesome. You can certainly use Terraform like you’d use Cloudformation (or how I’ve seen it in the one project that used it) – write everything out again and again and again, copying endless blocks of text, or you can embrace DRY and re-use code. Even better, you can re-use someone else’s code.
There’s lots more (workspaces, policies, Terraform Cloud), but not all places use these. Awareness of these will doubtless help get you started in a project using them. but I think you could probably skill-up quickly enough should it be needed.
Terraform Associate value as an employer/customer
I work in a consultancy, so I have two bunches of people to think about – my employer and my prospective customers/projects.
As an employer you want to know there’s a certain level of expertise in your staff. I feel this cert does actually give that. While I first passed and considered myself not very good, the cert had at least drilled into me the basic good practices, added understanding of state. It also taught me about Terraform Cloud and workspaces, neither of which are useful to me yet, but I get they *could* be.
Essentially it provides a base line – if someone’s passed this then they do know some stuff. If they’ve passed it through playing with code, all the better, so it’s worth providing a playground (AWS labs, whatever) so they can create and destroy stuff without much harm. Just make sure the cost implications are understood!
As a customer you probably want to know that prospective team members will work together effectively, quickly. If they’ve all relatively recently passed this then you know there’s a common understanding of the Hashicorp best practices, such as:
- That terraform fmt and validate are good things. These help enormously. Ideally these would just be “normal” in any team, built into workflows – this could be as an IDE plugin (vscode can fmt as you go), through precommit, through cicd. Basically though, if all devs do these in some way from the beginning, life is better.
- That secrets are stored in the right place. You really don’t want a rogue dev putting a secret somewhere silly. The cert covers this pretty well.
- That modules are the way to go. They reduce repeated code and help people deploy standardised resources. You don’t really want to have to change every terraform file that mentions a resource just because there’s now a requirement to add a feature – put this into the module and go.
But a dev needn’t have passed the cert to be good – there are some truly stellar devs I know who’ve not taken it recently (or at all) and I’m in awe of their Terraform-fu – it’s just that if they have recently passed then there’s a baseline you know you can expect. The really awesome devs will just be obvious anyway.
Learning Terraform
Approaching the exam
This depends on your experience.
- If you’re fairly new to Terraform then I think you’d be best served by working a course. If your workplace has one available, ask others what they think of it. Otherwise you could get something something on Udemy (other training providers are available) or schlep through the Hashicorp materials.
- If you’re been using this a lot then you know the language so you’ll probably need to swot up on the things you don’t use every day. I used a general summary of the syllabus to find my weaknesses and dipped into the documentation/tutorials. For what it’s worth, I knew little about Terraform Cloud, workspaces, policies.
Take practice tests! These are worth buying, I used the Bryan Krausen set on Udemy, but you may have others available or recommended. I took four of the five question sets available, passing each one fairly well. I’d intended to take the last on the morning of the exam, but didn’t wake up in time.
Taking the exam
I really hated this. It’s online only, and I far prefer exam centres. It wasn’t helped by me waking up only an hour before my 1pm exam due to my stinking cold.
Here’s what you need to sort out:
- Your laptop needs to have passed the basic checks beforehand. Work laptops can be an issue if they’re locked down, so do this way in advance so you can sort out a Plan B.
- You need to install the Secure Browser, but you’re only able to do this 30 mins before the exam, this threw me. My laptop passed the checks but somehow the secure browser had issues with the web cam. When I then installed it on my work laptop it got past that stage and told me the network connectivity in that back room wasn’t good enough.
- Your test environment needs to satisfy their requirements. The proctor will ask you to show all bits of the room to make sure there’s no funny business going on (people to help, recording devices). Having had to move to a different room this was a bit of a faff, I had to move things out of sight. The proctor asked me to show under the cushions next to me on the sofa, and round the side and back of the sofa. I really get why this is so, it was just unwelcome after the earlier palaver.
In the exam itself, do not speak. I uttered “Oh my gawd” (at feeling so rough with my cold) and my screen flashed up a warning about talking to myself.
The actual exam itself is multi choice (single or pick two/three), and there was one question expecting me to type a single “thing” (being careful with the NDA here!). Normal rules and methods apply – if not sure then eliminate the stupid and then work out the most likely, flag things you have a doubt about. Sometimes a bit of info in one question will give you think twice (or give a hint) about another.
Next steps
Use the language. Build stuff and destroy it.
Things to work on or read up on:
- Read and absorb Google’s Terraform best practices. I don’t care if you’re not using GCP, what it says is pretty good all round.
- Now read it again.
- Play with state – create resources manually and import them, get used to looking into the state file and breaking things.
- Create modules, shove them in git and version them. Play with using different module versions for different environments.
- Creating the remote state file using terraform. This feels chicken and egg, how would you approach it? Why? Are there tools that can help you?
- Play with Terragrunt (which might help with both of the above).