Terraform Cert Guide Chapter 1: What Is Infrastructure as Code and Why Should You Care?
Chapter 1 of Ravi Mishra’s book sets the stage for everything that follows. Before you touch a single Terraform command, you need to understand what Infrastructure as Code actually is and why it exists. Let’s break it down.
The Old Way Was Painful
Picture this. You need a virtual machine at work. You open up ServiceNow, raise a ticket, and wait. Someone from the backend picks up that ticket, logs into a management portal, and clicks through a bunch of menus to provision your VM. Done.
That works fine when you need one machine in a private data center that nobody’s going to touch again. But what happens when you move to the cloud and suddenly you need to scale 1,000 resources up during the day and back down at night? Are you going to raise 2,000 tickets? Is some poor admin going to click through all of that manually?
No. That’s where Infrastructure as Code comes in.
What Is Infrastructure as Code?
IaC is exactly what it sounds like. You write code that describes your infrastructure. Servers, networks, databases, load balancers, whatever you need. You store that code in version control (like GitHub or Bitbucket), and you deploy it automatically.
Most cloud providers have APIs for all their resources. IaC tools use those APIs to create, modify, and destroy infrastructure based on what you wrote in your config files. No tickets, no clicking through portals, no waiting for someone to get to your request.
Why IaC Matters (The Advantages)
The book lists several benefits. Here are the ones that actually matter in practice.
Speed and Simplicity
Need to spin up identical environments for dev, test, staging, and production? Write the code once, run it multiple times. Need a disaster recovery setup in another region? Same code, different target. Minutes instead of days.
Consistency
Manual deployments always introduce human error. You forget a setting, you misconfigure a firewall rule, you name something wrong. IaC standardizes the whole process. Every deployment follows the same blueprint, so you get fewer surprises.
Risk Reduction
Here’s a scenario that happens all the time. One person in the org knows how the infrastructure works. They leave. Nobody documented anything. Now you’re reverse-engineering your own systems.
With IaC, the code IS the documentation. Every change gets recorded in version control. If someone leaves or goes on vacation, the knowledge stays in the repo.
Developer Productivity
Developers can spin up their own sandbox environments without waiting on ops. QA can clone environments for testing. You can tear down everything when you’re done so you’re not paying for idle resources. CI/CD pipelines handle both app code and infrastructure code together.
Cost Savings
Less manual work means fewer people doing repetitive tasks. Auto-teardown of unused environments saves cloud bills. Engineers spend time on valuable work instead of clicking through consoles.
Enter Terraform
Terraform is an open source tool created by HashiCorp in 2014. It’s an IaC tool for building, changing, and managing infrastructure. It works with public clouds (AWS, Azure, GCP), private clouds (VMware vSphere, OpenStack), and a bunch of other services.
You write Terraform config files (ending in .tf or .tf.json) that describe what you want. Terraform figures out what needs to change and does it.
What Makes Terraform Popular
Three things set it apart.
Cloud-agnostic. One tool for AWS, Azure, GCP, and more. You don’t need to learn a different tool for each cloud.
Simple workflow. Three commands: terraform init, terraform plan, terraform apply. That’s the core loop, and it’s the same regardless of what you’re deploying to.
Consistent syntax. Terraform uses HCL (HashiCorp Configuration Language) everywhere. Whether you’re creating an AWS EC2 instance or an Azure VM, the syntax structure is the same.
Key Features
Execution plans. Before you deploy anything, terraform plan shows you exactly what will happen. No surprises. You see what gets created, modified, or destroyed before you commit.
Resource graph. Terraform builds a dependency graph of your resources and parallelizes creation where possible. If resource B depends on resource A, it handles the ordering. If resources C and D are independent, it creates them simultaneously.
Change automation. You modify your config, run plan, review the changes, then apply. Terraform figures out the minimal set of changes needed. Less room for human error.
Real-World Use Cases
The book covers several scenarios where Terraform shines.
Multi-tier apps. Think web tier, API tier, database tier. Each defined as a collection of resources in Terraform. You can scale tiers independently without breaking others.
Multi-cloud deployments. Running infrastructure across AWS and Azure? Terraform handles both with one tool and one language. No need to learn CloudFormation AND ARM templates.
Self-service clusters. Central ops team writes Terraform modules. Product teams use them as building blocks to spin up their own infrastructure. No bottlenecks.
Disposable environments. Copy your production config, spin up a test environment, run your tests, tear it down. Terraform makes this trivial.
Software demos. Need to demo your product to a customer? Terraform can provision the entire demo environment on any cloud, complete with scaling.
Resource schedulers. Terraform isn’t limited to cloud resources. It works with Kubernetes, Mesos, and other schedulers. You can set up the underlying infrastructure and deploy containers on top of it.
Terraform vs. The Competition
This is where the chapter gets really practical. Mishra compares Terraform against three cloud-native IaC tools: AWS CloudFormation, Azure ARM Templates, and Google Cloud Deployment Manager.
Terraform vs. CloudFormation
| Aspect | Terraform | CloudFormation |
|---|---|---|
| Cross-platform | Works on any cloud | AWS only |
| Language | HCL (readable, powerful) | JSON or YAML (verbose) |
| Modularity | Easy module system | Nested stacks (clunkier) |
| Validation | terraform plan shows everything | Syntax check + change sets (multiple steps) |
| Readability | HCL is clean | JSON is hard to read, YAML has whitespace issues |
| Failure handling | Keeps what was created, re-run deploys the rest | May roll back everything and start over |
| State management | Explicit state file (local or remote like S3) | Managed by AWS, but may miss config drift |
One interesting point from the book: if your CloudFormation stack fails halfway through a 50-resource deployment, it might roll back and destroy everything it created. Terraform keeps what was already provisioned and just picks up where it left off on the next run. That’s a big deal when deployments take 20-30 minutes.
Terraform vs. ARM Templates
| Aspect | Terraform | ARM Templates |
|---|---|---|
| Cross-platform | Any cloud | Azure only |
| Language | HCL | JSON (powerful but complex) |
| Modularity | Easy modules | Nested templates (workable but heavier) |
| Readability | Very readable | JSON can get messy |
| Workflow | Creates resource groups during runtime | Needs resource group to exist first |
| State management | Explicit state file | Stateless (rolls back to last good deploy) |
ARM templates are solid for Azure-only shops. But if you’re multi-cloud or think you might be someday, Terraform gives you portability that ARM can’t.
Terraform vs. Google Cloud Deployment Manager
| Aspect | Terraform | Cloud Deployment Manager |
|---|---|---|
| Cross-platform | Any cloud | GCP only |
| Language | HCL | YAML + Jinja or Python templates |
| Modularity | Simple modules | Nested templates in Python/Jinja |
| Readability | Clean HCL | YAML is okay, but Jinja/Python templates get complex |
| Maintainability | State file in GCS, code in git | No state file, templates stored locally or on third-party URLs |
| Workflow | Can create GCP projects at runtime | Needs project to exist first |
The big issue with Cloud Deployment Manager is that you end up needing to know YAML plus either Python or Jinja. Terraform just needs HCL.
The Common Thread
Across all three comparisons, the pattern is clear. Cloud-native tools work great for their specific cloud. Terraform works great everywhere. If you’re all-in on a single cloud and never plan to change, the native tool is fine. For everyone else, Terraform is the more practical choice.
Terraform Architecture
The chapter wraps up with how Terraform actually works under the hood. It’s a plugin-based architecture with two main components.
Terraform Core
This is the main binary, the terraform CLI you run on your machine. It’s written in Go and it’s open source. Core handles:
- Reading and processing your
.tfconfiguration files - Managing resource state
- Building the resource dependency graph
- Executing plans
- Communicating with plugins via RPC (Remote Procedure Calls)
Terraform Plugins
Plugins are where the actual cloud interaction happens. There are two types:
Providers handle the connection to specific services. The AWS provider knows how to talk to AWS APIs. The Azure provider knows Azure. Each provider plugin handles authentication, API calls, and resource definitions for its platform.
Provisioners run commands or scripts on resources after they’re created or before they’re destroyed. Think running a setup script on a new VM.
Both types are separate Go binaries that communicate with Terraform Core via RPC. When you run terraform init, it downloads the providers you specified in your config. By default, it pulls them from releases.hashicorp.com. Third-party plugins go in ~/.terraform.d/plugins.
Plugin naming follows a pattern: terraform-provider-<NAME>_vX.Y.Z for providers and terraform-provisioner-<NAME>_vX.Y.Z for provisioners. Terraform uses these filenames to figure out types, names, and versions.
Key Takeaways
- IaC replaces manual infrastructure management with code. Version controlled, repeatable, consistent.
- Terraform is cloud-agnostic. One tool, one language, one workflow for any cloud.
- The workflow is simple. Init, plan, apply. That’s it.
- Terraform beats cloud-native tools on portability. CloudFormation, ARM, and Cloud Deployment Manager are fine for single-cloud setups, but Terraform wins for multi-cloud or future flexibility.
- Architecture is plugin-based. Core handles the logic, plugins handle the cloud-specific work via RPC.
That’s Chapter 1. It’s mostly conceptual, but it gives you the foundation you need before you start installing and using Terraform. Next up, we actually get our hands dirty with the installation.
Previous: Series Introduction
Next: Chapter 2: Installation Guide
This is part of a series retelling “HashiCorp Infrastructure Automation Certification Guide” by Ravi Mishra (Packt, 2021). For the full text, grab the book - ISBN: 978-1-80056-597-5.