DEV Community: Ipadeola Taiwo

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.

Deploying an Azure Virtual Machine: Networking, SSH, and Apache Setup

Ipadeola Taiwo — Sat, 18 Apr 2026 16:36:19 +0000

Before deploying a virtual machine, we need to create a Resource Group. In Azure, a Resource Group acts as a container that holds all related resources such as virtual machines, networking components, and storage.
Step 1: Create a Resource Group: To create a resource group, type on search box to acces resource group, and create a resource group

After creating the Resource Group, the next step is to configure networking. In Azure, this is done using a Virtual Network (VNet), which provides a private network for your virtual machine.

Before deploying a virtual machine, we need to set up the required networking. In Azure, this is done by creating a Virtual Network (VNet), which allows our VM to communicate securely with other resources.

This leads us to the next step:

Step 2: Create a Virtual Network (VNet): In the Azure portal, search for Virtual Networks using the search bar. Select it, then click on Create to begin setting up a new virtual network.

Select your existing subscription, then choose the Resource Group you created earlier.

Click Next to proceed to the Security tab and leave the default settings unchanged. Continue by clicking Next to the IP Addresses section.

Here, keep the default address space of 10.0.0.0/16, which provides up to 65,536 IP addresses for your virtual network. Delete the default subnet and click next, you can leave the tag blank depends on your choice, review and create your vnet

Step 3: After creating the Virtual Network, open it from the Azure portal. In the left-hand menu, navigate to Settings and select Subnets.

Click on + Subnet to create a new subnet within the virtual network.

Click on +subnet

Give the subnet a name, then set the address range to 10.0.0.0/24.
This subnet mask provides 256 IP addresses.
Finally, click Add to create the subnet.

After setting up the Resource Group, Virtual Network, and Subnet, we are now ready to deploy the Virtual Machine.
These networking components ensure that the VM can communicate securely within the Azure environment

Step 4: Create a Virtual Machine: To deploy our vm we click on the search box in the azure console and click on the virtual machine in the resultof the search

click on create

click on virtual machine

select the created resource group, give it a name, select the region of your choice, (best region closer to the clients)

For Availability Zone, you can select Zone 1 for testing purposes.

Next, choose the operating system for your virtual machine. You can select either Windows or Linux, depending on your use case. For this tutorial, we will proceed with Ubuntu Server 24.04 LTS.

Select the VM size based on your requirements (for training purposes, a smaller size is recommended).

For authentication type, select SSH Public Key for secure access. Then, provide a username for the VM.

Under Inbound port rules, allow public inbound access and select the required ports:

Port 22 (SSH) – for connecting to your VM
Port 80 (HTTP) – for web traffic once Apache is installed, click on next to Disk

Os size should be by choice for training purpose choose 30 gig to incure little or no cost

For the Disk type, you can choose between SSD and HDD.
For cost efficiency during training, select HDD, then click Next.

Networking

Select the previously created Virtual Network (VNet) and Subnet.
Allow public inbound access for required ports, then proceed to the next step.

Management

For simplicity, leave all settings at their default values.

Monitoring

Also leave the monitoring settings as default.

Advanced

Leave all advanced options unchanged.

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

Ipadeola Taiwo — Tue, 17 Mar 2026 13:26:41 +0000

What is resource group and why should you care

In Microsoft Azure, a Resource Group is a logical container used to organize and manage related resources. It is one of the first things you need to create before deploying any service in Azure.

Whether you're deploying a virtual machine, database, or web app, Resource Groups help you manage everything efficiently, control access, and reduce costs.

In this guide, you’ll learn how to create a Resource Group step-by-step using the Azure Portal.

Step 1: Log in to the Azure Portal by visiting portal.azure.com and signing in to your account.
Step 2: In the Azure Portal, use the search bar at the top and type “Resource groups,” then select it from the results.

Step 3: Click the “Create” button to start creating a new Resource Group.

Step 4: Configure your Resource Group settings. By default, your Azure subscription (e.g., “Subscription 1”) will be selected. If you have multiple subscriptions, choose the one you want to use. Next, enter a name for your Resource Group—usually the name of your project works best. Then, select a region close to where your project or users are located. Once done, click the Next button to continue.

Step 5: Add tags (optional) Tags help you organize resources so you can find them easily later. You can leave this section blank if you want. It won’t affect your Resource Group. In this tutorial, we’ll skip adding tags.

Step 6: Review and create your Resource Group After clicking Next in the previous step, you will be taken to the Review + Create page. Carefully check that all the information is correct, including your subscription, Resource Group name, and region. Once everything looks good, click Create. Congratulations—you have successfully created your Resource Group! 🎉

Step 7: Confirm your Resource Group creation After clicking Create, look at the bell icon at the top of the Azure Portal. You should see a notification saying “Resource Group created”. You can then choose to either Go to resource group to view it immediately or Pin to dashboard for quick access later.

Congratulations! You have successfully created your first Resource Group in Azure. By organizing your resources in a Resource Group, you can manage, monitor, and deploy your projects efficiently.

Next, you can start adding resources like Virtual Machines, Databases, or Storage accounts to your Resource Group and explore how Azure manages them.

Best practices

Use meaningful names for your Resource Groups to easily identify projects.
Choose regions close to your users to improve performance.
Use tags for better organization, especially if you manage many projects.

Now that you know how to create a Resource Group, you’re ready to start building and managing your cloud projects in Azure. Happy learning! 🚀

Did you find this guide helpful? 💡
I’d love to hear about your experience creating your first Resource Group in Azure!
Share your thoughts or questions in the comments below, and stay tuned for more tutorials on Azure, Cloud Computing, and DevOps.