DEV Community: Ipadeola Taiwo

Building a Terraform CI/CD Pipeline With GitHub Actions (And Debugging Every Single Thing That Broke)

Ipadeola Taiwo — Tue, 11 Aug 2026 09:03:45 +0000

After getting comfortable with Terraform modules across multiple environments, I gave myself a new scenario. Imagine the CTO of the company sends down a new rule: no engineer runs terraform apply manually against production ever again. Every infrastructure change goes through a pull request. A pipeline validates it, plans it, and only applies once that change is actually merged to main. If something is wrong, it fails inside the pipeline, not in front of customers.

This post is the build of that pipeline, and honestly it turned into one of the most instructive things I have done, mostly because of how many small, sharp mistakes I made along the way and had to actually understand before I could fix them. If you are trying to build your first real CI/CD pipeline for Terraform, I want this to save you some of the pain.

The plan

Two jobs matter most here. A validate and plan job that runs on every pull request, and an apply job that only runs after code lands on main. I reused the module and one environment, payments, from an earlier project of mine, copied into a fresh repo built specifically for this pipeline.

terraform-cicd-pipeline/
├── .github/workflows/terraform.yml
├── environments/payments/
│   ├── providers.tf
│   ├── main.tf
│   └── terraform.tfvars
└── modules/infrastructure/
    ├── main.tf
    ├── variables.tf
    ├── outputs.tf
    └── cloud-init.yaml

Setting up the backend and authentication

Same manual backend pattern as always, since Terraform cannot create the storage it depends on.

az group create --name ci-cd-pipeline-backend-rg --location eastus
az storage account create --name cicdpipestorageacc --resource-group ci-cd-pipeline-backend-rg --location eastus --sku Standard_LRS --kind StorageV2
az storage container create --name ci-cd-container --account-name cicdpipestorageacc --auth-mode login

For authentication, a pipeline should never use a personal login. It needs its own identity, a Service Principal, scoped to what it actually needs to do.

MSYS_NO_PATHCONV=1 az ad sp create-for-rbac \
  --name "github-actions-terraform" \
  --role Contributor \
  --scopes /subscriptions/<subscription-id> \
  --sdk-auth

That MSYS_NO_PATHCONV bit came from a genuinely confusing early mistake. On Git Bash for Windows, any argument starting with a single slash gets silently rewritten into a Windows filesystem path before Azure CLI even sees it. So /subscriptions/xxxx quietly became C:/Program Files/Git/subscriptions/xxxx, and Azure returned a MissingSubscription error that had nothing obviously to do with slashes. That one environment variable prefix tells Git Bash to leave this specific command alone.

The four values that command outputs go into GitHub as repository secrets.

Two different kinds of authentication living in the same workflow

This tripped me up conceptually before it tripped me up technically. There are two separate things reading those same four secrets, doing two different jobs.

The azure/login action logs the Azure CLI itself into the runner. Useful if any step needs to run a plain az command.

Separately, Terraform's own provider and backend need ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_SUBSCRIPTION_ID, and ARM_TENANT_ID set as environment variables. Terraform does not automatically inherit whatever the Azure CLI is logged in as. Without these four set explicitly, terraform init fails with a very specific error: authenticating using the Azure CLI is only supported as a user, not a service principal. Both pieces are needed, and neither replaces the other.

The workflow file, and everything wrong with my first draft

I want to be honest about how many small mistakes stacked up in the first version of this file, because I think seeing the actual failures is more useful than seeing a clean finished workflow with no context.

The very first error was a missing comma inside the JSON block that azure/login reads. Plain JSON needs a comma after every property except the last one, and I had none. GitHub Actions caught this before the workflow even ran, which is honestly the best possible time for it to fail.

Other things I found and fixed one at a time across several pushes: capitalized Terraform subcommands like terraform Init that Terraform's CLI does not recognize since subcommands are lowercase only, a case mismatch between a job named Terraform-validate and another job's needs field referencing terraform-validate lowercase, since job IDs are case sensitive, and a typo in an action name, acttions/download-artifact instead of actions, which fails to resolve entirely since GitHub reads that as a literal, nonexistent repository.

The six minute silent hang

This one was the strangest to diagnose because there was no error at all, just a plan step that sat there doing nothing.

The cause was a typo in one of my TF_VAR environment variables, admin_usename instead of admin_username. Since that variable had deliberately been given no default value, based on a rule I had already learned about identity related variables never defaulting silently, Terraform tried to do the right thing and ask for a value interactively. On my own terminal that would show a prompt I could just answer. On a GitHub Actions runner, there is no one there to answer it, so it just waits, forever, with zero error output.

The fix was adding -input=false to both the plan and apply commands. This tells Terraform never to wait for interactive input, ever, and instead fail immediately and loudly if something required is missing. That single flag turned an invisible hang into an instant, readable error the next time a typo happened.

Cancelling that hung run left a real problem behind

Cancelling a stuck workflow does not run Terraform's normal cleanup. It just kills the process. Whatever lock Terraform had acquired on the state file right before it started waiting for input never got released.

The important thing to understand here is that the lock lives on the actual blob in Azure Storage, not inside GitHub Actions itself. So clearing it does not require anything special about CI, it just requires a client authenticated to the same backend.

terraform force-unlock <lock-id>

Run locally, against the same backend config, and the lock clears the same way it would if the stuck operation had come from a teammate's laptop instead of a runner.

A file that only existed on my machine

Once the workflow started actually running plan correctly, it immediately failed on missing required variables I definitely had values for. address_space, subnet_prefix, environment, backend_state_key, all of them living happily in my local terraform.tfvars.

The lesson here is one of the most important things to understand about any CI system. GitHub Actions runs on a completely fresh, disposable machine that has never seen your laptop and never will. It only ever sees what is actually committed and pushed to the repository. My terraform.tfvars was sitting quietly excluded by a default *.tfvars rule in .gitignore, so it existed locally and nowhere else. Since nothing in that particular file was sensitive, just config values, the fix was removing that line from .gitignore and actually committing the file.

SSH keys, and the difference between a path and content

The VM needed an SSH public key, and my module originally read it with file(pathexpand(var.ssh_public_key_path)), the same approach that worked fine on my own machine. It cannot work in CI. That function reads a real file from disk at plan time, and the disposable runner has no ssh folder with my keys in it at all.

The fix was changing the module to accept the key's actual text content as a variable, rather than a path to read. The public key itself is safe to store as a GitHub secret and pass in directly as TF_VAR_ssh_public_key, no file reading involved.

Getting the pipeline to actually deploy a live website

For the VM's own provisioning, update, upgrade, install nginx, clone a portfolio site, I used cloud-init rather than having the pipeline SSH in after the fact. Cloud-init runs automatically the moment the VM boots, which keeps the whole thing declarative instead of needing a private key sitting in my pipeline's secrets.

#cloud-config
package_update: true
package_upgrade: true

packages:
  - nginx
  - git

runcmd:
  - rm -rf /var/www/html
  - git clone https://github.com/highpee1991/cloud-devops-portfolio-repo.git /var/www/html
  - systemctl enable nginx
  - systemctl restart nginx

Two small but completely blocking typos hid in here for a while. First, my header line read hash cloud config with a space, which cloud-init reads as an ordinary comment rather than recognizing the file as a real cloud-config document at all, so it silently did nothing. Second, once that was fixed, I had package-update and package-upgrade with hyphens. Cloud-init's real key names use underscores. That mismatch failed schema validation and quietly skipped the whole final provisioning stage, no nginx, no clone, with almost nothing useful in the general log to point at why.

Tracing an invisible failure all the way to its root cause

Even after fixing both typos, the site still would not load. This is the part I am most proud of in this whole project, because instead of stopping at the first plausible explanation, I actually traced the failure the whole way down.

Browser, to nginx, to an empty var www html folder, to no git repository present, to a cloud-init schema error, to a systemd failure, to the actual root cause: the Linux kernel's OOM killer.

My VM size, Standard B1ls, only has about 393 megabytes of RAM. Asking it to run a full apt upgrade and install two packages unattended, all in one shot, was simply too much. The kernel killed the heaviest process mid operation to protect the system, which is exactly why cloud-init reported finishing with no obvious errors while accomplishing nothing. Sizing up to Standard B2s, with about 3.8 gigabytes of RAM, gave it enough headroom to actually finish the job.

It finally worked

A pipeline that validates, plans, and applies entirely through pull requests and merges, provisioning a real VM that installs its own software and serves a real website, with zero manual terraform apply anywhere in the loop. I tore the infrastructure down after confirming it worked, since there was no reason to keep it running once the point was proven.

What actually stuck with me

Almost every failure in this build came down to the same underlying idea in different clothes. A CI runner is a stranger to your machine. It cannot see your files, your SSH keys, your local Azure login, or anything you have not explicitly given it through a commit or a secret. Once that idea genuinely clicked, most of these bugs stopped being mysterious and started being predictable.

If you want to see the full pipeline, including the workflow file and the cloud-init script:

highpee1991 / terraform-cicd-pipeline

terraform-cicd-pipeline — Runbook

A GitHub Actions pipeline that manages Azure infrastructure through Terraform, so no engineer ever runs terraform apply by hand against production. Every infrastructure change goes through a pull request; the pipeline validates and plans it, and only applies once that change is merged to main.

Scenario

No engineer manually runs terraform apply in production ever again. Every infrastructure change goes through a pull request. The pipeline validates it, posts the plan as a comment, and applies it only when the PR is merged to main. If it fails, it fails in the pipeline, not in production.

Repository layout

terraform-cicd-pipeline/
├── .github/
│   └── workflows/
│       └── terraform.yml
├── environments/
│   └── payments/
│       ├── providers.tf      # backend + provider blocks
│       ├── main.tf           # module call + variable declarations + outputs
│       └── terraform.tfvars  # non-sensitive config values
└── modules/
    └── infrastructure/
        ├── main.tf           # resource

…

View on GitHub

If you are building something similar and hit a wall, drop a comment, happy to help however I can.

Refactoring Terraform Infrastructure Into Reusable Modules (Multi-Environment, One Codebase)

Ipadeola Taiwo — Thu, 06 Aug 2026 11:12:13 +0000

After building out the first version of my Azure infrastructure with Terraform, I ran into the problem every team eventually runs into. I needed the same infrastructure in three different places, a payments environment, an analytics environment, and a platform environment, and my first instinct was to just copy the same main.tf into three folders and tweak a few values.

That works until it doesn't. The moment you need to change one thing, add a tag, fix a rule, adjust a size, you're now updating it in three places by hand. Forget one, and you've got three environments quietly drifting apart from each other. This post is how I refactored that same infrastructure into a single reusable module that all three environments call, what broke along the way, and the two real recovery situations I had to work through when things genuinely went wrong.

The shape of it

Instead of one flat project, this became two things. A module, which holds the actual resource definitions written once. And three environments, which each call that module with their own values.

The module lives in modules/infrastructure/ with a main.tf, variables.tf, and outputs.tf, same idea as before just without hardcoding anything specific to one environment. Each environment folder under environments/ gets its own providers.tf, main.tf, and terraform.tfvars. The environment's main.tf doesn't define any resources itself anymore, it just calls the module and passes in values.

Here's the flow, end to end:

You run terraform apply inside an environment folder. That folder's providers.tf and terraform.tfvars feed into a module call, which reaches into modules/infrastructure where the resource group, virtual network, subnet, NSG, public IP, network interface, and VM are actually defined. Terraform hands the final plan to Azure ARM, and that's what creates the real infrastructure.

One backend, three isolated state files

The backend gets created manually, same as before, since Terraform can't create the backend it depends on:

az group create --name backend-rg --location eastus
az storage account create --name backendstorageaccs --resource-group backend-rg --location eastus --sku Standard_LRS --kind StorageV2
az storage container create --name backend-container --account-name backendstorageaccs --auth-mode login

The important decision here was not sharing one state file across all three environments. If payments, analytics, and platform all wrote to the same tfstate, a mistake in one could accidentally touch the other two. So each environment points at the same storage account and container, but a different key.

backend "azurerm" {
  resource_group_name  = "backend-rg"
  storage_account_name = "backendstorageaccs"
  container_name        = "backend-container"
  key                    = "payments.tfstate"
}

Small note on structure. I originally planned separate backend.tf and provider.tf files per environment, but ended up combining both into one providers.tf instead. Functionally identical, Terraform doesn't care which file a block lives in, it reads every .tf file in the folder as one combined config. Just a naming choice.

The design question that actually mattered

Before writing the module's variables, I got stuck on something that seemed small but wasn't. Some variables had default values, some didn't, and I couldn't articulate why.

The answer turned out to be a real principle, not just a style preference. Any variable that's environment specific, security related, or identity related should never have a default. If admin_username silently defaults to someone else's name because a new engineer forgot to set it, that new engineer can't log into their own server, and the person whose name it defaulted to now has access to a server they didn't know existed. If project_name silently defaults, someone on the analytics team could end up deploying into the payments resource group. If environment silently defaults, dev work could land in what's meant to be staging.

Compare that to something like location or vm_size. If those default to the wrong value, you notice immediately, the resource shows up in the wrong region or the VM is a bit underpowered, and you just fix it. No security incident, no confusion about who owns what.

So the rule I landed on: infrastructure should fail loudly with a clear error rather than succeed silently with the wrong value. Anything where a wrong guess could hurt someone gets no default, full stop.

A copy-paste bug, twice

Copying the module call from one environment to the next introduced two separate bugs, both worth mentioning because they're the kind of thing that's easy to miss and easy to fix once you see them.

First, a line assigning the wrong variable:

backend_storage_account_name = var.backend_container_name

Right variable name on the left, wrong one on the right. Small thing to catch, easy to miss when everything else validates fine.

Second, one environment's module call was literally named differently from the other two:

module "enviroment" {

against

module "infrastructure" {

in the other two. Both work, Terraform lets you name a module call whatever you want locally, but having one out of three be inconsistent is exactly the kind of thing that makes a shared codebase harder to reason about later. Renamed it to match, reran terraform init, and it fell in line.

Applying all three

Once the module and all three environments were consistent, applying each one followed the same pattern: terraform validate, terraform plan, terraform apply. Ten resources each, matching what the earlier single-project version had, just parameterized this time.

Each environment ended up SSH accessible on its own public IP once applied.

And in the portal, all three environments plus the backend show up as separate resource groups, each with their own network interface, NSG, public IP, VM, disk, and virtual network.

When the network actually dropped

This is the part worth reading carefully if you're doing anything with a remote backend, because it will happen to you eventually.

Midway through applying the analytics environment, my network dropped for a few minutes right as Terraform finished creating the VM and tried to write the final state back to the storage account. The apply itself succeeded, every resource was really created, but the state write failed with a DNS lookup error, since my machine briefly couldn't resolve the storage account's hostname.

Because it couldn't reach the backend, Terraform did the safe thing. It saved the correct, complete state to a local file called errored.tfstate and told me exactly what to do next. It also tried to release its lock on the remote state and failed at that too, since the same connection was down, leaving an orphaned lock behind.

Every apply after that failed with "state blob is already locked," which looked alarming but wasn't actually a conflict with anyone else, just a lock nobody could release because the connection that was supposed to release it was gone. Recovery was three commands:

terraform force-unlock <lock-id>
terraform state push errored.tfstate
terraform plan

The force-unlock cleared the stuck lock. Pushing errored.tfstate uploaded the correct, complete state that Terraform had already built locally. The follow-up plan came back with "No changes, your infrastructure matches the configuration," confirming everything reconciled correctly. Nothing was lost, nothing had to be rebuilt, and the VM that got created during the outage was sitting there working the whole time.

Tearing it all down

terraform destroy on each environment removed exactly what that environment's module call had created, in the correct dependency order. One of the three hit a second, smaller network hiccup, this time a connection reset while deleting the VM's managed disk mid-teardown. No stuck lock this time, just a straightforward second terraform destroy picked up exactly where the first one left off and finished the job.

One thing worth knowing: terraform destroy only removes what Terraform manages. It doesn't touch the backend itself, since that was created manually and Terraform was never given authority over it. After destroying all three environments, the three state files were still sitting in the container, just now describing empty environments. Removing the backend for good meant one more manual step:

az group delete --name backend-rg

That took the resource group, the storage account, the container, and every state file inside it down in one shot.

What this actually bought me

Going from one flat project to a module plus three environments wasn't just about avoiding copy and paste. It meant a single change to modules/infrastructure/main.tf would ripple out to payments, analytics, and platform automatically, instead of needing to be applied three separate times by hand and risking one getting missed. It also meant each environment's blast radius was contained, its own resource group, its own state file, its own lock, so a mistake in one couldn't reach into another.

If you want to see the actual code, including the module and all three environments:

https://github.com/highpee1991/terraform-enterprise

If you're building something similar and want to talk through the module structure or the state recovery, drop a comment.

Building Enterprise Azure Infrastructure With Terraform and Remote State

Ipadeola Taiwo — Sat, 01 Aug 2026 05:58:12 +0000

A few weeks ago I set myself a scenario. Pretend I joined a company called Big 8 Integrated LLC as a Cloud Engineer. The company has decided that from now on, all infrastructure gets managed as code with Terraform. And because more than one engineer touches the infrastructure, the Terraform state can never sit on anyone's laptop. It has to live somewhere shared, somewhere that locks itself while someone is working, so two people can't step on each other's changes.

That one requirement, state must never be local, ended up teaching me more than any tutorial I had read before it. This post is that journey, from an empty Azure subscription to a live VM serving a website, written the way it actually happened, mistakes included. If you're new to Terraform and Azure, you should be able to follow this from scratch and end up with the same thing.

The plan

Before touching any code, I sketched out what I was building.

Two resource groups. One holds the backend, just a storage account with a blob container where the Terraform state file lives. The other holds the actual workload, a virtual network, a subnet, a network security group, a public IP, and a Linux VM. The backend group gets created by hand. Everything in the second group gets created by Terraform.

Why two groups, and why create the first one by hand? Because Terraform can't create the backend it depends on. It needs somewhere to store its state before it can even start managing anything, so that first piece has to exist before Terraform ever runs.

Setting up the backend manually

I already had the Azure CLI installed and was logged in, which I confirmed with:

az account show

Then I created the resource group for the backend:

az group create --name big8-rg --location eastus

That one worked first try. The storage account did not.

az storage account create --name big8-backend-store --resource-group big8-rg --location eastus --sku standard_LRS --kind storageV2

Azure rejected it. Storage account names can't have dashes, or any special characters at all. Lowercase letters and numbers only, between 3 and 24 characters. Small thing, but it's the kind of rule you only learn by hitting it. I dropped the dashes and tried again with big8backendstore, and it went through.

Last piece of the manual setup, the blob container that would actually hold the state file:

az storage container create --name bigcontainer --account-name big8backendstore --auth-mode login

At this point I had a resource group, a storage account, and an empty container. No state file yet. That part comes automatically the first time Terraform runs.

Writing the Terraform config

I set up a providers.tf file with the provider block and the backend block pointing at what I'd just created by hand.

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }

  backend "azurerm" {
    resource_group_name  = "big8-rg"
    storage_account_name = "big8backendstore"
    container_name        = "bigcontainer"
    key                    = "pro/big8store.tfstate"
  }
}

provider "azurerm" {
  features {}
}

That key value is just the filename Terraform will use for the state file inside the container. It doesn't have to match anything specific, you choose it. For a bigger setup with multiple environments, you'd usually split this by environment or component, something like dev.tfstate and prod.tfstate, or networking/vnet.tfstate and compute/vm.tfstate, so nothing shares a state file and nothing risks overwriting something it shouldn't. For this project I kept it simple, one state file for the whole thing.

Then I ran:

terraform init

This is the moment the backend actually gets used. Terraform connected to the storage account, configured itself to read and write state there, and installed the azurerm provider. And sure enough, checking the container in the Azure portal right after, there it was, a tiny 181 byte file called big8store.tfstate sitting exactly where I told it to go.

The part that finally made variables click

I want to be honest about this part because it tripped me up longer than I expected. I understood that variables.tf declares a variable exists, and terraform.tfvars gives it a value, but I couldn't picture how Terraform actually connects the two.

What clicked for me eventually is that it's just name matching. If variables.tf declares a variable called location, and terraform.tfvars has a line location = "East US", Terraform pairs them up because the names match exactly. Nothing more clever than that. Then anywhere in main.tf you write var.location, Terraform swaps in the value before it ever talks to Azure. Run terraform plan and what you're looking at is that swap already done, the fully resolved version of your config.

Once that landed, locals made sense as the natural next step. Variables are values you set from outside your config, tfvars, command line flags, environment variables. Locals are values you compute inside your config from other values, and you don't set them from outside at all. I used a locals block to build one tags object from three variables, so instead of retyping the same three tags on every single resource, I write it once and reference local.tags everywhere.

locals {
  tags = {
    Project     = var.project_name
    Environment = var.environment
    Owner       = var.admin_username
  }
}

I actually mixed this up once, declared tags as both a variable with no default value and a local, and Terraform got confused trying to figure out which one I meant, prompting me for a value on every plan. Deleting the leftover variable declaration and keeping only the local fixed it in one shot. Good practical example of the difference between the two.

Writing main.tf

With variables and locals sorted, the actual resource definitions were fairly mechanical. Resource group, then a virtual network sitting inside it, a subnet inside the network, a network security group with rules allowing inbound traffic on port 22 for SSH and port 80 for HTTP, a public IP, a network interface tying the subnet and public IP together, and finally the VM itself.

Two mistakes came up here worth mentioning. First, my NSG rules were written with destination_address_prefixes (plural) set to a single string, "*". Terraform wants a list for the plural version. The fix was switching to destination_address_prefix (singular), which takes a plain string. Second, my SSH key path was wrong, I had it pointing somewhere that didn't exist on my machine. Checking my actual .ssh folder and correcting the path with pathexpand("~/.ssh/id_ed25519.pub") sorted that out.

After both fixes, terraform validate finally came back clean.

The plan, and a real deploy error

terraform plan showed exactly ten resources ready to create, matching the diagram I'd sketched at the start. Everything lined up, tags flowing automatically onto the resource group, the network, and the public IP from that one locals block.

terraform apply got nine of those ten up without issue. The tenth, the VM itself, failed:

Error: creating Linux Virtual Machine: unexpected status 404 (404 Not Found)
PlatformImageNotFound: The platform image 'Canonical:0001-com-ubuntu-server-jammy:22_04_lts:latest' is not available.

I'd written the sku as 22_04_lts, with underscores. Running a quick image list against Azure showed the real current sku uses a hyphen instead, 22_04-lts. One character fix, and re-running apply picked up right where it left off, the nine resources already created stayed untouched, and only the VM got added this time.

Getting onto the box and putting something real on it

With a public IP in hand, I connected over SSH:

ssh <admin_username>@<public-ip>

Ran the usual updates, installed nginx, and visiting the IP in a browser showed the default nginx welcome page, proof the whole networking chain actually worked end to end.

Then I copied a small static site over with scp, moved it into /var/www/html, and reloaded the page.

That was the moment this stopped feeling like an exercise. A real site, served from a VM I had provisioned entirely through code, sitting behind a network I had also defined entirely through code.

Proving the state lock actually works

The whole reason this project insists on remote state is to make collaboration safe. Two engineers, one shared state file, no local copies going stale. I wanted to actually see that protection in action instead of just taking it on faith, so I opened two terminals and simulated it.

In one terminal, I kicked off terraform apply.

While that was still running, I switched to the second terminal and ran terraform plan.

Error: Error acquiring the state lock
Error message: state blob is already locked
Lock Info:
  Operation: OperationTypeApply

That's the mechanism working exactly as intended. Azure Storage puts a lease on the state blob the moment an operation starts writing to it, and any other operation trying to touch that same file gets refused until the lease is released. Without this, two engineers running Terraform at the same time could easily corrupt the state or fight over the same resources. With it, one of them simply gets told to wait.

Cleaning up

Once I was done, tearing it all down was just:

terraform destroy

Ten resources removed, in the correct order, associations and rules first, then the VM and its NIC, then the network, and the resource group last since everything else lived inside it.

The backend pieces were created by hand, so they had to go the same way:

az group delete --name big8-rg

A quick az group list afterward confirmed only Azure's own auto-created NetworkWatcherRG was left. Clean slate.

What actually stuck with me

Reading Terraform state as a genuine record of reality, not just a lock file, changed how I think about every command. plan isn't guessing, it's comparing your code against a document that describes what's really out there. apply doesn't blindly create things, it reconciles the two. And the locking isn't a formality, it's the one thing standing between a team and a corrupted state file.

If you want to follow along with the actual code, it's all here:

https://github.com/highpee1991/terraform-IAC

If you're working through something similar and get stuck, drop a comment, happy to help however I can.

Building And Securing An Azure Virtual Machine With Terraform, From Zero To A Working Website

Ipadeola Taiwo — Sun, 12 Jul 2026 11:19:54 +0000

This is a full walkthrough of a real Terraform project, provisioning a Linux virtual machine on Azure, securing it properly, and deploying a working web server on it. Every command in this post is one I actually ran, every error is one I actually hit, and every fix is exactly how I solved it. My goal here is not just to show you a finished project, my goal is to teach you how to build this yourself, line by line, understanding why each piece exists and what happens when something goes wrong.

If you follow this post from top to bottom, you will end with your own Linux server running on Azure, provisioned entirely as code, reachable over SSH, and serving a real webpage to anyone who visits its public address.

What We Are Building

A single Ubuntu virtual machine, sitting inside its own virtual network, protected by a firewall that only allows the two ports it actually needs, SSH for management and HTTP for web traffic, with a static public IP address so that address never changes once assigned.

Prerequisites

Terraform installed on your machine, version one point zero or higher. The Azure CLI installed and signed in with az login. An active Azure subscription. And an SSH key pair already generated on your machine, most systems already have one sitting at ~/.ssh/id_rsa.pub, if not, generate one with ssh-keygen before continuing.

Project Structure

Four files make up this entire project.

providers.tf
variables.tf
main.tf
outputs.tf

Terraform does not care how you split your code across files. Every file in the same folder is automatically treated as one combined configuration. Splitting things apart like this is purely for readability, so let's go through each file and understand what it is doing.

providers.tf, Telling Terraform Which Cloud We Are Talking To

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "4.80.0"
    }
  }
}

provider "azurerm" {
  features {}
}

This file has one job, telling Terraform that this project talks to Azure, using a specific, pinned version of the provider. Pinning the version matters more than it might look like at first, if you leave this open ended, your project could quietly behave differently every time you run it, depending on whatever the latest provider release happens to be that day. Pinning it to 4.80.0 means this project behaves exactly the same way every single time, on any machine, forever.

variables.tf, The Values That Drive Everything Else

variable "project" {
  description = "project name"
  type        = string
  default     = "terraform_vm"
}

variable "location" {
  description = "azure region"
  type        = string
  default     = "East US"
}

variable "owner" {
  description = "owner tag"
  type        = string
  default     = "Hagital"
}

variable "vm-size" {
  description = "vm size"
  type        = string
  default     = "Standard_B1ls"
}

Four variables, the project name, the Azure region, an owner tag for organizing resources, and the size of the virtual machine. Every resource in main.tf pulls its values from here rather than having anything typed directly into it, so changing the region or the VM size later means editing one line here, not hunting through every resource individually.

One thing worth explaining clearly, since it genuinely confused me the first time I wrote a Terraform project. If you come from a general programming background, you are used to variables needing to be exported from one file and imported into another. Terraform does not work that way at all. There is no export keyword, no import statement, nothing to wire together. Once a variable is declared anywhere in this folder, it is available anywhere else in this same folder, simply by writing var.project, or var.location, or whichever name you gave it. The folder itself is the boundary, not the individual file.

main.tf, The Actual Infrastructure

This is the heart of the project. Nine resources, built up in the order they logically depend on each other. Let's go through each one.

The Resource Group

resource "azurerm_resource_group" "hagital-rg" {
  name     = "${var.project}_hagital_rg"
  location = var.location

  tags = {
    Environment = "Hagital-vm"
    Owner       = var.owner
    Project     = var.project
  }
}

Every resource in Azure needs a container to live inside, called a resource group. This is the first thing created, and every other resource in this file references it, either directly or indirectly.

The Virtual Network And Subnet

resource "azurerm_virtual_network" "hagital-vnet" {
  name                = "${var.project}_hagital_vnet"
  location            = azurerm_resource_group.hagital-rg.location
  resource_group_name = azurerm_resource_group.hagital-rg.name
  address_space       = ["10.0.0.0/16"]

  tags = {
    Environment = "Hagital_vnet"
    Owner       = var.owner
    Project     = var.project
  }
}

resource "azurerm_subnet" "hagital-subnet" {
  name                 = "${var.project}_hagital_subnet"
  resource_group_name  = azurerm_resource_group.hagital-rg.name
  virtual_network_name = azurerm_virtual_network.hagital-vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

A VM needs a network to sit inside before it can exist. The virtual network defines the overall address space, and the subnet carves out a smaller section of it for this specific machine to live in. Notice how resource_group_name here is not typed as a plain string, it directly references azurerm_resource_group.hagital-rg.name. This is how Terraform understands dependency order automatically, it sees that the subnet needs the resource group to exist first, and builds everything in the correct sequence without you having to say so explicitly.

The Firewall, And Its Rules

resource "azurerm_network_security_group" "NSG" {
  name                = "${var.project}_hagital_NSG"
  location            = azurerm_resource_group.hagital-rg.location
  resource_group_name = azurerm_resource_group.hagital-rg.name
}

resource "azurerm_network_security_rule" "NSG_rule_port_80" {
  name                        = "${var.project}nsg_port_80"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "80"
  source_address_prefix       = "*"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.hagital-rg.name
  network_security_group_name = azurerm_network_security_group.NSG.name
}

resource "azurerm_network_security_rule" "NSG_rule_port_22" {
  name                        = "${var.project}nsg_port-22"
  priority                    = 101
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "22"
  source_address_prefix       = "*"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.hagital-rg.name
  network_security_group_name = azurerm_network_security_group.NSG.name
}

A network security group, NSG for short, is Azure's firewall. On its own it does nothing, it is just a container for rules. Each rule below it defines exactly one allowed pattern of traffic.

Both rules here are inbound, meaning traffic coming into the VM from outside, not traffic leaving it. Port eighty allows web visitors to reach the site once it is running. Port twenty two allows SSH connections in, so you can actually manage the server. Notice each rule has its own priority number, one hundred and one hundred one. Two inbound rules in Azure can never share the same priority, each one needs a unique number, and spacing them out, rather than using consecutive numbers, leaves room to insert new rules later without renumbering everything.

Notice too, source_port_range is set to a wildcard on both rules, while destination_port_range is the actual port being protected. This trips a lot of people up at first. The source port is whatever random, temporary port your browser or SSH client happens to open the connection from, you cannot predict or control that, so it is always a wildcard. The destination port is the one you actually care about, the port on the server itself.

The Public IP

resource "azurerm_public_ip" "public-ip" {
  name                = "${var.project}_public_ip"
  resource_group_name = azurerm_resource_group.hagital-rg.name
  location            = azurerm_resource_group.hagital-rg.location
  allocation_method   = "Static"

  tags = {
    Environment = "public_ip"
    Owner       = var.owner
    Projects    = var.project
  }
}

Without this, the VM would only be reachable on a private, internal address, nothing you could actually connect to from your own laptop. allocation_method is set to Static rather than Dynamic, deliberately. A static IP stays the same even if the VM is stopped and restarted, it only changes if the public IP resource itself is deleted. A dynamic IP, by contrast, can change every time the VM restarts, which becomes a real annoyance once you are actively developing against a known address.

The Network Interface

resource "azurerm_network_interface" "NIC" {
  name                = "${var.project}_NIC"
  location            = azurerm_resource_group.hagital-rg.location
  resource_group_name = azurerm_resource_group.hagital-rg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.hagital-subnet.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.public-ip.id
  }
}

This is the piece that physically connects everything together. The network interface card, NIC for short, is what actually plugs the VM into the subnet, and it is also where the public IP gets attached. A VM cannot connect directly to a subnet or a public IP on its own, it always goes through a network interface in between.

The Virtual Machine Itself

resource "azurerm_linux_virtual_machine" "linux-vm" {
  name                = "${var.project}_linux_vm"
  computer_name       = "hagital-vm"
  resource_group_name = azurerm_resource_group.hagital-rg.name
  location            = azurerm_resource_group.hagital-rg.location
  size                = var.vm-size
  admin_username      = "${var.owner}user"
  network_interface_ids = [
    azurerm_network_interface.NIC.id
  ]

  admin_ssh_key {
    username   = "${var.owner}user"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }
}

This resource references everything built above it, the network interface for connectivity, an Ubuntu twenty two image from Canonical for the operating system, and an SSH key read directly from your local machine using the file() function, rather than pasting the key as text. One detail worth calling out, name and computer_name are two different things here, name is the label Azure uses for the resource itself, while computer_name becomes the actual hostname inside the running Linux machine, and Linux hostnames follow much stricter naming rules than Azure resource names do, more on that shortly when we get to the errors.

The Missing Piece Most Tutorials Skip

resource "azurerm_network_interface_security_group_association" "nsg_association" {
  network_interface_id      = azurerm_network_interface.NIC.id
  network_security_group_id = azurerm_network_security_group.NSG.id
}

This resource genuinely tripped me up, and I want to explain it clearly because I suspect it will trip other people up too. Creating a network security group and writing rules for it does not automatically apply those rules to anything. The NSG just sits there, unused, until it is explicitly attached to something, in this case, the network interface. Without this association resource, your firewall rules exist in Azure but affect nothing at all, and Azure falls back to blocking inbound internet traffic by default. This one resource is what actually switches your firewall rules on.

outputs.tf, Getting Useful Information Back

output "resource_group_created" {
  description = "resource group name"
  value       = azurerm_resource_group.hagital-rg.name
}

output "Vnet" {
  description = "vnet name"
  value       = azurerm_virtual_network.hagital-vnet.name
}

output "subnet" {
  description = "subnet name"
  value       = azurerm_subnet.hagital-subnet.name
}

output "NSG" {
  description = "NSG name"
  value       = azurerm_network_security_group.NSG.name
}

output "port_80_rule" {
  description = "Inbound port 80 created"
  value       = azurerm_network_security_rule.NSG_rule_port_80.destination_port_range
}

output "port_22_rule" {
  description = "Inbound port 22 created"
  value       = azurerm_network_security_rule.NSG_rule_port_22.destination_port_range
}

output "public_ip" {
  description = "public ip"
  value       = azurerm_public_ip.public-ip.id
}

output "vm_name" {
  description = "azure vm name"
  value       = azurerm_linux_virtual_machine.linux-vm.name
}

output "vm_public_ip" {
  description = "vm attached public ip"
  value       = azurerm_linux_virtual_machine.linux-vm.public_ip_address
}

Outputs print useful information to the terminal automatically after every apply, so you are not stuck manually looking things up in the Azure Portal afterward. The most useful one here by far is vm_public_ip, since that is the exact address needed to actually SSH into the machine once it exists.

The Errors I Ran Into, And How They Were Fixed

A quick note before this section, the code shown above already reflects every correction. You do not need to change anything, this section exists purely to walk through what went wrong the first time and how each issue was diagnosed.

This is the part most tutorials skip entirely, and it is the part I think actually matters most. Nothing here worked perfectly on the first attempt. Every error below is real, and understanding each one teaches you something a clean, error free run never would.

Running terraform init

terraform init

This command downloads the azurerm provider and prepares the working directory. The very first time I ran this, it failed.

Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider hashcorp/azurerm

Read that carefully. It says hashcorp, missing the letter i. The real provider is published as hashicorp, with the i. Somewhere in my configuration, that name had been typed incorrectly, and Terraform was searching for a provider that simply does not exist. Correcting the spelling and running terraform init again resolved it immediately.

A second, completely different failure showed up on another attempt.

Error: Failed to install provider
Error while installing hashicorp/azurerm v4.80.0: releases.hashicorp.com: local error: tls: bad record MAC

This one had nothing to do with my code at all, it was a network connection problem, an interrupted or unstable connection while downloading the provider. The fix here was simply waiting a moment and retrying the same command again.

terraform init

Once the connection stabilized, it installed cleanly.

The Subscription ID Requirement

Running terraform plan for the first time in this particular project produced a new error I had not seen in earlier Terraform projects.

Error: `subscription_id` is a required provider property when performing a plan/apply operation

This turned out to be a documented change, starting with version four point zero of the azurerm provider, explicitly setting a subscription ID in the provider block became mandatory. In an earlier Terraform project of mine, this had not come up, likely due to how that specific environment resolved it implicitly. The fix here was reverting cleanly to provider version 4.80.0 after clearing out the previously cached .terraform folder and lock file, forcing Terraform to properly resolve the version fresh, which sidestepped the issue entirely for this setup.

Reviewing The Plan

Once initialization succeeded, terraform plan produced a full, detailed preview of every resource about to be created, nine in total, resource group, virtual network, subnet, NSG, two security rules, public IP, network interface, and the VM itself.

Plan: 9 to add, 0 to change, 0 to destroy.

This is the single most important habit in Terraform, always read the plan before applying it. It tells you exactly what is about to happen before it actually happens, and it is your last chance to catch a mistake before real infrastructure gets created and starts costing money.

Running terraform apply, And The First Real Failure

terraform apply

Typing yes at the confirmation prompt kicked off creation. Eight resources succeeded cleanly, resource group, network, subnet, NSG, both rules, public IP, and network interface, each completing within seconds. Then the VM itself failed.

Error: unable to assume default computer name "computer_name" cannot contain the special characters:
`\/"[]:|<>+=;,?*@&~!#$%^()_{}'`. Please adjust the `name`, or specify an explicit `computer_name`

This is a genuinely useful error to understand. Azure resource names and Linux hostnames follow completely different rule sets. My VM's name value contained underscores, which Azure resource names allow without issue, that is exactly why the resource group, VNet, and NSG all created successfully with underscores in their own names. But without an explicit computer_name set, Terraform tries to generate one automatically from the resource name, and a Linux hostname cannot contain underscores at all. The fix was adding an explicit, separate computer_name value using only letters, numbers, and hyphens, which is exactly what you see in the finished main.tf above, computer_name = "hagital-vm".

The Second Failure, An Invalid VM Size

After fixing the computer name and running terraform plan again, a different error appeared, this time about the VM size itself.

The originally typed size, Standard_B1_ls, is not a valid Azure size string. Azure VM sizes follow a fixed format defined by Azure itself, and this one had an extra underscore that did not belong. The correct value is Standard_B1ls, no separator between B one and ls, one continuous string. You can always confirm exactly which sizes are valid and available in your specific region directly from the CLI, rather than typing one from memory:

az vm list-sizes --location eastus --output table

Correcting variables.tf to Standard_B1ls and running terraform plan again confirmed it was accepted.

Applying Again, Successfully This Time

terraform apply

This time, all nine resources built successfully.

Apply complete! Resources: 9 added, 0 changed, 0 destroyed.

Outputs:

NSG = "terraform_vm_hagital_NSG"
Vnet = "terraform_vm_hagital_vnet"
port_22_rule = "22"
port_80_rule = "80"
public_ip = "/subscriptions/.../publicIPAddresses/terraform_vm_public_ip"
resource_group_created = "terraform_vm_hagital_rg"
subnet = "terraform_vm_hagital_subnet"
vm_name = "terraform_vm_linux_vm"
vm_public_ip = "20.169.155.100"

Every output printed automatically, exactly as designed, including the actual public IP address, ready to copy straight into an SSH command.

The Connection That Timed Out

ssh Hagitaluser@20.169.155.100

ssh: connect to host 20.169.155.100 port 22: Connection timed out

This is the error that taught me the most out of this entire project. Everything in the plan had applied successfully, no errors, nine resources created, yet SSH could not reach the machine at all. A connection timeout like this, rather than an outright refusal, is the signature of a firewall silently dropping the request rather than actively rejecting it.

The cause traced back to something I had genuinely overlooked. Creating a network security group and writing rules for it does not automatically apply those rules to anything. I had built the NSG, and I had written both inbound rules, port twenty two and port eighty, but I had never actually attached that NSG to the network interface. The rules existed, but they were not switched on.

The fix was adding one more resource, exactly the association block shown earlier in main.tf.

resource "azurerm_network_interface_security_group_association" "nsg_association" {
  network_interface_id      = azurerm_network_interface.NIC.id
  network_security_group_id = azurerm_network_security_group.NSG.id
}

terraform plan
terraform apply

One resource added. Trying SSH again immediately after:

ssh Hagitaluser@20.169.155.100

The authenticity of host '20.169.155.100 (20.169.155.100)' can't be established.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '20.169.155.100' (ED25519) to the list of known hosts.
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1059-azure x86_64)

Connected. That fingerprint warning the first time is completely normal, it is simply your machine confirming, for the first time, that it trusts this brand new server's identity, the same thing happens connecting to any new server for the first time, not just this one.

Configuring The Server

With SSH access working, I updated the system and installed Nginx, the actual web server this whole project was built to run.

sudo apt update
sudo apt upgrade -y
sudo apt install nginx -y

Once installed, I confirmed the service was genuinely running, not just installed.

sudo systemctl status nginx

● nginx.service - A high performance web server and a reverse proxy server
     Active: active (running) since Sun 2026-07-12 10:30:47 UTC

Then verified it was actually serving content, first from directly inside the VM itself.

curl 20.169.155.100

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

Verifying From The Outside World

The final and most satisfying check, opening the VM's public IP address directly in a browser from my own laptop, completely outside of Azure and outside of the VM itself.

The page loaded correctly, the default Nginx welcome page, confirmed reachable from the open internet. That "not secure" warning next to the address bar is expected and not a problem, it simply means the connection is running over plain HTTP rather than HTTPS, adding a TLS certificate would be the natural next step to remove that warning, a good project on its own.

What This Project Actually Proves

Every piece of this was provisioned as code, version controlled, and repeatable, not clicked together by hand. Five distinct, real errors were hit along the way, a provider name typo, a network connectivity drop, a Linux hostname naming rule, an invalid Azure VM size string, and a missing NSG association that silently left the firewall rules inactive despite a fully successful apply. Every one of them was diagnosed by actually reading the error message closely and understanding what it was describing, not by guessing or copying a fix blindly.

The result is a real, working, secured Linux server, reachable over SSH, serving a live webpage to anyone on the internet, built entirely from four Terraform files and a lot of careful debugging.

If you followed along and built this yourself, or if you hit a different error than the ones documented here, I would genuinely like to hear about it in the comments. Debugging infrastructure is a skill built entirely through hitting exactly this kind of wall and working through it, and comparing notes with someone else doing the same thing is one of the fastest ways to get better at it.

Github Link:

highpee1991 / Terraform-Virtual-Machine-Deployment

My First Real Terraform Project, Two Environments, One Storage Account, And A Few Lessons I Did Not See Coming

Ipadeola Taiwo — Sat, 11 Jul 2026 15:52:14 +0000

A few days ago I said I was starting Infrastructure as Code. Today I actually sat down and wrote my first proper Terraform project, and I want to walk you through exactly what I built, what confused me at first, and what broke along the way, because the broken parts taught me more than the parts that just worked.

What I Set Out To Build

The idea was simple on paper. A small payments project needs two separate environments, one for development and one for staging, each represented by its own resource group in Azure. On top of that, the development environment needed a storage account with a blob container inside it, the kind of setup you would actually see on a real team, where dev and staging are kept apart on purpose.

Nothing here was complicated in terms of what Azure resources were involved. What made it worth doing was doing it the Terraform way, writing it once as code, and letting Terraform figure out how to create everything in the right order.

The Part That Actually Confused Me At First, Variables

Before I even got to writing resources, I had to deal with variables, and this is the part I really want to talk about, because it caught me off guard in a way I was not expecting.

If you come from a general programming background, even a light one, you are used to variables needing to be exported and imported somehow. You define something in one file, and if you want to use it somewhere else, you usually have to explicitly export it, then import it wherever you need it. That is just how most languages work.

So naturally, when I created a separate file just for my variables, my first thought was, how do I export this so my other files can actually see it. I genuinely sat there for a moment trying to figure out the Terraform equivalent of an export statement.

Turns out, there isn't one, and there does not need to be.

In Terraform, every file inside the same working directory is automatically part of the same configuration. It does not matter if your variables live in variables.tf, your resources live in main.tf, and your outputs live in outputs.tf. Terraform reads every .tf file in that folder as one combined configuration. Once a variable is declared, anywhere in that folder, you can reference it anywhere else in that same folder, just by calling var.whatever_you_named_it.

No import statement. No export keyword. No file path linking one file to another. The folder itself is the boundary, not the individual file.

Once that clicked, it actually made the whole language feel simpler than I expected. Splitting files apart in Terraform is purely for organization and readability, not because the tool needs you to wire files together the way you would in something like JavaScript or Python.

Setting The Foundation, Provider And Variables

Every Terraform project needs to know which provider it is talking to, in this case Azure, and which version of that provider to use. I pinned mine to a specific version rather than leaving it open ended, so the project behaves the same way every time it runs, regardless of what the latest provider release happens to be on a given day.

Then came the three variables that would drive the whole project, the project name, the Azure region, and an owner tag, each with a sensible default so I would not have to retype the same values across every resource.

Building The Actual Infrastructure

With the foundation in place, I defined four resources. Two resource groups, one for dev and one for staging, a storage account sitting inside the dev resource group, and a storage container sitting inside that storage account.

What I liked here is how naturally Terraform expresses the relationship between resources. I did not have to manually tell the storage account which resource group it belonged to using some ID I copied from somewhere. I just referenced the resource group resource directly, and Terraform understood the dependency and the order to create things in, entirely on its own.

Where It Actually Broke, And What Each Break Taught Me

I want to be upfront about this part, because I think it is the most useful part of this whole post. Nothing here worked perfectly on the first attempt, and I think that is normal, and worth documenting honestly rather than pretending it all went smoothly.

The first error showed up right at terraform init. Terraform told me it could not find a provider called hashcorp/azurerm. I stared at that for longer than I want to admit before I noticed the actual issue, the error was missing a letter. The real provider is hashicorp, not hashcorp. One missing letter somewhere in my configuration was enough to send Terraform looking for a provider that does not exist. Fixing the spelling and running init again solved it immediately.

The second error happened during terraform plan. This one looked scarier than it actually was. Terraform said it ran into a problem while trying to automatically register an Azure resource provider called Microsoft.Kusto, something I was not even using directly, and the process got interrupted. I simply ran the plan again, and it went through cleanly the second time. Turns out Terraform tries to register a whole set of Azure resource providers behind the scenes the first time you use certain resource types, and on a lighter subscription that step can be slow enough to get cut off.

The third error was the most straightforward, but the easiest to overlook. Azure rejected my storage account name because it contained a hyphen. Storage account names in Azure have to be lowercase letters and numbers only, no hyphens allowed, which is different from resource group names, where hyphens are perfectly fine. I had used the same naming pattern across both without realizing storage accounts play by different rules. Removing the hyphen fixed it right away.

None of these were difficult once I understood what was actually happening, but each one forced me to slow down and actually read the error message properly instead of assuming I already knew what went wrong.

Confirming It Actually Worked

Once everything applied successfully, I did not just trust the terminal output. I went into the Azure Portal directly and checked every piece, both resource groups showing up correctly under the right region, the storage account sitting inside the correct resource group, and the container present inside that storage account with the access level I had configured. Seeing it match exactly what Terraform said it created was a genuinely satisfying moment.

Tearing It Down

Since this was a lab and not something meant to run permanently, I finished by running a full destroy, and watched Terraform take everything down in the correct reverse order, the container first, then the storage account, then both resource groups, all cleanly removed with a single command and a typed confirmation.

What This Project Actually Taught Me

Beyond the individual errors, the biggest shift for me was realizing how much Terraform handles on its own once you describe what you want clearly. I did not have to think about ordering. I did not have to manually track dependencies between resources. I described the end state, and Terraform figured out how to get there, and how to safely undo it later.

I also learned something small but important while wrapping up, my working folder had files sitting there that should never end up in version control, the local state files and the provider cache directory in particular, since state files can end up holding sensitive information about the resources they track. That is going straight into a .gitignore before this project touches GitHub properly.

This is only the first project in what I expect will be a much longer run with Terraform. If you have worked with it longer than I have, and there is something you wish someone had told you this early on, I would genuinely like to hear it in the comments.

Below is link to my github repo

highpee1991 / azure-terraform-lab

terraform

Understand the 4 Core Files

Every Terraform project has this structure:

azure-terraform-lab/ ├── main.tf # Your resources live here ├── variables.tf # Input variables (reusable values) ├── outputs.tf # What Terraform prints after running └── providers.tf # Which cloud you are connecting to

Terraform command to use daily

1. Download the Azure provider plugin

terraform init

2. Preview what Terraform WILL do — never skip this

terraform plan

3. Actually build the infrastructure

terraform apply

4. Destroy everything safely when done

terraform destroy

View on GitHub

I Deployed a Live Website on Azure Using Only the CLI, No Portal, No Clicking

Ipadeola Taiwo — Mon, 06 Jul 2026 19:46:15 +0000

There is a certain kind of confidence you only get when you type a command into a terminal and watch an actual server come to life in another part of the world. No dashboard, no wizard, no clicking through screens. Just you, a terminal, and a set of decisions you have to make yourself.

That is exactly what I set out to do. The brief was simple to read but not simple to execute: deploy a Linux server on Azure, connect to it, configure it, secure it properly, and document the whole process the way a real DevOps engineer would, as a runbook someone else could follow and trust.

I want to walk you through how I did it, the mistakes I made along the way, and how you can follow the same path yourself if you are trying to build this skill.

Why I Did This the Hard Way

It is tempting to open the Azure portal, click a few buttons, and have a server running in minutes. That works, but it does not teach you anything that scales. The moment you need to provision ten servers, or repeat the same setup for a client, clicking through a UI becomes a liability rather than a convenience.

So I chose the terminal instead. Every resource group, every network, every rule was created with a command I typed myself, so that I would actually understand what was happening underneath.

Step One, Giving the Project a Home

Every resource in Azure needs a container to live in, called a resource group. Think of it as the folder that keeps everything related to one project together, so you can manage it, monitor it, or delete it as a single unit later.

az group create --name hagital-rg --location eastus

That one line created a logical home for everything that followed.

Step Two, Building the Network Before the Server

Before you can have a server, you need a network for it to live inside. This is one of those things that feels backwards if you are used to clicking through a portal, where the network gets created for you automatically. On the CLI, you build it yourself, which forces you to actually understand how the pieces fit together.

az network vnet create \
  --resource-group hagital-rg \
  --name provion-server-vnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name provison-server-subnet \
  --subnet-prefix 10.0.0.0/24

I then double checked everything before moving forward, because catching a mistake here is far easier than catching it after a server is already attached to the wrong network.

az network vnet show \
  --resource-group hagital-rg \
  --name provion-server-vnet \
  --query "{VNet:addressSpace.addressPrefixes, Subnets:subnets[].addressPrefix}"

Step Three, Bringing the Server to Life

With the network ready, I created the virtual machine itself, an Ubuntu server, placed directly inside the network I had just built.

az vm create \
  --resource-group hagital-rg \
  --name hagital-server \
  --image Ubuntu2204 \
  --size Standard_B1ls \
  --vnet-name provion-server-vnet \
  --subnet provison-server-subnet \
  --admin-username azureuser \
  --generate-ssh-keys

One detail worth mentioning here, something that genuinely surprised me. When you create a server through the Azure portal, you are usually handed a private key file to download and guard carefully. On the CLI, the generate-ssh-keys flag handles that for you. Azure generates the key pair locally and wires up the public key automatically, so there is no separate file to lose track of. Small detail, but it changed how I think about secure access.

Step Four, Locking the Front Door, Then Only Opening What Is Needed

A server exposed to the entire internet on every port is a server waiting to be compromised. So the very next thing I did was open only the two ports this server actually needed, port twenty two for SSH access, and port eighty for web traffic. Nothing else.

Opening the first port went smoothly.

az vm open-port --resource-group hagital-rg --name hagital-server --port 22

Opening the second one did not.

az vm open-port --resource-group hagital-rg --name hagital-server --port 80

Azure responded with an error I had never seen before.

SecurityRuleConflict: Security rule open-port-22 conflicts with rule open-port-80. Rules cannot have the same Priority and Direction.

This is the part of the process that actually taught me something. In Azure, every firewall rule, called a network security group rule, has a priority number, and two inbound rules cannot share the same one. The open port command always tries to use the same default priority, nine hundred, no matter how many times you run it. My SSH rule had already claimed that number, so the HTTP rule had nowhere to go.

I checked the existing rules to see exactly what was going on.

az network nsg rule list --resource-group hagital-rg --nsg-name hagital-serverNSG --output table

Once I understood the cause, the fix was straightforward. I created the HTTP rule manually and gave it its own priority instead of relying on the default.

az network nsg rule create \
  --resource-group hagital-rg \
  --nsg-name hagital-serverNSG \
  --name AllowHTTP \
  --priority 910 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 80

That single error taught me more about how Azure firewall rules work than any tutorial had, because I had to actually understand the priority system to solve it myself.

Step Five, Walking In Through SSH

With the network secured, I fetched the server's public IP address and connected directly.

az vm show --resource-group hagital-rg --name hagital-server --show-details --query publicIps --output tsv

ssh azureuser@<public-ip>

No password prompt, no key file to search for, just a clean connection using the key pair Azure had already set up.

Step Six, Giving the Server a Job

A bare server does nothing on its own. I installed Nginx, a lightweight and widely used web server, so the machine could actually serve web pages to anyone who visited its address.

sudo apt update
sudo apt install nginx -y

Running an update before the install is a habit worth keeping. It refreshes the list of available packages so you are installing the current version rather than something outdated sitting in a stale cache.

A quick check confirmed everything was running as expected.

systemctl status nginx

Step Seven, Getting My Own Project Onto the Server

At this point the server could serve a web page, just not mine yet. I copied a portfolio project, built with plain HTML, CSS and JavaScript, from my local machine onto the server using secure copy.

scp -r ./devops_portfolio azureuser@<public-ip>:/tmp/

The next step introduced two more mistakes, both worth sharing because they are easy to make and easy to learn from.

The first attempt tried to move the entire project folder directly onto the location of the existing default web page, and Azure's server refused, since you cannot replace a single file with an entire folder.

The second attempt failed for a different reason, a plain permission error, since the folder that serves web content on a Linux server is owned by the system, not by the everyday user account.

The working solution handled both issues at once, moving the contents of the folder rather than the folder itself, and running the command with elevated permission.

sudo mv /tmp/devops_portfolio/* /var/www/html/

A moment later, visiting the server's public address in a browser showed my actual portfolio, live, served from a machine I had built entirely from a terminal.

Turning the Whole Process Into a Script

Doing this manually taught me the mechanics, but repeating it manually every time would not scale, and would not reflect how this is actually done professionally. So I converted the entire workflow into a bash script, with each stage wrapped in its own function, resource group creation, network creation, server creation, and a reusable function for opening ports safely, one that checks whether a rule already exists before attempting to create it again.

Running the whole provisioning process now takes one command and finishes in a matter of seconds, something that used to take a series of manual steps and careful attention to avoid the exact mistakes I described above.

What This Project Actually Demonstrates

If you are a recruiter or a hiring manager reading this, here is what I want you to take away. This was not a copy and paste exercise. Every command here was typed, tested, and in more than one case, broken and then fixed by understanding the actual cause rather than guessing. I hit a real Azure networking conflict and resolved it by reading the error and understanding how security rule priorities work. I hit a real Linux permissions issue and resolved it the same way.

I also wrote the entire process up as a runbook, the kind of documentation a real engineering team would expect, so that anyone on a team could follow these exact steps and get the same result, safely and predictably.

The live result of this project is a working website, served entirely from infrastructure I provisioned, secured and configured myself, from the terminal, from the ground up.

If you would like to see the full runbook, the automation script, or talk through any part of how this was built, I would genuinely welcome the conversation. This is exactly the kind of work I want to keep doing.

Below is the link to my github repo

highpee1991 / azure-cli-lab

My Azure CLI learning journey from beginner to pro

Day 01 — Azure CLI Basics

What I Learned

Azure CLI is a tool that lets you manage Azure resources from the terminal...

Commands I Ran

Check version

az --version

Output: azure-cli 2.87.0

core 2.87.0 telemetry 1.1.0

Dependencies: msal 1.36.0 azure-mgmt-resource 24.0.0

Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe' Config directory 'C:\Users\Relitorin Orders.azure' Extensions directory 'C:\Users\Relitorin Orders.azure\cliextensions'

Python (Windows) 3.13.13 (tags/v3.13.13:01104ce, Apr 7 2026, 19:25:48) [MSC v.1944 64 bit (AMD64)]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

Login to Azure

az login
az account show

Output: Retrieving tenants and subscriptions for the selection...

[Tenant and subscription selection]

No Subscription name Subscription ID Tenant

[1] * Azure subscription 1 Default Directory

The default is marked with an *; the default tenant is 'Default Directory' and subscription is 'Azure subsc ription 1' ().

Select a subscription and tenant (Type a number or Enter for no changes):

Tenant: Default Directory Subscription: Azure subscription…

View on GitHub

Multi-Region VNet Peering + Global Load Balancer on Azure, A Step-by-Step Guide

Ipadeola Taiwo — Mon, 29 Jun 2026 19:12:04 +0000

What We're Building

A Nigerian fintech has two offices, Lagos and Abuja and wants:

Both offices on the same private network, even though they sit in different parts of the world
A web app running on a server in each office
Traffic automatically routed to whichever office is closest to the user, with automatic failover if one office's server goes down

To simulate this on Azure, Lagos lives in East US and Abuja lives in South Africa North two genuinely different Azure regions, connected privately, with a global load balancer deciding where to send traffic.

By the end of this guide, you'll have a working multi-region setup you can test from your own terminal.

What you'll need

An Azure account (the free tier works fine)
Basic comfort with the Azure Portal
A terminal that can run ssh and curl (Git Bash, macOS/Linux terminal, or Cloud Shell)

Step 1: Create a Resource Group

A resource group is just a logical folder that holds everything we build, so it's easy to manage or delete later as one unit.

In the Azure Portal, search "Resource groups" → + Create
Resource group name: fintech-rg
Region: pick any region for the resource group itself, it doesn't have to match the resources inside it
Review + Create → Create

Step 2: Create Two Virtual Networks (VNets)

A VNet is a private network inside Azure. We need one for each branch office, in two different regions.

VNet for Lagos (East US)

Search "Virtual networks" → + Create
Resource group: fintech-rg
Name: lagos-vnet
Region: East US
Leave the default address space and subnet, or customize if you prefer
Review + Create → Create

VNet for Abuja (South Africa North)

Repeat the same steps:

Name: abuja-vnet
Region: South Africa North
Review + Create → Create

Step 3: Peer the Two VNets Together

VNet Peering connects the two networks so resources inside them can talk to each other using private IP addresses, as if they were on the same local network, no public internet involved.

Peering needs to be set up from both sides once from Lagos's VNet pointing to Abuja, and once from Abuja's VNet pointing to Lagos.

From the Lagos VNet

Open lagos-vnet → left menu → Peerings → + Add
This virtual network:
- Peering link name: lagos-to-abuja
- Allow traffic to remote virtual network: ✅ enabled
Remote virtual network:
- Peering link name: abuja-to-lagos
- Virtual network: select abuja-vnet
- Allow traffic to remote virtual network: ✅ enabled
Add

This single step actually creates both sides of the peering at once.

Confirm the Peering Is Connected

Go back to lagos-vnet → Peerings
You should see the peering listed with status: Connected
Check abuja-vnet → Peerings too — it should show Connected from its side as well

Step 4: Create a VM in Each VNet

VM for Lagos

Search "Virtual machines" → + Create
Resource group: fintech-rg
VM name: lagos-vm
Region: East US
Image: Ubuntu Server (any recent LTS version)
Size: the default/smallest size is fine for this project
Authentication: SSH public key (recommended) or password
Username: lagosvm (or whatever username you prefer, just stay consistent for the rest of the guide)
Networking tab: Virtual network → select lagos-vnet
Review + Create → Create

VM for Abuja

Repeat with:

VM name: abuja-vm
Region: South Africa North
Username: abujavm
Virtual network: abuja-vnet

Once both VMs are created, note down:

Each VM's public IP (used to SSH in)
Each VM's private IP (used for the ping test later)

In this guide, the private IPs are:

Lagos VM private IP: 10.0.0.4
Abuja VM private IP: 10.1.0.4

(Yours may be different — always use the actual IP shown in your VM's Overview or Networking tab.)

Step 5: Secure SSH Access and Connect to Each VM

If you're using an SSH key pair, make sure your private key file has the correct permissions before connecting, otherwise SSH will refuse to use it:

chmod 700 lagosvm_key.pem

(Do the same for the Abuja key if you're using a separate one.)

Connect to the Lagos VM:

ssh -i lagosvm_key.pem lagosvm@<lagos-vm-public-ip>

Connect to the Abuja VM in a separate terminal tab:

ssh -i abujavm_key.pem abujavm@<abuja-vm-public-ip>

Step 6: Install and Start a Web Server on Each VM

Run this on both VMs:

sudo apt update && sudo apt upgrade -y
sudo apt install apache2 -y
sudo systemctl start apache2
sudo systemctl enable apache2

apt update && upgrade refreshes the package list and applies any pending updates
apache2 is the web server that will respond to HTTP requests
enable makes sure Apache automatically restarts if the VM ever reboots

Confirm Apache is running on each VM:

sudo systemctl status apache2

You should see active (running) in green.

Step 7: Test the Private Network Connection (Ping Test)

This is the moment that proves the VNet peering actually works — two VMs, in two different regions, reaching each other over a private connection.

From the Lagos VM, ping Abuja's private IP:

ping 10.1.0.4

From the Abuja VM, ping Lagos's private IP:

ping 10.0.0.4

If peering is working correctly, you'll see successful replies on both sides, something like:

64 bytes from 10.1.0.4: icmp_seq=1 ttl=64 time=142 ms

Press Ctrl + C to stop the ping.

⚠️ Note: If you don't get replies, double check that each VM's Network Security Group (NSG) allows inbound traffic from the peered VNet (the default AllowVnetInBound rule usually covers this automatically).

Step 8: Customize Each Web Page So You Can Tell Them Apart

To visually confirm which server is responding later (especially once the load balancer is involved), give each VM a distinct homepage.

On the Lagos VM:

echo "<h1>Hello from Lagos Server</h1>" | sudo tee /var/www/html/index.html

On the Abuja VM:

echo "<h1>Hello from Abuja Server</h1>" | sudo tee /var/www/html/index.html

Test it directly using each VM's public IP in a browser:

http://<lagos-vm-public-ip>
http://<abuja-vm-public-ip>

You should see the matching "Hello from..." message for each one.

Step 9: Open Port 80 on Both VMs

Apache runs on port 80, so each VM's NSG needs to allow inbound HTTP traffic — otherwise external requests (including from the load balancer) won't be able to reach it.

Open each VM → Networking tab → Add inbound port rule
Settings:
- Destination port: 80
- Protocol: TCP
- Action: Allow
- Give the rule a name (anything descriptive works, e.g. Allow-HTTP)
Add
Repeat for the other VM

Step 10: Create the Regional Load Balancer for Lagos

Since Lagos and Abuja are in different regions, we can't use one single load balancer to cover both — a standard Azure Load Balancer only operates within a single region. We need one regional load balancer per region, and later, a Global Load Balancer sitting on top of both.

10.1 — Create the Public IP

Search "Public IP addresses" → + Create
Give it a name (e.g. lagos-lb-ip)
SKU: Standard
Tier: Regional
Region: East US
Assignment: Static
Review + Create → Create

10.2 — Create the Load Balancer

Search "Load balancers" → + Create
Give it a name (e.g. lagos-lb)
Region: East US
SKU: Standard
Type: Public
Tier: Regional
Frontend IP configuration: add a frontend IP, give it a name, and select the public IP you just created (lagos-lb-ip) — this becomes your regional frontend IP, in this guide 20.121.242.74
Skip backend pools and rules for now — we'll add them after creation for a cleaner setup
Review + Create → Create

10.3 — Add the Backend Pool

Open your Lagos load balancer → Backend pools → + Add
Give it a name
Virtual network: select lagos-vnet
Backend pool configuration: NIC
Click + Add under the IP configurations table → select lagos-vm
Save

10.4 — Add a Health Probe

Health probes → + Add
Give it a name
Protocol: HTTP
Port: 80
Path: /
Interval: 5–15 seconds
Add

10.5 — Add the Load Balancing Rule

Load balancing rules → + Add
Give it a name
Frontend IP: select the frontend IP you created
Backend pool: select the backend pool you created
Health probe: select the probe you created
Protocol: TCP, Port: 80, Backend port: 80
Add

10.6 — Test the Lagos Load Balancer

From your terminal:

curl http://20.121.242.74

(replace with your actual Lagos load balancer frontend IP)

You should see the "Hello from Lagos Server" response.

Step 11: Create the Regional Load Balancer for Abuja

Repeat all of Step 10, but for the Abuja region:

Public IP: give it a name, Region: South Africa North → in this guide, the resulting frontend IP is 20.87.39.70
Load Balancer: give it a name, Region: South Africa North
Backend pool: Virtual network → abuja-vnet, add abuja-vm
Health probe and rule: same settings as before (HTTP/80//, TCP/80→80)

Test it:

curl http://20.87.39.70

You should see "Hello from Abuja Server."

⚠️ Important: Don't move to the next step until both regional load balancers pass this test independently. The Global Load Balancer depends on both of these already working correctly.

Step 12: Create the Global Load Balancer

The Global Load Balancer sits above both regional load balancers and decides which region to send each user's request to, based on which one is geographically closest and healthy.

12.1 — Create the Global Public IP

Search "Public IP addresses" → + Create
Give it a name (e.g. global-lb-ip)
SKU: Standard
Tier: Global
Region: must be one of Azure's supported home regions for global resources, examples include East US 2, West Europe, Southeast Asia, West US, North Europe, Central US
Assignment: Static
Review + Create → Create

In this guide, the resulting global IP is 20.15.1.61.

12.2 — Create the Global Load Balancer

Search "Load balancers" → + Create
Give it a name (e.g. global-lb)
Region: the same home region you used for the global IP (e.g. East US 2)
SKU: Standard
Tier: Global ⚠️ this is the setting that matters most here — don't select Regional
Frontend IP configuration: add a frontend IP, give it a name, and select your global-lb-ip
Skip backend pools and rules in the wizard
Review + Create → Create

12.3 — Add the Backend Pool

Open your Global load balancer → Backend pools → + Add
Give it a name
Under the configuration table, click + Add
Type: Load Balancer (not NIC, not IP address)
Add your Lagos load balancer
Click + Add again and add your Abuja load balancer
Confirm both regional load balancers now appear in the table
Save

12.4 — Add the Load Balancing Rule

Load balancing rules → + Add
Give it a name
Frontend IP: your global frontend IP
Backend pool: your global backend pool
Protocol: TCP, Port: 80, Backend port: 80

The backend port here must match the frontend port used in both regional load balancer rules — in this case, both use port 80, so we're consistent.

Add

Step 13: Test the Global Load Balancer

curl http://20.15.1.61

(replace with your actual global load balancer IP)

You should get back a response from whichever region is closest to you, for example, "Hello from Lagos Server."

This is expected behavior: the Global Load Balancer uses geo-proximity routing, not round robin. It always routes you to the closest healthy region, not a random alternating split.

Step 14: Test Automatic Failover

To prove the system can actually fail over between regions, we'll simulate one region going down.

SSH into the Lagos VM and stop Apache:

sudo systemctl stop apache2

Now curl the global load balancer again:

curl http://20.15.1.61

This time, the response should switch to "Hello from Abuja Server" Azure detected that the Lagos region's health probe failed, removed it from rotation, and automatically routed traffic to the healthy Abuja region instead.

Once you're done testing, restart Apache on the Lagos VM so it's back in rotation:

sudo systemctl start apache2

Recap: What We Actually Built

Client
  ↓
Global Load Balancer (home region, e.g. East US 2)
  ↓                              ↓
Regional LB - Lagos          Regional LB - Abuja
(East US)                    (South Africa North)
  ↓                              ↓
lagos-vm                     abuja-vm
  ↳ peered privately with abuja-vm via VNet Peering

This setup demonstrates three real-world cloud concepts at once:

Private cross-region connectivity (VNet Peering)
Regional high availability (each region's own load balancer and health probe)
Global resilience and failover (the Global Load Balancer routing around an unhealthy region automatically)

If you build this yourself, try the failover test a few times — watching traffic automatically reroute in real time is genuinely satisfying, and it's the same underlying pattern real fintechs use to stay online across regions.

Got stuck somewhere or have a question about a specific step? Drop a comment below 👇

Day 2 — I Stopped Being a Student and Started Acting Like a DevOps Engineer

Ipadeola Taiwo — Sun, 28 Jun 2026 08:32:59 +0000

This is Day 2 of my 90-day cloud engineering challenge. Day 1 was about installing tools and getting familiar with the Azure CLI. Day 2 was different — instead of just running commands to learn syntax, I gave myself a real-world scenario and worked through it the way an actual DevOps engineer would on the job.

The Scenario

To push myself past "tutorial mode," I simulated a message from a team lead:

"Taiwo, we need a new environment for the payments project. Create a resource group for dev, one for staging. Tag them properly. Create a storage account in dev. List everything and send me a clean output. Then document it."

No step-by-step instructions. No exact commands handed to me — just a goal. That's closer to how real work actually shows up: as an outcome someone needs, not a tutorial to follow. My job was to translate that into the right CLI commands, tag things properly, and produce a clean, professional result.

Commands I Used

Listing and inspecting resource groups

az group list
az group list --output table
az group list --output tsv
az group list --output jsonc

I started by getting comfortable with different output formats. In a real environment with dozens or hundreds of resources, raw JSON is hard to scan quickly — table and tsv make it much easier to read at a glance or pipe into other tools/scripts.

Filtering with `--query`

az group list --query "[].{Name:name, Location:location}" --output table
az group list --query "[?location=='eastus'].name" --output table
az account show --query "name" --output tsv

This is where things started feeling like real engineering rather than just running commands. --query lets you filter and reshape the JSON output before it even hits your screen — instead of scrolling through everything, you ask for exactly what you need. When you're dealing with 200+ resources, this isn't optional; it's how you stay sane.

Tagging resources properly

az group update \
  --name taiwo-devops-rg \
  --tags Environment=Dev Owner=Taiwo Project=AzureCLILab

az group show \
  --name taiwo-devops-rg \
  --query "tags" \
  --output table

Tags seem like a small detail until you realize how much they matter in a real company. Tags answer three questions instantly, for any resource, at any scale:

Who owns it?
What project does it belong to?
What environment is it — dev, staging, or production?

Without consistent tagging, a subscription with hundreds of resources becomes nearly impossible to manage, audit, or clean up safely.

The Automation Script

Rather than running each command by hand every time I needed an environment, I wrote a Bash script to provision the entire setup — dev resource group, staging resource group, and a storage account — in one run:

#!/bin/bash

# ============================================
# Azure Environment Provisioner
# Author: Taiwo
# Description: Provisions dev environment
#              for any project automatically
# ============================================

# Variables — change these for any project
PROJECT="payments"
OWNER="Taiwo"
LOCATION="eastus"
STORAGE_NAME="taiwo${PROJECT}dev001"

echo "🚀 Starting provisioning for project: $PROJECT"

# Step 1: Create Dev Resource Group
echo "📁 Creating Dev Resource Group..."
az group create \
  --name "${PROJECT}-dev-rg" \
  --location "$LOCATION" \
  --tags Environment=Dev Owner=$OWNER Project=$PROJECT

# Step 2: Create Staging Resource Group
echo "📁 Creating Staging Resource Group..."
az group create \
  --name "${PROJECT}-staging-rg" \
  --location "$LOCATION" \
  --tags Environment=Staging Owner=$OWNER Project=$PROJECT

# Step 3: Create Storage Account
echo "💾 Creating Storage Account..."
az storage account create \
  --name "$STORAGE_NAME" \
  --resource-group "${PROJECT}-dev-rg" \
  --location "$LOCATION" \
  --sku Standard_LRS \
  --kind StorageV2 \
  --tags Environment=Dev Owner=$OWNER Project=$PROJECT

# Step 4: Confirm everything
echo "✅ Provisioning complete. Here is your environment:"
az group list --output table

echo "🎉 Done! Project $PROJECT environment is ready."

The script takes a few simple variables — project name, owner, and location — and provisions a complete environment from scratch, consistently, every single time. Change the PROJECT variable and the same script provisions an environment for a completely different project. That's the difference between "I ran some commands" and "I built something reusable."

Bonus: A Git Workflow Script

Outside of the Azure work itself, I also wrote a small Bash script to speed up my Git workflow — staging, committing, and pushing in a single command instead of typing three separate ones every time:

#!/bin/bash
# Exit if any command fails
set -e
trap 'echo "❌ A command failed. Exiting..."' ERR

echo "Current branch: $(git branch --show-current)"

# Stage all changes
git add .

# Prompt for commit message
while true; do
    read -p "Enter a commit message: " commitMessage
    if [ -n "$commitMessage" ]; then
        break
    fi
    echo "Commit message cannot be empty."
done

# Commit and push
git commit -m "$commitMessage"
git push

echo "✅ Changes committed and pushed successfully."

Small touches here matter: set -e and the trap ensure the script stops cleanly the moment something fails instead of plowing ahead, and the commit-message prompt won't let me accidentally push with an empty message. It's a small script, but it's the kind of "make my own workflow faster" thinking that DevOps is built on.

What This Taught Me About Real DevOps Work

Today reframed how I think about the CLI. It's not just a faster way to click buttons — it's a tool for repeatability, filtering, and automation at a scale where doing things manually simply breaks down.

In a real company, this is what the day-to-day actually looks like:

Spinning up a storage account for a dev team on request
Checking what resources are currently running in production
Cleaning up a test environment left over from last sprint
Standing up a new resource group for a new project
Filtering out the handful of failed resources from a list of 200+
Wrapping repeatable tasks into scripts instead of typing them out every time

None of that works well through a portal UI when you're dealing with real scale. It works through commands, queries, tags, and scripts — exactly what I practiced today.

Problems I Faced

The biggest challenge wasn't syntax — it was genuinely understanding why each piece mattered (tagging, querying, scripting) rather than just copying commands. Once I slowed down and researched the reasoning behind each one, things started clicking. I'd rather understand the "why" once than memorize the "what" repeatedly.

What Clicked Today

Provisioned a full dev + staging environment from a single scenario, not a tutorial
Created a Storage Account via CLI inside the correct resource group
Used --query to filter and reshape output like an engineer working at scale
Wrote a reusable Bash automation script for environment provisioning
Wrote a separate Git workflow script to speed up my own commit/push process

What's Next

Day 1 was about learning the tool. Day 2 was about using it to solve a problem someone else gave me. That shift — from "following steps" to "interpreting a request and deciding the steps myself" — is the part I want to keep practicing for the rest of these 90 days.

Following along with a 90-day hands-on cloud engineering challenge. Catch up on Day 1 here.

Azure #DevOps #CloudEngineering #100DaysOfCloud #LearningInPublic #BashScripting

Day 01 — Azure CLI Basics

Ipadeola Taiwo — Tue, 23 Jun 2026 16:07:37 +0000

Welcome to Day 1 of my 90-day cloud engineering challenge! I'm documenting everything I learn as I go — partly to hold myself accountable, and partly because writing things down helps them actually stick.

Today's focus: getting comfortable with the Azure CLI and creating my first resource entirely from the terminal.

What I Learned
The Azure CLI is a command-line tool that lets you manage Azure resources directly from your terminal, without needing to click through the Azure Portal. Once it's installed and you're logged in, you can create, update, and delete resources with simple commands — which is faster and more repeatable than navigating a UI.

Commands I Ran

Install CLI: For me i am on window so i am using below command

winget install --id Microsoft.AzureCLI

Check the installed version

az --version

This confirmed the CLI was installed correctly and showed me the version, dependencies, and Python environment it's running on. Good first sanity check before doing anything else.

az login
az account show

This opens a browser-based login flow and connects the CLI to my Azure account. Once logged in,

confirms which subscription and tenant is currently active — useful for double-checking you're working in the right environment before creating anything.

Create my first Resource Group

az group create --name taiwo-devops-rg --location eastus

Output:

{
  "id": "/subscriptions/<subscription-id>/resourceGroups/taiwo-devops-rg",
  "location": "eastus",
  "managedBy": null,
  "name": "taiwo-devops-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

A Resource Group is basically a container that holds related Azure resources — useful for organizing and managing things together (and for cleaning everything up at once later by just deleting the group).

What This Taught Me
This exercise taught me how to create a resource group and control exactly where it lives (in this case, eastus). More importantly, it showed me how much faster the CLI can be compared to the Azure Portal — no waiting on pages to load, no risk of losing your place if your internet connection hiccups. Just a clean command and a clean output. I can already see why CLI/scripting skills matter so much in DevOps and cloud engineering.

Problems I Faced
Honestly, the biggest challenge today was just remembering the command syntax — this is my first real session using the Azure CLI, so nothing is muscle memory yet. But I expect that to improve quickly with repetition. The more I run these commands, the more naturally they'll come.

Why This Matters in DevOps
This might look like a small win — installing a CLI and creating one resource group — but it ties directly into how real DevOps workflows operate:

Automation over manual clicks: DevOps is built on repeatable, scriptable processes. A command like az group create can be dropped into a CI/CD pipeline, a shell script, or an Infrastructure-as-Code workflow — something you simply can't do with portal clicks.
Consistency: Running the same command always produces the same result. That predictability is exactly what you want when provisioning environments for dev, staging, and production.
Foundation for IaC: Tools like Terraform, Bicep, and ARM templates all build on the same underlying concepts I practiced today — resource groups, regions, and subscriptions. Getting comfortable with the CLI now makes those tools click faster later.
Faster feedback loops: Typing a command and getting an immediate JSON response is a much quicker feedback loop than navigating multiple portal pages, which matters when you're iterating quickly or troubleshooting under time pressure.

In short: today wasn't just about "I made a resource group." It was about building the muscle memory and mindset that DevOps engineers rely on every day — treating infrastructure as something you script and version, not something you click through.

What's Next
This is Day 1 of 90. Tomorrow I'll be building on this foundation — likely exploring more az commands and starting to provision some actual resources inside this resource group.

Follow along with the rest of the series as I document 90 days of hands-on cloud engineering learning.

_#Azure #CloudEngineering #DevOps #100DaysOfCloud #LearningInPublic

Building a Multi-Region Load Balancer on Azure for a Nigerian Fintech (Lagos ↔ Abuja) — A Real Troubleshooting Story

Ipadeola Taiwo — Wed, 17 Jun 2026 13:13:35 +0000

The Scenario
Imagine a Nigerian fintech — think Flutterwave-style — with offices in Lagos **and **Abuja. Both offices need to:

Sit on the same private network (even though they're in different Azure
regions)Serve a web app from two VMs, load-balanced, so if one office's
server goes down, traffic keeps flowing through the other
This post walks through exactly how I built this on Azure — including every error I hit along the way, because honestly, the errors taught me more than the parts that worked first try.

If you're following along, you'll need an Azure account (the free tier works) and basic comfort with SSH.

Part 1: Two VNets, Two Regions, One Private Network
The first task was creating two Virtual Networks (VNets) in different Azure regions and peering them together so they could talk to each other privately — no public internet involved.

VNet 1 (Lagos) → South Africa North
VNet 2 (Abuja) → East US 2

After creating both VNets, I set up VNet Peering between them. This is what allows resources in one VNet to reach resources in the other using private IP addresses, as if they were on the same local network — even though they're physically thousands of kilometers apart.

Part 2: One VM Per Region, Proving They Can Talk
Next, I deployed one Linux VM in each VNet:

vm-lagos in South Africa North
vm-abuja in East US 2

To prove the peering actually worked, I SSH'd into each VM and pinged the other one's private IP address:

ping 10.1.0.4

Getting replies back here was the moment it clicked — two VMs in completely different parts of the world, talking over a private network, no public internet hop required.

Part 3: The Load Balancer — Where Things Got Interesting
This is the part of the project that taught me the most, because almost nothing went smoothly. I'll walk through it the way it actually happened, mistakes included, because I think that's more useful than a sanitized "perfect setup" guide.

My First Plan (That Didn't Work)
My first instinct was: "just create one regular Azure Load Balancer, point it at both VMs, done."
That seemed reasonable until I remembered a key constraint: a standard Azure Load Balancer only works within a single region. My two VMs were in two different regions. A regional load balancer physically can't span across them.
So I had two real options:
Option 1
Fake it by routing cross-region traffic through one region's LB
What it means
Works in theory, but not how Azure actually supports it in production

Option 2
Use Azure's Cross-Region (Global) Load Balancer
What it means
The actual purpose-built solution for exactly this scenario
I went with the proper solution: the Global Load Balancer.

You can't just create one Global LB and point it straight at two VMs. The Global LB sits on top of two regional load balancers — one per region — and routes traffic between regions, while each regional LB handles traffic within its own region.
This means I needed three load balancers total:

A Regional LB in South Africa North (for Lagos)
A Regional LB in East US (for Abuja)
One Global LB sitting above both

Step 1: Web Server on Both VMs
Before touching any load balancer, both VMs needed something to actually serve over HTTP. I installed apache2 on each and customized the homepage so I could visually tell which VM was responding:

sudo apt update && sudo apt install apache2 -y
sudo systemctl start apache2
sudo systemctl enable apache2
echo "<h1>Lagos Server Loaded</h1>" | sudo tee /var/www/html/index.html

(and the equivalent "Abuja Server Loaded" on the other VM)

Step 2: Open Port 80
Each VM's Network Security Group (NSG) needed an inbound rule allowing TCP traffic on port 80, otherwise the web server would be running but unreachable from outside.

Step 3: Build the Two Regional Load Balancers
I created one Standard SKU Public Load Balancer in each region, each with:

A frontend public IP
A backend pool containing that region's VM
A load balancing rule on port 80
A health probe checking HTTP on port 80

At this point, hitting either regional LB's public IP directly in a browser correctly returned that region's "Hello from..." page. Good sign — the foundation was solid.

Part 4: Where I Actually Got Stuck (And How I Fixed Each Thing)
This is the part I really want to highlight, because I think showing the actual errors is more useful than pretending everything worked first try.
🔴 Error 1: "No matching inventory for the requested VIP"
When I tried to create the Global Load Balancer for the first time, Azure threw this:
"No matching inventory for the requested VIP of address family: IPv4, sku: Standard and availability zone: non-zonal."

What was actually happening: Azure's Cross-Region/Global Load Balancer can only be deployed in specific "Home regions" — a fixed list that includes places like East US 2, West Europe, Southeast Asia, and a handful of others. I had originally tried creating it in a region that wasn't on that list.
The fix: I deleted the failed Public IP and Load Balancer, and recreated both in East US 2 specifically, with the Public IP's tier set to Global.

🤔 Question I had to clear up: "Does everything need to move to a Home region?"
Once I learned about the Home region restriction, I panicked a little — did my Resource Group, VNets, and VMs all need to be in one of these special regions too? That would've defeated the entire point of the assignment (having Lagos and Abuja in genuinely different regions).
Turns out: no. Only the Global Load Balancer itself and its Public IP need to be in a Home region. Everything else — the Resource Group, both VNets, both VMs, and both Regional Load Balancers — can stay exactly where they logically belong. The Home region is just where the Global LB's control plane lives; it doesn't dictate where your actual infrastructure sits.

🔴 Error 2: Global LB deployed, but curl couldn't connect at all
After fixing the region issue, the Global LB deployed successfully. But testing it with:

curl http:/20.15.2.121

...just hung and timed out.

What was actually happening: When I went to check the regional backend pool configuration, I found the Virtual Network field was empty — meaning the backend pool existed and was attached to a load balancing rule, but had zero actual VMs inside it. It looked configured, but it was an empty shell.

The fix: Selecting the correct VNet from the dropdown revealed an "+ Add" button I hadn't seen before, which let me actually add the VM's NIC to the pool.

Lesson learned: a backend pool being "attached to a rule" doesn't mean it has members in it. Always double check the actual VM/IP table, not just whether the pool exists.

Final puzzle: "Why does my Global LB always show the same region?"
Everything was technically working now — both regional LBs responded correctly, and the Global LB no longer timed out. But running curl against the Global LB's IP over and over only ever returned the Abuja server, never Lagos, no matter how many times I refreshed or switched browsers.

My first thought: something's broken, it should be alternating like a normal load balancer.

What was actually happening: This is expected behavior, not a bug. A regional load balancer round-robins between backend VMs. A Global Load Balancer works completely differently — it uses geo-proximity routing, meaning it looks at where the request is physically coming from and always sends it to the closest healthy region. Since I was testing from one physical location every time, it consistently picked the same region — exactly as designed.

This actually makes total sense for the original use case: a Lagos-based customer should get routed to the Lagos backend, and a US-based customer should get routed to the US backend, automatically, without anyone configuring anything manually.

How I proved both regions actually worked:

Curl each regional LB's IP directly — both returned their correct, distinct pages.
Simulated a regional failure by stopping apache2 on the Abuja VM, then curled the Global LB IP again — it correctly failed over and served the Lagos page instead.

# On the Abuja VM
sudo systemctl stop apache2

# From my laptop
curl http:/20.15.2.121
# Now returns "Lagos Server Loaded" instead

Don't forget to restart apache2 afterward:

sudo systemctl start apache2

What I'd Tell Someone Starting This Project
If I were doing this again, here's what I'd want to know upfront:

A regional Load Balancer cannot span two regions, full stop. If your VMs are in different regions, you need the Global tier sitting on top of two regional LBs underneath it — not one LB trying to do everything.
The Global LB has region restrictions ("Home regions") that your other resources don't. Don't panic and try to move your whole architecture — only the Global LB and its Public IP care about this.
Always verify backend pools actually have members, not just that they exist. An empty backend pool with a rule attached looks deceptively "configured."
Global Load Balancer ≠ round robin. It's geo-proximity based. If you're testing from one location and only ever see one region respond, that's correct behavior, not a failure — test failover instead to prove redundancy.

Final Result
By the end, hitting the Global Load Balancer's public IP correctly served traffic from the geographically closest healthy region, and killing nginx on one VM correctly triggered failover to the other — proving genuine multi-region high availability, the same pattern a real fintech would rely on to keep Lagos and Abuja customers online even if one region had issues.
If you're working through something similar, I hope walking through the actual errors (not just the final clean steps) saves you some of the head-scratching it cost me.
Questions or got stuck somewhere different? Drop a comment below 👇

Creating a Custom RBAC Role in Azure for VM Operations

Ipadeola Taiwo — Tue, 12 May 2026 04:01:41 +0000

Introduction
In cloud environments, giving users excessive permissions can introduce major security risks. One of the key principles of cloud security is the principle of least privilege, where users receive only the permissions required to perform their tasks.

In this hands-on project, I implemented a custom Role-Based Access Control (RBAC) role in Microsoft Azure to allow a user manage virtual machines without granting full administrative access.

The custom role allowed the user to:

Start virtual machines
Stop virtual machines
View virtual machines

While restricting the user from:

Deleting virtual machines
Modifying networking resources
Assigning IAM roles

This project helped me gain practical experience with:

Azure IAM and RBAC
Custom role creation
Least privilege security
Resource Group scoped permissions
Permission testing and validation

Scenario
The DevOps team required a user who could operate virtual machines for daily operational tasks without having permission to delete resources or manage access control settings.

Project Objectives

Create a custom RBAC role
Assign VM-specific permissions
Restrict unnecessary privileges
Assign role at Resource Group level
Validate access using a test user

Environment Setup

Resource Group
Virtual Machine
Test user (ops-user)

First we need to create our resource groups, to see guide on RG click the link below on one of our article on creating resource groups

Ipadeola Taiwo

Mar 17

How to Create a Resource Group in Azure (Step-by-Step Guide)

#azure #cloudcomputing #devops #microsoft365

3 min read

Next is to create our user
we would be brief with this step
first search on the console search bar miscrosoft entra ID
Click on the results
Go to manage and click on users, create users
to see step by step guide on creating a user, click on the link below to see full details on creating a user

Ipadeola Taiwo

May 8

Implementing RBAC in Azure for Secure Resource Group Access

#azure #cloud #security #tutorial

5 min read

Next step is to Create the Custom Role:
To create the custome role follow below step
first go to the resource group created, click on access control (IAM), click on add, add custome role

Give the custom role a name, and description

Click on next
Click on add permission

since the role we want to assign is read (view), start and stop (deallocate)
we would would input this in the search for permission Microsoft.Compute/virtualMachines this allow us to have access to virtual machine control, click on the result microsoft compute then go further by adding /read to the path after clicking on the microsoft compute, select permission and click on add

The read permision will be added

we would do the same thing for start
we would click on add permision again, where we have search for a permission we would input this again Microsoft.Compute/virtualMachines and click on microsoft compute after then add /start to the path click on the permission start vm and add

this will add the start permission to the list of our created custom role

next is to create custom role to stop vm in azure it is not called stop but deallocate so we would do the same thing as we have been doing before click on add permison, paste Microsoft.Compute/virtualMachines in the in the search bar and click on miscrosoft compute add /deallocate to the path and select the permission, so this give it the power to stop the vm
Our permission should look like this

this add the read, start and stop power custome role, click next, asignable scope we leave it as defaults, then we have our json created

{ "properties": { "roleName": "VM Operator", "description": "The custom role allowed the user to:\n- Start virtual machines\n- Stop virtual machines\n- View virtual machines", "assignableScopes": [ "/subscriptions/732a7227-baa8-4458-8e10-4c85a2615397/resourceGroups/vm-Operator-rg" ], "permissions": [ { "actions": [ "Microsoft.Compute/virtualMachines/read", "Microsoft.Compute/virtualMachines/start/action", "Microsoft.Compute/virtualMachines/deallocate/action" ], "notActions": [], "dataActions": [], "notDataActions": [] } ] }}

Click next and create

for security restriction, i intenstionally did not include
Microsoft.Authorization/*
Microsoft.Network/*
Microsoft.Compute/virtualMachines/delete

this prevented

IAM modifications
Network changes
VM deletion we would now assign this role to our user ops-user, that we created at the reourse group level, this give the user power to start, stop and view vms's in this resource group For us to assign the role to our user we would go to our resource group vm-operator-rg, that we created click on add

click on add role assigment

on the role search for the custome role we created by typing the name we gave to it, vm operator and select the custome role

click on next
click on select member to add the user we want to give this permision to

select the user and click on select

click on next, then review + assign

we have succesfully created our custome role and assign it to a user

our user can start vm, view vm stop vm, but cannot delete vm or modify IAM

for us to practicalise some of the action we can log in to user ops-user account
first we try assign IAM to the vm from the ops-user account we can see that the add button is greyed there is no permission for the user to do this operation

also let us try and delete the vm

we can see we got an error trying to delete the vm

now let us try stop our running vm

It was a success because we gave the user the power to stop the vm

let us start our vm, we click on start

we succesfully started our vm

Key Security Lessons
Least privilege reduces security risk
Custom roles provide granular control
Resource Group scope limits exposure
Built-in roles may provide excessive permissions

Conclusion
This project demonstrated how custom RBAC roles can be used to enforce least privilege access in Azure environments. Instead of assigning broad built-in roles, custom permissions allowed secure delegation of operational tasks while protecting critical infrastructure and access control configurations.

Thanks for reading

Implementing RBAC in Azure for Secure Resource Group Access

Ipadeola Taiwo — Fri, 08 May 2026 03:14:09 +0000

In modern cloud environments, not every team member should have full access to resources. Proper access control is important for security, accountability, and preventing accidental changes.

In this project, I implemented Role-Based Access Control (RBAC) in Microsoft Azure to manage access to a Resource Group. I created multiple users with different permission levels and ensured that only authorized users could create or modify resources, while others had view-only access.

This hands-on project helped me understand:

Azure IAM and RBAC
Role assignments
Least privilege principle
Resource Group level access control

Project Scenario
A company project is hosted in Azure, and multiple team members require access to the environment. However, not everyone should have full control over the resources.

Objectives

Create a Resource Group
Create users
Assign RBAC roles
Implement least privilege access

Implementation Steps
First create a resource group, this act as logical container for our resoucrces and help us manage our resources easily

To create a resource group click on the search bar in azure console and type resource groups

Click on the resource groups result shown

Nest step is to click on create as shown in the image below

on clicking on the create button it will take you to the next page where you will fill in the following information, information such as selecting subscription, by default azure create subscription1 for us and that is what we would be using in this mini project
next give it a resource group name and also select a region, for this project we would go with the South Africa North (as i am based in Nigeria and is the closed region to my company, choose a region closest to your company)
then click on next

Next you are to select a tag name and value for the resource group to make it easier to search, but this is optional for this project we would leave it blank
Next is to click on review and create after confirmation click on create

we have succesfully created our resource groups

next let us create a user
for this project we would create 3 users

dev-user -> role: Contributor -> Access Level: Create/Edit Resources
tester-user -> role: Reader -> Access Level: View Only
auditor-user -> role: Reader -> Access Level: View Only

To create a user click on the search bar and type microsoft entra ID

Click on microsoft entra ID from the results
Go to manage and click on results

Click on new user, create new user

fill all the information and click on next

Since we want to gie it role from the resource group level we wonrt give it role at this point we would click on review and create and this would create our dev-user

we would create a new user again to do the same thing we did ealier to create our tester-user and our auditor-user

at this state we have our three new users created

Now let us give each users role to what they can do so we dont just give them unnecessary power they do not need to have, for protections and securities reasons

for us to give them role we would go our resource group we created ealier, by typing resource group in the search bar and click on jake-projects-rg we created ealier

Thank click on access control (IAM)

We would click on add -> assign role

let us start assigning role to our dev-user first, since we want to give contributor access control to our dev-user we would role we wouls click on priviledge administrator and search for contributor

Click on the next button
click on User, group, or service principal at the select access to
on the members click on select member in order to add we we want to give this permision to which is our dev-user

now our dev-user have been selected

Next click on review and assign
we have succesfully given role based accessed control to our dev-user

now let us do same thing to our remaining 2 users we want to give read access to

we would do the same thing as above
we would click on add, add role assignment
since the access we want to give to both users are read access only we would click on the job function and select the reader access this restrict the user from creating resources or accidentally deleting the resources but can only view

We would click on the add member and select the member we want to assign this role to in our case is the tester-user, and the auditor-user

we would click on review and assign to complete this
we have succesfully created and assign reader role to both users

When we click on role assigment inside the access control (IAM) in our resource group we can see we have succesfully

now this users can now sign in to their created accounts and do only what they are gicen power to do

The Dev-user can create resources, modify resources work on resources but delete resources and delete the resource group, mind you if the dev user mistakenly delete the resource group it can not be undone

auditor user and tester user can only read but can not create resources can not modify resources and can not delete resources

Security Improvement

During testing, I observed that a user with the Contributor role could delete the entire Resource Group. To improve protection against accidental or unauthorized deletion, Azure Resource Locks can be implemented to restrict deletion operations even for users with elevated resource permissions.