DEV Community: David Cletus

Inside Azure Networking: How I Created a Virtual Network with Custom Subnets

David Cletus — Thu, 04 Jun 2026 23:54:09 +0000

If you've ever stared at the Azure portal wondering where to even begin with networking, you're not alone. I was right there a few weeks ago. In this post, I'm walking you through exactly what I did — from creating a resource group to building a virtual network with three custom subnets. No fluff, just real steps with real screenshots.
Let's get into it.

Head over to portal.azure.com
Once logged in,

Step 1 — Search for Resource Groups

The first thing you want to do is head to the Azure portal and use the search bar at the top to look up "resource group". You'll see it pop up under Services — click on Resource groups.

💡 Quick note: I covered resource group creation in a previous blog too, but I'm including the steps here again so this post is fully self-contained. No jumping around needed.

Step 2 — Create a New Resource Group

Once you're on the Resource Groups page, you'll see a list of any existing groups or an empty list with a create button visible on the page. To create a new one, click the + Create button at the top left.

Step 3 — Fill in the Resource Group Details

On the creation form, you need to fill in three things:

Subscription — select your active subscription (mine is Azure subscription 1)
Resource group name — I named mine Netaccess
Region — I chose (Africa) South Africa North since that's closest to me

Once filled in, click Review + create.

Step 4 — Review and Create the Resource Group

You'll be taken to a summary screen. Confirm the details look right — subscription, name, and region. Then hit the Create button at the bottom.

Step 5 — Resource Group Created!

Once Azure finishes provisioning (it's pretty fast — usually a few seconds), you'll see a notification on the right confirming that the resource group was created successfully. Your new Netaccess group will now appear in the list.

Step 6 — Search for Virtual Networks

Now that our resource group is ready, it's time to create a Virtual Network inside it. Use the top search bar again and type "virtual networks". Click on Virtual networks from the Services dropdown.

Step 7 — Create a Virtual Network

You'll land on the Virtual Networks overview page. Since we don't have any yet, it'll say "No virtual networks to display." Click the + Create button (either at the top or the one in the centre of the page).

Step 8 — Fill in the Virtual Network Basics

On the Basics tab of the creation wizard, configure the following:

Subscription — Azure subscription 1
Resource group — Select the Netaccess group we just created
Virtual network name — I named it Netaccess-VM
Region — (Africa) South Africa North

Then click Next to move to the next tab.

Step 9 — Configure Address Space and Delete the Default Subnet

Skip past the Security tab (leave everything as default) and head to the Address space tab. Here Azure has already set up a default address space of 10.0.0.0/16 — that gives us 65,536 IP addresses, which is way more than enough.
Now here's the important part: Azure also pre-creates a default subnet with the range 10.0.0.0 - 10.0.0.255 (/24). We're going to delete this because we want to create our own subnets with custom names and IP ranges.
Click the trash/delete icon on the right side of the default subnet row to remove it.

Why delete the default subnet? Because accepting defaults means Azure names and organises things on your behalf. When you create your own subnets from scratch, you control the naming convention, IP ranges, and how traffic is logically segmented. Clean slate = cleaner architecture.

Step 10 — Review and Create the Virtual Network

Click through to the Review + create tab. You'll see a green "Validation passed" banner at the top — Azure confirming everything looks good. Take a moment to review the summary:

Subscription: Azure subscription 1 ✅
Resource Group: Netaccess ✅
Name: Netaccess-VM ✅
Region: South Africa North ✅
Security (Bastion, Firewall, DDoS): all Disabled ✅

Hit the Create button at the bottom.

Step 11 — Deployment Complete — Click "Go to Resource"

Azure will now provision your virtual network. It usually takes just a minute or less. Once done, you'll land on the deployment overview showing "Your deployment is complete" with a green checkmark.
Click Go to resource to open your newly created Netaccess-VM virtual network.

Step 12 — Explore the VNet Overview and Navigate to Subnets

You're now inside the Netaccess-VM virtual network overview page. You can see all the essentials — resource group, location, address space (10.0.0.0/16), and notice it currently shows 0 subnets (because we deleted the default one earlier).
In the left sidebar under Settings, click on Subnets. This is where we'll build all three of our custom subnets.

Step 13 — Click "+ Subnet" to Start Adding Subnets

Once you're on the Subnets page, you'll see "No items found" — exactly as expected. Click the + Subnet button at the top of the page to open the "Add a subnet" panel on the right side.

Step 14 — Add Subnet 1 (Netaccess-subnet1)

The "Add a subnet" panel slides in from the right. Fill in the following:

Subnet purpose — Default
Name — Netaccess-subnet1
IPv4 address range — 10.0.0.0/16 (this is auto-populated from your VNet address space)
Starting address — 10.0.0.0
Size — /24 (256 addresses)

This creates a subnet range of 10.0.0.0 - 10.0.0.255. Leave IPv6 unchecked and scroll down to click Add.

Step 15 — Add Subnet 2 (Netaccess-subnet2)

Click + Subnet again to add the second subnet. You'll notice the panel now shows the existing subnet1 listed on the left — that's just confirmation it was saved. Fill in the new details:

Name — Netaccess-subnet2
Starting address — 10.0.1.0
Size — /24 (256 addresses)

Subnet range: 10.0.1.0 - 10.0.1.255. Click Save.

Notice how we moved the third octet from .0.0 to .1.0 for the second subnet — that's how we keep each subnet in its own separate IP block within the same /16 space. No overlap, no conflict, no headaches so we do the same to create Netaccess-subnet3.

Step 16 — All Three Subnets Created Successfully

Repeat the same process one final time for the third subnet:

Name — Netaccess-subnet3
Starting address — 10.0.2.0
Size — /24

After saving, your Subnets page will now show all three subnets neatly listed with their IPv4 ranges highlighted:
NameIPv4 RangeAvailable IPsNetaccess-subnet110.0.0.0/24251Netaccess-subnet210.0.1.0/24251Netaccess-subnet310.0.2.0/24251

Each subnet has 251 usable IP addresses — When a resource is created, it uses one IP address from its subnet, and that IP is no longer available in the virtual network's address range. However, IP usage is managed at the subnet level, so a subnet can run out of addresses while the virtual network still has many unused IPs available in other subnets.

Cleanup — Deleting the Resources

Once I was done with the lab, I cleaned everything up to avoid unnecessary charges. Here's how:
Delete the Netaccess Resource Group
Go back to Resource groups, select Netaccess, click Delete resource group, type the name to confirm, and hit Delete.

Delete the NetworkWatcherRG

Azure automatically creates a NetworkWatcherRG resource group when you deploy networking resources. Delete this one too — same process: select it, click Delete resource group, type the name, confirm.

All Resource Groups Deleted

Once both are gone, your resource groups list is clean again — back to just the ones you had before (in my case, only Je-mega-soft remains).

Summary

Here's the full recap of what we did:

✅ Searched for and opened Resource Groups
✅ Created the Netaccess resource group in South Africa North
✅ Searched for and navigated to Virtual Networks
✅ Filled in VNet Basics — name Netaccess-VM, resource group Netaccess
✅ On the Address space tab, deleted the auto-generated default subnet
✅ Reviewed and created the Virtual Network (validation passed)
✅ Deployment completed — clicked Go to resource
✅ Navigated to the Subnets section inside the VNet
✅ Clicked + Subnet to start adding custom subnets
✅ Created Netaccess-subnet1 → 10.0.0.0/24
✅ Created Netaccess-subnet2 → 10.0.1.0/24
✅ Created Netaccess-subnet3 → 10.0.2.0/24
✅ Cleaned up both Netaccess and NetworkWatcherRG resource groups

Why This Matters
Understanding how to manually structure your subnets gives you real control over how traffic flows in your cloud environment. Instead of accepting defaults, you're deliberately choosing IP ranges — which becomes crucial when you start doing things like:

Separating frontend and backend application tiers
Connecting on-premises networks via VPN Gateway or ExpressRoute
Setting up Network Security Groups (NSGs) with rules per subnet
Deploying services that require dedicated subnets (like Azure Bastion or App Gateway)

This is foundational Azure networking.

If this helped you, drop a ❤️ or leave a comment — especially if you ran into something different in your own setup. I'd love to hear about it.
Until next time — keep building! 🚀

How I Hosted a Free Website on Azure Blob Storage (No Server Needed!)

David Cletus — Wed, 03 Jun 2026 07:33:07 +0000

Introduction

So I wanted to host a website without paying for a web server or dealing with complex configurations. Turns out, Azure Blob Storage has a brilliant feature called Static Website Hosting that lets you serve HTML, CSS, and JavaScript files directly from a storage container — kind of like having a mini web host built into your cloud storage.
In this post, I'll walk you through exactly what I did, step by step, with screenshots. The website template I used is called Nexus Brew — a cyberpunk-themed cafe website from Tooplate.com, which offers free HTML templates.
By the end of this guide, your site will be live at a URL like this:

https://jewebs.blob.core.windows.net/$web/index.html

Let's get into it!

Step 1 — Download the Nexus Brew Template from Tooplate
Before jumping into Azure, the first thing I did was grab the website template.
I went to tooplate.com — a site that offers clean, modern, free HTML templates built with Bootstrap and CSS. They have over 80 templates for startups, small businesses, and portfolios.

I searched for and found the Nexus Brew template.

It's a dark, cyberpunk-style cafe website template with features like:

A hero banner section
A tabbed menu showcase
An about section with content and images
A contact form
Social media links
Smooth scroll navigation and hover effects

It looks super cool — very futuristic and modern. Perfect for learning!
I clicked the Download button on the template page to grab the zip file.

The downloaded file was named 2146_nexus_brew.zip and it landed in my Downloads folder.

Step 2 — Extract the Zip File
After downloading,

I extracted the zip file. Inside the 2146_nexus_brew folder, you'll find these files:

index.html — the main HTML page
tooplate-nexus-brew.css — the stylesheet
tooplate-nexus-scripts.js — the JavaScript file
ABOUT THIS TEMPLATE.txt — info about the template
images/ — a folder containing all the images used on the site

These are all the files I'll need to upload to Azure later.

Step 3 — Find Resource Groups in the Azure Portal
Now it's time to head over to portal.azure.com.
Once logged in,

I used the search bar at the top and typed "resource group". In the dropdown that appeared, I clicked on Resource groups (the one listed under Services).

What is a Resource Group?
Think of a Resource Group as a folder in Azure where you keep related things together. It helps you manage, organize, and delete resources (like storage accounts) as a unit.

Step 4 — View the Existing Resource Group Created in the Last Blog

After clicking Resource groups, I could see my existing resource group named Je-mega-soft which was created in our last blog, located in South Africa North under Azure subscription 1.
I clicked on it to open it.

Step 5 — Search for Storage Accounts
Inside the Resource Manager section, I used the search bar again and typed "storage account". From the suggestions, I clicked on Storage accounts (the one listed under Services — not the classic version).

This took me to the Storage center where I could see existing storage accounts and create new ones.

Step 6 — Create a New Storage Account
On the Storage center page, I clicked the + Create button at the top to start creating a new storage account.

On the Basics tab of the creation form, I filled in these details:

Resource group: Je-mega-soft (selected from the dropdown)
Storage account name: jewebs (this has to be globally unique — all lowercase, no special characters)
Region: (Africa) South Africa North (I chose the region closest to me)
Preferred storage type: Azure Blob Storage or Azure Data Lake Storage
Performance: Standard (recommended for most use cases)
Redundancy: Locally Redundant Storage (LRS) (the most affordable option — stores 3 copies of your data within one data center)

Why LRS? For a static website that's just for learning or low-traffic use, LRS is more than enough and the cheapest option.

Step 7 — Enable Anonymous Access in the Security Tab
After filling in the Basics, I clicked Next to navigate through the tabs until I reached the Security tab.
Here, the most important setting to enable is:
✅ Allow enabling anonymous access on individual containers
I made sure this checkbox was ticked.

The red arrow in my screenshot points directly to this option — don't miss it!

Why is this important? Without enabling anonymous access, your static website files would be private by default. No one on the internet would be able to open your website. Enabling this allows the $web container (which Azure creates for static websites) to serve files publicly.

Once done, I clicked Review + create, reviewed the settings, and clicked Create.

Step 8 — Deployment Complete! Go to Resource
After a few seconds, the deployment finished and I saw the "Your deployment is complete" message.
The notification bell at the top right also showed a green checkmark saying "Deployment succeeded" — the deployment was to resource group Je-mega-soft.

I clicked the Go to resource button (there's one in the main panel and one in the notification panel — either works) to open the newly created storage account.

Step 9 — Navigate to Static Website Settings
Now I was inside the jewebs storage account dashboard.
On the left sidebar, I scrolled down and expanded the Data management section. Inside it, I clicked on Static website.

If you don't see Data management, look for it in the left panel — it's usually collapsed. The red arrow in my screenshot points directly to it.

Step 10 — Enable the Static Website Feature
On the Static website page, by default the feature is set to Disabled.
I clicked on Enabled to turn it on.

As soon as I enabled it, two input fields appeared:

Index document name: nexus_brew.html
Error document path: ERROR-404.html

This is the page that shows when someone visits a URL that doesn't exist. You can create a simple 404 page or just use the default.

After filling these in, I clicked Save.

Step 11 — Settings Saved Successfully
A green notification appeared in the top right corner saying "Successfully updated static website settings".
On the same page, I could now see:

The static website is Enabled
A message saying: "An Azure Storage container has been created to host your static website."
A link to the container: $web
The Primary endpoint URL: https://jewebs.z1.web.core.windows.net/

What is $web? This is a special Azure container that's automatically created when you enable static website hosting. It's where you'll upload all your website files.

I clicked on $web to open that container.

Step 12 — Upload Files to the $web Container
Inside the $web container, it was empty — showing "No items found".
I clicked the Upload button at the top to open the Upload blob panel on the right side.

I then selected all the files from the extracted Nexus Brew folder:

index.html
tooplate-nexus-brew.css
tooplate-nexus-scripts.js
ABOUT THIS TEMPLATE.txt
The images folder

The upload panel showed "7 file(s) selected" (the images folder contains multiple image files, so the total count goes up).

I clicked the Upload button in the panel to start the upload.

Important tip: Make sure to upload the contents of the folder, not the folder itself. Azure Blob Storage needs the files at the root level of $web for the static website to work correctly. If you upload a folder as a subfolder, your index page won't load properly.

Step 13 — Files Successfully Uploaded
After the upload completed, the $web container now showed all my files:
NameTypeSizeimagesFolder—ABOUT THIS TEMPLATE.txtBlock blob557 Bindex.htmlBlock blob16.8 KiBtooplate-nexus-brew.cssBlock blob24.78 KiBtooplate-nexus-scripts.jsBlock blob3.52 KiB
All 5 items were now visible and available in the container — uploaded on 6/2/2026 at 10:38 PM.

Step 14 — Copy the URL of the Index File
To get the direct URL of the uploaded index.html file, I:

Clicked the three-dot menu (...) next to index.html
Selected Copy URL from the context menu

The URL I got was:
https://jewebs.blob.core.windows.net/$web/index.html

Note: There are actually two URLs you can use:

Blob URL (direct file): https://jewebs.blob.core.windows.net/$web/index.html

Static website URL (cleaner): https://jewebs.z1.web.core.windows.net/

The Website Is Live! 🎉

That's it! The Nexus Brew template is now hosted live on Azure Blob Storage as a static website.
You can visit it at:
👉 https://jewebs.blob.core.windows.net/$web/index.html

           Quick Summary of All Steps

Here's a quick recap of everything we did:

Downloaded the Nexus Brew free HTML template from tooplate.com
Extracted the zip file and noted the files inside
Open the Azure Portal and search for Resource groups in the Azure portal
Opened the existing Je-mega-soft resource group which was previously showed on our last blog how to create.
Searched for Storage accounts and clicked Create
Configured the storage account with name jewebs, region South Africa North, Standard performance, and LRS redundancy
In the Security tab, enabled Allow anonymous access on containers
Deployed and clicked Go to resource
Navigated to Data management → Static website
Enabled static website hosting and set the index document name
Saved settings and noted the $web container and primary endpoint URL
Opened the $web container and uploaded all website files
Confirmed all files were uploaded successfully
Copied the URL and opened the live websit e

Why I Loved This Approach

Honestly, this whole setup took less than 15 minutes and didn't require me to set up a web server, configure Nginx or Apache, deal with SSL certificates manually, or pay for a VM. Azure handles everything for you and even gives you HTTPS for free through the static website endpoint.
For simple websites — portfolios, landing pages, documentation sites, or just practice — this is one of the easiest and cheapest ways to get something live on the internet.

Resources Used:

Tooplate.com — Free HTML templates
Azure Static Website Hosting Docs
Azure Account.

Step-by-Step Guide to Azure Blob Storage: Uploading Files, Enabling Public Access, and Secure SAS Link Generation

David Cletus — Thu, 28 May 2026 22:09:47 +0000

In this article, I will walk through how I created an Azure Storage account, configured Blob Storage, uploaded a file, made it publicly accessible, and finally generated a Shared Access Signature (SAS) link for secure access.

This is part of my hands-on learning journey in Cloud Computing and DevOps using Microsoft Azure.

Creating the Azure Storage Account

The first step was to create a Storage Account in Microsoft Azure. This is the core service that provides a scalable location for storing files such as images, videos, documents, and backups.

Configuration used:
Resource Group: je-mega-soft
Storage Account Name: prodjemegastorage1
Region: Africa (South Africa North)
Primary Service: Azure Blob Storage
Performance: Standard
Redundancy: Locally Redundant Storage (LRS)
Access Tier: Hot
Allow Blob Public Access: Enabled (on container level)
Explanation of each choice:

Resource Group (je-mega-soft):
A resource group is simply a logical container in Azure that holds related resources. I used this to group everything related to my project for easy management and cleanup.

Storage Account Name (prodjemegastorage1):
This must be globally unique across Azure. I used a structured name to represent a production-style storage setup.

Region (Africa – South Africa North):
I selected this region because it is geographically closer to my location, which reduces latency and improves performance when accessing resources.

Primary Service (Blob Storage):
Blob Storage is designed for storing unstructured data like images, videos, logs, and backups. It is the best choice for this type of project.

Performance (Standard):
Standard performance was chosen because this is a learning/demo project. It is cost-effective and suitable for general-purpose storage. Premium would only be needed for high-speed enterprise workloads.

Redundancy (Locally Redundant Storage - LRS):
LRS stores data in a single data center but keeps multiple copies within that facility. I chose this because it is the cheapest option and perfect for testing and learning purposes.

Access Tier (Hot):
The Hot tier is used for data that is accessed frequently. Since I planned to upload and access the file during testing and sharing, this was the best fit.

Public Access Enabled:
I enabled public access at the container level because I wanted the uploaded file to be accessible via a URL without authentication.

After reviewing all settings, I clicked Create and waited for deployment to complete.

Creating a Blob Container

After the storage account was successfully created, I moved to the next step which is creating a container.

Path:
Storage Account → Data Storage → Containers → + Add Container

Container configuration:
Name: jemega-img-vid
Public Access Level: Container (anonymous read access for containers and blobs)
Why I used this container name:

I chose jemega-img-vid because:

“jemega” represents my personal/project brand name
“img-vid” clearly indicates the container is meant for images and videos
It is short, readable, and meaningful for future scaling
Public Access Level explanation:

Setting the access level to Container means:

Files inside the container can be publicly accessed
Anyone with the link can view blobs without authentication
This is useful for demos, static file hosting, and learning scenarios
About the $logs container:

During setup, Azure automatically created a container called $logs.

This container is used for system-generated logs such as:

Storage analytics logs
Request tracking logs
Diagnostic monitoring data

It is not meant for user files, so I did not modify or use it.

Uploading the File to Blob Storage

Next, I uploaded a file into the container.

File uploaded:
just me.png

Steps:

Opened the container (jemega-img-vid)
Clicked on Upload
Selected the file from my local system
Clicked Upload to store it in Azure Blob Storage

Once uploaded, Azure automatically generated a unique URL for the file.

Blob URL generated:

https://prodjemegastorage1.blob.core.windows.net/jemega-img-vid/just%20me.png

Explanation:

This URL directly points to the file inside the container. Because public access was enabled, the file can be accessed in a browser without authentication.

Generating a Shared Access Signature (SAS)

To improve security while still allowing temporary access, I generated a Shared Access Signature (SAS).

What is SAS?

A SAS token is a secure way to grant limited access to storage resources without exposing your account keys. It allows you to define:

What can be accessed
How long access is valid
What permissions are allowed
Why I used Key 1:

I used Key 1 from the storage account because it is one of the primary access keys used to generate SAS tokens. These keys should be protected because they grant full control over the storage account.

SAS configuration used:
Start Time: Today at 10:30 PM
Expiry Time: 31st of this month at 12:03 PM
Permissions: Read (sp=r)
Protocol: HTTPS only

Why SAS is important:

SAS provides:

Temporary access instead of permanent public exposure
Better security control over shared files
Ability to revoke access by changing keys or expiry
Fine-grained permissions (read, write, delete, etc.)

*Final SAS URL (Secure Access Link)
*
Here is the final link generated using SAS:

https://prodjemegastorage1.blob.core.windows.net/jemega-img-vid/just%20me.png?sp=r&st=2026-05-28T21:12:08Z&se=2026-05-31T11:03:08Z&spr=https&sv=2026-02-06&sr=b&sig=SseErml92AKi5t60kVuYCN8DNP%2BBkKm4CaXtHwhTqwo%3D

Conclusion

This walkthrough helped me understand the basics of Azure Blob Storage, from creating a storage account and container to uploading a file and generating a SAS link for controlled access. I also learned how key settings like redundancy, access tier, and public access affect cost, performance, and security. Overall, it made cloud storage concepts clearer and gave me a solid foundation for working with Azure storage services going forward.

I Created an Azure User, Gave It Global Admin Access, Revoked It, and Tested Azure IAM — Here’s What I Learned

David Cletus — Fri, 22 May 2026 01:20:29 +0000

As part of my Cloud Engineering and DevOps learning journey, I recently decided to go beyond theory and start practicing Identity and Access Management (IAM) directly inside Microsoft Azure.

I wanted to understand how organizations manage users, permissions, administrative access, and security in real cloud environments. Instead of just reading about Microsoft Entra ID and RBAC, I performed a complete hands-on lab from start to finish.

In this lab, I:

created a new Azure user
configured Microsoft Authenticator
assigned administrative roles
logged into the new account using an incognito browser
created another user using delegated access
revoked the permissions
tested whether the account could still perform administrative actions

This exercise gave me a much deeper understanding of how cloud identity management works in enterprise environments.

The screenshots attached throughout this post document the entire process step by step.

Starting From the Default Directory

I began by logging into the Azure Portal using my main administrator account inside the default directory.

From there, I navigated to:

Microsoft Entra ID → Users → All Users

This section contains every identity managed inside the Azure environment, including:

users
groups
applications
permissions

At this point, I already had administrative privileges, which allowed me to create and manage other users.

One thing I’m beginning to understand about cloud platforms is that structure and organization are extremely important. Without proper identity management, large organizations would struggle to control access securely.

Creating the “Immortel” User

The next step was creating a new user account named “Immortel.”

During the setup process, I configured:

display name
username
password settings
account information

After creating the account successfully, the new user appeared immediately inside the Azure users list.

This helped me understand how organizations onboard employees into Microsoft Entra ID environments.

At this stage, the account existed but had limited permissions.

Logging Into the Immortel Account Using Incognito Mode

Instead of signing out from my main administrator account, I opened a new incognito browser window and logged into the Immortel account separately.

This allowed me to:

remain logged into my administrator account
test the Immortel account independently
simulate how multiple administrators may work simultaneously

Using incognito mode was actually very useful because it helped me manage both accounts side by side without interrupting my existing Azure session.

At this stage, the Immortel account still had very limited access because no elevated administrative roles had been assigned yet.

This demonstrated an important cloud security principle known as:

Least Privilege Access

This means users should only receive the minimum permissions necessary for their tasks.

Setting Up Microsoft Authenticator (MFA)

While logging into the Immortel account, Azure required Multi-Factor Authentication (MFA) setup using Microsoft Authenticator.

This process involved:

scanning a QR code
linking the account to the Authenticator app
approving sign-in requests

This was one of the most practical parts of the exercise because it showed me how organizations secure user accounts beyond just passwords.

I now understand why MFA is considered one of the most important security practices in cloud computing. Even if a password gets compromised, unauthorized users still cannot access the account without the additional verification step.

Assigning Global Administrator and Global Reader Roles

After setting up the Immortel account successfully, I returned to my original administrator session inside the default directory and assigned two important roles:

Global Administrator
Global Reader

This introduced me to Azure Role-Based Access Control (RBAC).

Before this exercise, RBAC sounded theoretical while reading documentation. But seeing it work practically made everything much clearer.

Understanding the Global Administrator Role

Global Administrator is one of the highest privileged roles inside Microsoft Entra ID.

A user with this role can:

create and manage users
assign permissions
manage identity settings
configure security
reset passwords
control administrative settings

In simple terms, this role has broad control over the Azure identity environment.

Understanding the Global Reader Role

Global Reader works differently.

Users with this role can:

view configurations
monitor environments
review settings

but they cannot make administrative changes.

This role is useful for:

auditors
compliance teams
monitoring personnel

who need visibility without modification access.

Logging Back Into the Immortel Session

After assigning the roles, I refreshed and continued working inside the incognito browser session already logged into the Immortel account.

The difference was immediately noticeable.

The account now had elevated privileges and could access administrative capabilities that were unavailable earlier.

This demonstrated how permissions in Azure are controlled dynamically through assigned roles.

It also showed me how powerful RBAC is in enterprise cloud environments.

Creating Another User Named “Dare”

To confirm the permissions were working correctly, I used the Immortel account to create another user named “Dare.”

The creation process was successful.

This confirmed that the Global Administrator privileges assigned earlier were active and functioning properly.

At this point, I fully understood how delegated administration works in Azure environments.

Organizations can temporarily assign elevated permissions to specific users without permanently granting full administrative control to everyone.

Revoking the Administrative Access

After completing the delegated administration test, I returned to my original administrator session inside the default directory.

I then removed:

Global Administrator access
Global Reader access

from the Immortel account.

This part of the exercise taught me another important IAM concept:

Permissions can be granted and revoked at any time.

This is critical in real-world environments for situations such as:

employee resignation
temporary contractors
security incidents
role changes
access reviews

Testing the Revoked Account

To confirm the permissions were truly removed, I returned to the incognito browser session using the Immortel account and attempted to create another user named “John.”

This time, the operation failed.

The account no longer had sufficient privileges to perform administrative tasks.

This final test clearly demonstrated how Azure immediately enforces permission changes once access is revoked.

It was satisfying seeing the entire IAM workflow function exactly as expected.

What This Lab Taught Me

This hands-on exercise helped me better understand:

Microsoft Entra ID
Identity and Access Management (IAM)
RBAC
Multi-Factor Authentication (MFA)
delegated administration
access control
permission revocation
cloud security principles

More importantly, it helped me realize that identity management is one of the most critical aspects of cloud security.

Without proper IAM controls:

unauthorized access becomes easier
security risks increase
governance becomes difficult
compliance becomes harder to maintain

Final Thoughts

This was one of the most valuable Azure labs I’ve completed so far because it moved beyond theory into practical identity administration and security management.

As I continue learning Cloud Engineering and DevOps, I’m beginning to appreciate how important hands-on practice is. Reading documentation is useful, but actually performing these tasks inside a real cloud environment creates a completely different level of understanding.

I still have a long way to go, but each lab continues to build my confidence and understanding step by step.

I’ll continue documenting my learning journey, projects, and hands-on experiences as I grow in cloud engineering and DevOps.

[Boost]

David Cletus — Thu, 14 May 2026 20:23:27 +0000

David Cletus

May 14

Creating My First Azure Resource Group as I Begin My Journey Into Cloud Engineering and DevOps

#azure #beginners #cloud #devops

2 min read

Creating My First Azure Resource Group as I Begin My Journey Into Cloud Engineering and DevOps

David Cletus — Thu, 14 May 2026 20:18:29 +0000

Today I took another practical step in my Cloud Engineering and DevOps learning journey by creating my first Resource Group on Microsoft Azure.

As someone currently learning cloud computing and DevOps from scratch, this may seem like a small task, but it actually helped me understand how cloud infrastructure is organized in real-world environments.

In the screenshot above, I was working inside the Azure Portal while creating a Resource Group called “Hagital-Resource-Group” and selecting the “South Africa North” region.

This simple setup exposed me to important cloud concepts such as subscriptions, regions, resource organization, and infrastructure management.

What is a Resource Group?

A Resource Group in Azure acts like a container that holds related cloud resources together.

For example, a company can keep:

virtual machines
databases
storage accounts
applications
virtual networks

inside one Resource Group instead of managing them separately.

This makes resources easier to organize, monitor, secure, and manage.

A simple way to think about it is like creating a folder on your computer for a particular project where all related files are stored together.

What I Learned During This Setup

While creating this Resource Group, I learned a few important things about how cloud platforms work.

Subscriptions

Azure uses subscriptions to manage billing and cloud services. Every resource created inside Azure belongs to a subscription.

Regions

Cloud providers do not keep all their infrastructure in one location. They build data centers across different countries and locations around the world called regions.

I selected the “South Africa North” region because it is geographically closer to Africa and can help improve performance and reduce latency for users in this region.

Resource Organization

I also learned how organizations group cloud resources based on projects, departments, or applications. This becomes very important in large environments where thousands of resources may exist.

Why I Started Learning Cloud Engineering and DevOps

Technology is moving heavily toward cloud infrastructure and automation. Many organizations now rely on cloud providers like Microsoft Azure, AWS, and Google Cloud to run their systems and applications.

I decided to start learning cloud engineering and DevOps because I want to understand modern infrastructure, automation, and how scalable systems are built and managed.

Right now, I’m learning:

cloud fundamentals
Microsoft Azure
Linux
networking
DevOps concepts
virtual machines
resource management

I also plan to learn tools like Docker, Git, Kubernetes, Terraform, and CI/CD pipelines as I continue growing in this field.

What I Learned Today

Some of the key things I learned from this exercise include:

how Azure Resource Groups work
how subscriptions are used in Azure
the importance of regions in cloud computing
how cloud infrastructure is organized globally
the value of hands-on practice while learning technology
Final Thoughts

This is still the beginning of my journey, but I’ve realized that small practical steps are important when learning cloud technologies.

I plan to continue documenting my progress, sharing what I learn, and building projects along the way.

There is still a lot to learn, but I’m excited about the process and looking forward to improving consistently over time.

cloudcomputing #azure #devops #cloudengineering #learninginpublic