Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
The Problem With Doing It By Hand
Early in my Cloud and Infrastructure career I watched a colleague spend three days manually building out a production environment on Azure. Clicking through dashboards, configuring virtual networks, setting up security groups, deploying OpenShift, installing operators. Three days of careful, methodical work.
Two weeks later, we needed an identical environment for testing.
Nobody could remember exactly what had been clicked, in what order, with what settings. The tribal knowledge lived entirely in one person’s head — and that person was on holiday. What followed was a painful reconstruction exercise involving guesswork, old notes, and a lot of “I think this is how we did it.”
The test environment and the production environment were never quite the same. Different settings crept in. Configurations drifted apart. Bugs that appeared in production could not be reproduced in test because the environments were not truly identical.
This is one of the most common and most expensive problems in Cloud and Infrastructure work. And Infrastructure as Code is how you solve it.
What is Infrastructure as Code?
Infrastructure as Code — or IaC — means defining your entire cloud environment in code files rather than clicking through dashboards manually.
Instead of logging into AWS or Azure and clicking “create server,” you write a file that describes exactly what you want — the server size, the network configuration, the security rules, the storage — and a tool reads that file and builds it for you automatically.
Think of it like the difference between giving someone verbal directions to your house and sending them a precise Google Maps link. Both get them there eventually. But one is repeatable, shareable, consistent, and works the same way every time.
Your infrastructure file becomes the single source of truth for your environment. Store it in Git — as we covered in Article 3 — and you have a full history of every change ever made to your infrastructure, who made it, and when.
The Problems It Solves
Configuration Drift
This is what happens when environments that are supposed to be identical slowly become different over time. Someone makes a small manual change in production to fix an urgent issue. They mean to document it. They never do. Three months later nobody knows why production behaves differently to test and debugging becomes a nightmare.
With Infrastructure as Code, every change goes through code. There are no undocumented manual changes because there are no manual changes. If it is not in the code it does not exist.
Inconsistent Environments
Dev, test, and production should be as identical as possible. When they are not, bugs appear in production that never showed up in testing — because the environments were different in ways nobody noticed. IaC eliminates this by using the same code to build every environment. Same code, same result, every time.
Tribal Knowledge
This is the most dangerous problem of all and the one I have seen cause the most damage in real organisations. When infrastructure knowledge lives only in the heads of experienced engineers — the “old folks” who have been around long enough to remember why things were built a certain way — you are one resignation or one holiday away from a crisis.
Infrastructure as Code documents your environment automatically. The code itself is the documentation. A new team member can read the Terraform files and understand exactly how the infrastructure is built without needing to find the one person who remembers.
Enter Terraform
There are several Infrastructure as Code tools — AWS CloudFormation, Azure Bicep, Ansible, Pulumi — but Terraform is the one I use most and the one that has become the closest thing to an industry standard.
What makes Terraform special is that it is cloud agnostic. The same tool and the same approach works across AWS, Azure, Google Cloud, and dozens of other providers. If you learn Terraform you can apply that knowledge anywhere.
I learned Terraform entirely through trial and error and a lot of googling. There was no formal training, no structured course — just a problem to solve, a terminal, and the Terraform documentation. If that sounds familiar, you are in good company. Most Cloud engineers learned it the same way.
How Terraform Works
Terraform uses its own simple language called HCL — HashiCorp Configuration Language. It reads like plain English and is designed to be easy to understand even if you have never written code before.
Here is a real example that creates a virtual network on Azure:
# Define which cloud provider to use
provider "azurerm" {
features {}
}
# Create a Resource Group
resource "azurerm_resource_group" "main" {
name = "my-infrastructure"
location = "UK South"
}
# Create a Virtual Network
resource "azurerm_virtual_network" "main" {
name = "my-vnet"
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
}
In plain English this says: connect to Azure, create a resource group called “my-infrastructure” in UK South, and inside it create a virtual network. That is infrastructure that would take several minutes of clicking through the Azure portal — defined in fifteen lines of code that can be run in seconds and repeated perfectly every time.
The Three Terraform Commands You Need to Know
Everything in Terraform comes down to three commands:
terraform init
# Downloads the providers and plugins your code needs
# Run this once when you start a new project
terraform plan
# Shows you exactly what Terraform is going to do before it does it
# Think of it as a preview — always run this before applying
# This is your safety net
terraform apply
# Builds the infrastructure defined in your code
# Terraform will ask you to confirm before making any changes
The terraform plan step is the one I rely on most in real work. Before touching any production infrastructure I always run plan first to see exactly what is going to change. It has saved me from mistakes more times than I can count.
Terraform With OpenShift — A Real World Example
In my Cloud and Infrastructure work I have used Terraform extensively to deploy OpenShift environments — on Azure as ARO (Azure Red Hat OpenShift) and on AWS as ROSA (Red Hat OpenShift Service on AWS).
Before Terraform, deploying OpenShift involved long runbooks — step by step manual instructions for clicking through dashboards, running scripts, and configuring operators. Day 2 operations — the ongoing configuration and maintenance after the initial deployment — involved more runbooks, more manual steps, more tribal knowledge.
With Terraform, the base infrastructure — the virtual networks, the subnets, the security groups, the identity and access management — is all defined in code. The same Terraform configuration that builds the dev environment builds the test environment and the production environment. Identical every time.
Ansible handles the next layer — configuring the operating system, installing software, running the post-deployment tasks that Terraform does not cover. Together they replace most of what used to live in runbooks with repeatable, version controlled, auditable code.
Storing Terraform in Git — The Complete Picture
In Article 3 we covered Git and how it tracks every change to your code. Infrastructure as Code makes Git even more important because now your infrastructure changes are tracked too.
A typical workflow looks like this:
# Create a branch for your infrastructure change
git checkout -b infra/add-new-subnet
# Make your Terraform changes
# Then plan to preview what will change
terraform plan
# Commit your changes
git add main.tf
git commit -m "Add new private subnet for database tier"
# Push and open a Pull Request for review
git push origin infra/add-new-subnet
A colleague reviews the Pull Request, checks the terraform plan output, approves the change, and merges it. The CI/CD pipeline then runs terraform apply automatically.
Every infrastructure change is reviewed, documented, and traceable. No more undocumented manual changes. No more tribal knowledge. No more configuration drift.
The Honest Truths About Terraform
Since we keep it real on this blog, here is what the official documentation does not always tell you:
State management will confuse you at first. Terraform keeps track of what it has built in a file called the state file. If this gets out of sync with your actual infrastructure — which happens more often than you would like — things get complicated. Learn about remote state storage in AWS S3 or Azure Blob Storage early.
Googling is part of the job. Every Terraform engineer has a browser full of open documentation tabs. The official Terraform registry is excellent and searching “terraform azurerm resource name” will answer most questions faster than any course.
Start small. Do not try to write Terraform for your entire infrastructure on day one. Start with one resource — a storage account, a virtual machine, a network. Get comfortable with the plan and apply cycle before adding complexity.
Quick Recap
Here is everything we covered today:
- Infrastructure as Code means defining your cloud environment in code files instead of clicking through dashboards manually
- It solves three of the biggest problems in Cloud work — configuration drift, inconsistent environments, and tribal knowledge
- Terraform is the most widely used IaC tool and works across AWS, Azure, Google Cloud and more
- The three essential Terraform commands are
init,plan, andapply— always runplanbeforeapply - Storing Terraform in Git gives you a full history of every infrastructure change and connects directly to your CI/CD pipeline
- Ansible complements Terraform by handling configuration and day 2 operations that Terraform does not cover
What’s Next?
We have now covered the full DevOps and Cloud foundation — DevOps, Linux, Git, Containers, CI/CD, Kubernetes, and Infrastructure as Code.
In Article 8 we are moving into the world of AI — starting with the question everyone is asking: what actually is AI, how does it work, and how does it connect to everything we have covered so far?
The next chapter of Pipeline & Prompts is about to get very interesting.
See you in Article 8.
Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
Found this useful? Share it with anyone who has ever rebuilt a cloud environment from memory and hoped for the best. Follow along for a new article every week.
Top comments (0)