DEV Community: Daniel

My First Terraform Workflow on Azure.

Daniel — Sat, 11 Jul 2026 14:52:26 +0000

My cloud tutor gave me a scenario for a fictional company, Hagital Cloud Solutions, with one clear goal: use Terraform to provision a Resource Group in Azure and run the complete Infrastructure as Code workflow not just apply and call it a day.

That means:
terraform init - terraform fmt - terraform validate - terraform plan terraform apply

...and then, just as importantly, terraform destroy to tear it all down cleanly.
It's a small task on the surface (one resource, one resource group), but the point wasn't the resource itself it was building the muscle memory for the workflow every Terraform engineer runs on every project, big or small.

Why the Full Workflow Matters
Before jumping into the code, here's the mental model I'm working with for each command:
init — downloads the provider plugins (in this case, azurerm) and sets up the backend. Nothing gets touched in Azure yet.

fmt — auto-formats the .tf files to a consistent style. Cheap to run, keeps code review painless.

validate — checks the syntax and internal logic of the config without talking to Azure. Catches typos and structural mistakes early.

plan — the dry run. Terraform compares your config against the real state of Azure and tells you exactly what it intends to do.

apply — actually executes that plan and creates the resources.

destroy — the reverse of apply; tears down everything Terraform is tracking in state.

The Terraform Code

main.tf

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

provider "azurerm" {
features {}
subscription_id = "Can't put my azure account's subscription id here for security reasons"
}

Resource Group

resource "azurerm_resource_group" "Terraform-RG" {
name = "Terraform-RG"
location = "westeurope"

}

I went with West Europe as the region nothing scenario-specific requiring it, just a solid, low-latency default for this exercise.

Running the Workflow
1. terraform init
Downloaded the azurerm provider and initialized the working directory.

2. terraform fmt
Formatted the file no changes needed since I kept the indentation clean from the start, but good habit to run it anyway.
3. terraform validate
Config passed validation no syntax errors.

4. terraform plan
Terraform showed exactly one resource to be added: azurerm_resource_group.hagital. This is the step I always slow down on reading the plan output line by line before typing yes anywhere.
5. terraform apply
Confirmed the plan, and got the message every Terraform engineer wants to see which is:
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
As you can see in my screensnip below...

6. Verified in the azure portal
Jumped into the Azure Portal and confirmed Terraform-rg showing up under Resource Groups state file matched reality.

7. terraform destroy
Since this was a learning exercise not something meant to stay running and accumulate costs i tore it down:

Still verified in the azure portal again:
The screenshot below confirms that the item is no longer available in the portal.

Reflection

This one ran clean end-to-end no errors, no surprises. That's partly luck and partly because the exercise is deliberately scoped small: one resource, one provider, no dependencies to trip over.

But "it worked" isn't really the takeaway I want to hold onto. What stuck with me was the discipline of the workflow fmt and validate before plan and never applying without reading the plan output first. Those are the habits that matter once the configs get bigger and the blast radius of a mistake gets larger.

Next up: I want to extend this into a small VNet + subnet setup on top of the same Resource Group, so I can start tying the networking concepts I've been studying (NSGs, subnet segmentation) into the same IaC workflow.

How I Hosted a Static Website on Azure Blob Storage with Custom DNS, Zero Servers, Under $2/Month

Daniel — Sat, 04 Jul 2026 17:24:09 +0000

Introduction

I challenged myself with a real-world Azure scenario something beyond just spinning up a VM and calling it a day. So I set myself to host a fully functional marketing website for a fictional Lagos real estate startup on Azure, with no servers, no maintenance overhead, and as little cost as possible.

Here's exactly what I built, every decision I made.

The Architecture Design Before Deployment

Before touching a single Azure resource, I mapped out the layout. This is a habit I'm building early because deploying without a clear design in mind is how you end up with resources in the wrong place and configurations you have to undo.

User types www.lagosproperties.com
│
▼
Azure DNS Zone (CNAME record)
│
▼
Storage Account — $web container
│
▼
index.html / about.html / contact.html

The key design decision here was deliberately avoiding compute. No VM means no OS to patch, no web server to configure, and no idle compute costs running 24/7. For a static marketing site, Blob Storage is the right tool — cheap, reliable, and maintenance-free.

Task 1 — Setting Up the Storage Account + Static Website

First, I created a StorageV2 storage account in the South Africa North region. because South Africa North is geographically closest to Lagos, which means lower latency for Nigerian visitors loading the site. a small detail, but the kind of thing that matters in production.

I also used Standard LRS (Locally Redundant Storage) for redundancy, Azure keeps three copies of the data within the same datacenter. For a marketing site, that's sufficient. A banking system would warrant something stronger like GRS, but over-engineering redundancy here would just drive-up cost unnecessarily.

With static website hosting enabled, Azure provisions a special $web container and assigns a public endpoint automatically. I built three HTML pages; Home, About, and Contact plus a custom 404 error page and uploaded all four to the container.

The site went live immediately at:
https://lagosproertiesstg.z1.web.core.windows.net/

Homepage

About page

Contact page

$web container showing all 4 files

Task 2 — Azure DNS Zone + CNAME Record

A storage endpoint URL works but lagosproertiesstg.z1.web.core.windows.net isn't something you'd put on a business card. I needed a proper custom domain.

So i created a public Azure DNS Zone for lagosproperties.com and configured a CNAME record pointing www.lagosproperties.com to the storage endpoint

One thing worth noting and something I learned during this project is that a CNAME record cannot sit at the root/apex of a domain (lagosproperties.com with no www). DNS standards don't allow it because the root domain must have SOA and NS records, which can't coexist with a CNAME. The www subdomain is where the CNAME lives. For the bare root domain to also work in production, an Alias record would be needed instead.

Azure automatically assigned four nameservers to the zone:

ns1-09.azure-dns.com
ns2-09.azure-dns.net
ns3-09.azure-dns.org
ns4-09.azure-dns.info

In a real deployment, I'd update these at the domain registrar to complete the delegation. But for this project, I verified the CNAME resolves correctly by querying Azure's nameservers directly using this command:

nslookup www.lagosproperties.com ns1-09.azure-dns.com

I chose to verify it this way at my own discretion, because anyone trying to load www.lagosproperties.com in a browser right now wouldn't see it yet without the registrar delegation. Querying the nameserver directly proves the Azure side of the configuration works perfectly!

Task 3 — Blob Versioning + Rollback

This is the part I found most valuable from a real-world perspective. Enabling blob versioning on the storage account means every time a file is overwritten, Azure silently keeps the previous version in the background automatically, with no extra configuration.

Why does this matter? Because mistakes happen. A content update with a typo, a broken layout, an accidental overwrite these are inevitable. "Being careful" doesn't scale as a strategy. Versioning is what gives you a fast recovery path when something goes wrong, regardless of why it went wrong.

To demonstrate this, I:

Uploaded the original homepage — Version 1
Edited the heading and re-uploaded the same file — Version 2 (now live)
Confirmed both versions existed in Azure with different timestamps.
Rolled back by restoring Version 1 as the current live blob.
Refreshed the live site original content restored instantly.

Data Protection page showing versioning enabled

live site — Version 1 (original heading)

live site — Version 2 (updated heading)

Versions of the two timestamps in the azure portal

live site after rollback — Version 1 restored

Task 4 — What Does This Actually Cost?

One thing I always want to understand when building on Azure is what I'm actually paying for and why. So I ran the numbers through the Azure Pricing Calculator based on realistic assumptions for a small real estate site:
Assumption Value
─────────────────────────────────────────────────
Expected visitors/month ~5,000
Average pages viewed per visit 3
Total read operations/month ~10,000
Write operations/month ~1,000
Data retrieval/month ~100 MB
DNS zone 1
DNS queries/month ~10,000

Estimated monthly total: $1.14

That's the entire hosting cost for a production-ready marketing website DNS included. No compute, no idle server running overnight, no maintenance window. This is the core value proposition of serverless static hosting, and running these numbers myself made it genuinely concrete rather than just a talking point.

Below are images showing the Storage + DNS line items breakdown

Conclusion

What started as a simple "host a static site" challenge turned into a genuinely useful exercise in thinking through architecture, cost, DNS, and data resilience together not as separate topics, but as one connected system. The result is a serverless, sub-$2/month website that a real Lagos startup could deploy from day one with confidence.

How i Created a Linux VM, SSHed Into it and Installed Apache2 on Azure

Daniel — Mon, 27 Apr 2026 11:10:32 +0000

Introduction

In this project, I created a Linux virtual machine on Microsoft Azure, connected to it securely using SSH, and installed Apache2 to host a web server.

This is part of my journey as an aspiring cloud engineer, learning cloud technologies, Linux, and DevOps.

Step 1: Creating a Virtual Machine on Azure

I logged into the Azure Portal and created a new virtual machine using Ubuntu as the operating system.

Key configurations included:

Resource group creation
Selecting a region
Choosing a VM size
Setting up authentication (SSH key)

Step 2: Connecting to the VM via SSH

After the VM was successfully created, I connected to it using SSh [Secure shell hosting] from my Gitbash terminal.

Command used:
ssh username@public-ip-address

Once connected, I had full access to the Linux environment running on virtual machine as shown below

Step 3: Updating the System

Before installing any software, I updated and upgraded the package list with the commands;

sudo apt update
&
sudo apt ugrade

This ensures that all packages are up to date and upgraded.

Step 4: Installing Apache2

Next, I installed Apache2 using the following command:

sudo apt install apache2 -y
The -y flag automatically confirms installation prompts.

After installation, Apache2 started running on the server.

Step 5: Verifying Apache2 Installation

To confirm Apache2 was working, I opened a browser and visited my VM’s public IP address.

The default Apache2 welcome page was displayed, confirming a successful installation.

Conclusion

In this project, I successfully:

Created a Linux virtual machine on Azure
Connected to it using SSH
Installed and ran Apache2

This project strengthened my understanding of cloud computing, remote server management, and basic web server deployment.

I look forward to building more projects as I continue my journey in cloud engineering.