DEV Community: Emmanuel

Azure Management Task: Clean Up Everything (Part 5)

Emmanuel — Sat, 27 Jun 2026 13:28:59 +0000

We have built, configured, secured, and tagged a complete Azure environment over the past four posts. Now it's time to tear it all down, and doing this properly is just as much an admin skill as building it up.

Step 1: Remove the Delete Lock

Remember the Delete lock we added to guided-project-vm in Part 4? It will block deletion if we do not remove it first. Locks have to go before resources do.

Step 1: Log in to Microsoft Azure
In the Azure portal, search for Virtual machines and
Step 2: Select guided-project-vm. Under Settings,
Step 3: Select Locks. On the VM-delete-lock row,
Step 4: click Delete,
Step 5: Then confirm.

Step 2: Delete the Project Resource Group

Here is where resource groups really earn their keep. Instead of deleting each resource individually, deleting the resource group wipes everything inside it at once: the VM, VNet, NSG, storage account, all of it.

Search for Resource groups.
Step 1: Select guided-project-rg.
Step 2: Click Delete resource group.
Step 3: Check Apply force delete - to handle any running resources like the VM. Step 4: Type guided-project-rg in the confirmation box, and next Step click Delete. Step 5: Then confirm.

Deletion takes around 5 minutes. Refresh the resource groups list periodically until guided-project-rg disappears.

Step 3: Delete NetworkWatcherRG (If Applicable)

Azure may have automatically created a NetworkWatcherRG resource group when you provisioned the VNet. Whether you need to delete it depends on whether it existed before you started this series.

If NetworkWatcherRG existed before you started, you can leave it alone. It belongs to something else.
If it was created during this project, delete it now using the same process as above: open the resource group, click Delete resource group, type NetworkWatcherRG to confirm, and delete.

A clean subscription, no lingering costs, and a complete end-to-end Azure project under your belt.

Over this series, you provisioned a full Azure environment from scratch, secured a virtual network with subnets and NSGs, managed a virtual machine and storage account, applied tags for visibility, protected critical resources with locks, and cleaned everything up properly. That is the full lifecycle of Azure resource management.

Kindly share and leave your comments.

Mastering Azure Management, Part 4: Organizing with Tags and Protecting with Locks

Emmanuel — Fri, 26 Jun 2026 18:59:30 +0000

Over the past three posts, we created the foundational infrastructure, segmented the virtual network with a dedicated FTP subnet, secured it with a Network Security Group, and worked with our virtual machine and storage account.

We are going to add tags to our resources so the team can track what is what, and we will apply a resource lock to our VM to avoid accidental deletion.

This post wraps up the series. Ensure you have the guided-project-vm virtual machine and guided-project-vnet virtual network from the previous exercises already in place.

What Are Tags?

Tags are simple key-value pairs you attach to Azure resources. A tag might look like Department: Customer Service or Purpose: FTP Server. They do not affect how a resource behaves; they just add metadata that makes filtering, reporting, and cost tracking easier.

Imagine this: Your finance team asks for a cost breakdown by department, and you have no way to filter spending. Or worse, someone accidentally deletes the production VM during a routine cleanup. Both scenarios are nightmares. Tags and resource locks exist to prevent exactly these disasters, and they take about 5 minutes to set up.

What Are Resource Locks?

A resource lock is exactly what it sounds like: a safeguard that prevents a resource from being modified or deleted, even by users who have permission to do so. Azure offers two lock types:

Delete — prevents deletion, but allows modifications.
ReadOnly — prevents both deletion and modifications.

Locks are especially useful for critical infrastructure. If a VM is running a production workload, a Delete lock means no one — including an admin having a bad day can remove it without first explicitly removing the lock. It is a simple but powerful safety net.

Task 1: Add Tags and a Lock to the Virtual Machine

We will start with the VM, since it needs both tags and a lock. It is efficient to handle both. Add Tags to the VM

Step 1: Log in to the Azure portal.
Step 2: In the search bar, type Virtual machines and select it under Services.
Step 3: Select guided-project-vm from the list.
Step 4: In the left-hand menu, select Tags.

On the first row, enter Department for Name and Customer Service for Value. On the second row, enter Purpose for Name and FTP Server for Value. Click Apply.

The VM is now tagged. Anyone browsing resources across the subscription can immediately see what this machine does and who it serves.

Add a Delete Lock to the VM

While we are still in the VM blade, let us add the lock. No need to navigate away. In the left-hand menu, expand Settings if it is not already open.

Step 1: Select Locks.
Step 2: Click + Add.
Step 3: For Name, enter VM-delete-lock.
Step 4: For Lock type, select Delete.
Optionally, add a note explaining the lock. This note is visible to anyone who encounters the lock later, which helps avoid confusion.
Step 5: Click OK.

The VM is now protected. Attempts to delete guided-project-vm will be blocked until this lock is removed, and removing a lock is a deliberate action that requires navigating to the Locks blade.
Click Home to return to the portal home page.

Task 2: Add Tags to the Virtual Network

The VNet doesn't need a lock, but it should be tagged for the same visibility reasons. Notice that when you go to add tags here, Azure will offer Department as an existing tag name. It learned this from the tag we already applied to the VM. You can reuse it and just set a different value.

From the portal home page, search for Virtual networks and select it.
Step 1: Select guided-project-vnet.
Step 2: In the left-hand menu, select Tags.
Step 3: For Name, select Department from the dropdown (it should appear as an existing tag). For Value, enter IT.
Step 4: Click Apply.

The VNet is now tagged and attributed to the IT department.

Here is a snapshot of everything in place:

This is a real-world Azure environment pattern: segmented networking, tightened security rules, tagged resources for cost tracking and visibility, and locked critical infrastructure. These are not just lab exercises; they are the building blocks of how production environments are actually run.

This series covered the fundamentals of Azure resource management. There is a lot more for us to explore together.
In this series, we built a secure, organized, and protected Azure environment. You now know how to:

Segment networks with subnets and NSGs

Tag resources for instant visibility and cost tracking

Lock critical assets to prevent disaster.

Thanks for following along. I will be glad to hear from you. What Azure topic keeps you up? Networking? Cost management? Security? Drop a comment below, and will cover it in the next series.

Azure Management Task: Locking Down Your Storage #Part 3

Emmanuel — Thu, 25 Jun 2026 21:27:51 +0000

In this third installment, we are going to get hands-on with Azure Storage. Explore the practical steps of managing containers, file shares, and most importantly, securing access to the files within them.

Task 1: Creating a Storage Container

We need a place to store our files. In Azure Storage, a container is like a folder that holds your blobs.

Navigate to your Storage Account: From the Azure portal home page, type "storage accounts" in the search box and select it from the results. Click on the storage account you created in the earlier preparation exercise. It should be linked to your resource group, like guided-project-rg.

Add a Container: On your storage account's blade, locate the Data storage section in the left-hand menu, then select Containers.

Create It: Click on the + Add button. A new pane will appear. Give your container a name, for example, storage-container.

Uploading a File
Now that we have a container, find any image file on your computer (or download one from the internet). Click on your newly created container, storage-container.

Select Upload and browse to your chosen image file. Once uploaded, you will see it in the list.

Task 2: Changing the Access Tier for a Blob

Azure offers different access tiers to help you optimize costs based on how frequently you access your data.

Hot: Optimized for data that is accessed frequently.

Cool: For data that is infrequently accessed and stored for at least 30 days. Cold: For data that is rarely accessed and stored for at least 90 days. Archive: For data that is very rarely accessed and stored for at least 180 days.

For our test file, it doesn't need to be in the Hot tier. Let us move it to Cold. Inside your storage container, click on the uploaded file's name (which is a hyperlink). On the file's overview page, select the Change tier button.

A pane will slide out. Select Cold and click Save.

You have just successfully changed the access tier for an individual blob. Remember, you can also set a default tier at the storage account level to apply to all new blobs.

Task 3: Creating and Managing a File Share

Azure Files provides fully managed file shares in the cloud, accessible via the Server Message Block (SMB) protocol. It's perfect for lifting and shifting legacy applications or creating shared drives for your team.

Let us create one: Go back to your storage account's main blade.

Under the Data storage menu, select File shares.

Click on + File share.

On the "Basics" tab, name your file share file-share.

Move to the Backup tab and uncheck the "Enable backup" box (since this is just a test). Click Review + create, then Create.

Once created, navigate into your new file share and click the Upload button to upload the same image (or a different one) you used earlier for the blob.

Task 4: The Power of Shared Access Signatures (SAS)

Azure offers Shared Access Signatures (SAS). A SAS grants restricted access rights to your storage resources. You can control the permissions, the protocol, and the time window for which the access is valid. This is the core of our management task today.

Generating a SAS URL

From your storage account, select Storage browser from the left-hand menu. Expand Blob containers and select your storage container.

Locate the image you uploaded, and click the ellipsis (...) at the end of its row. From the dropdown menu, select Generate SAS.

Customizing Your SAS Token

A powerful pane will appear, allowing you to fine-tune exactly what access you're granting.

Signing method & key: Choose Account key. You can use either Key 1 or Key 2. Having two keys allows you to rotate them without downtime, as we'll see in a moment.

Stored access policy: Keep this as None for this exercise.

Permissions: For this example, we will grant only read permission. This means anyone with this link can see and download the file, but they can't modify it.

Start and expiry time: You can set a custom window. For learning, leave the defaults, but in a production scenario, always set the shortest time frame necessary.

Allowed protocols: Select HTTPS only for security.

Finally, click the Generate SAS token and URI button. You will see a Blob SAS URL appear. Copy this entire URL.

Testing the Link
Open a new private/incognito browser window or tab and paste the URL you just copied. You should see the image you uploaded displayed directly in the browser, as you see here.

This is the beauty of SAS tokens. You can share this link with anyone, and they will have secure, time-limited access to your file.

Task 5: The Art of Revocation - Rotating Access Keys

A SAS token is secure, but what happens if it gets into the wrong hands, or if someone leaves the company? While you could wait for the expiry time, what if you need to revoke access immediately?

A SAS token signed with an account key is tied to that key. If you regenerate or rotate the storage account key, the SAS token becomes invalid instantly.

Let's see this in action: Go back to your storage account's main blade.

Expand the Security + networking section in the left-hand menu and select Access keys.

For Key 1, click the Rotate key button.

Read the warning carefully. Regenerating a key will invalidate all tokens and apps using that key. Click Yes to confirm.

Once you see the success message, go back to the browser tab where you pasted the SAS URL and refresh the page.

You should be greeted with an error, something like "AuthenticationFailed." The link is now dead. You have successfully revoked access!

Takeaway: This ability to instantly revoke access is why Azure provides two keys. You can rotate Key 1, while all your critical applications use Key 2. Then, you can update those applications to use the new Key 1 and later rotate Key 2 without any downtime. This is a best practice for managing secure access in production.

In just 12 minutes, you have accomplished a lot: You created a blob container and uploaded a file. You learned how to manage costs by changing the access tier of a blob.

You set up a file share, demonstrating the versatility of Azure Storage.

Most importantly, you created and used a Shared Access Signature (SAS) to share a file securely.

Finally, you learned the critical skill of rotating access keys to instantly revoke permissions.

Controlling access is a fundamental skill for any Azure administrator. It is not just about granting permissions, but about understanding the tools to manage and revoke them securely.

See you in part 4 of this series. If you have questions, let me know. I would be happy to support.

Mastering Azure Management Task: A Hands-On Project (Part 2)

Emmanuel — Wed, 24 Jun 2026 22:34:21 +0000

Securing Your Virtual Network with Subnets and Network Security Groups

In Part 1, we built the foundation of our Azure environment: a resource group, a virtual network, a virtual machine, and a storage account. Now it's time to put that network to work.

In this post, we are playing the role of an Azure admin who is asked to prepare the network for a new FTP (File Transfer Protocol) server. The task involves three steps: creating a dedicated subnet for FTP traffic, locking it down with a Network Security Group (NSG), and associating the two together.

Before you begin: This exercise builds directly on the environment created in Part 1. Make sure you have the guided-project-vnet virtual network and guided-project-rg resource group already in place before continuing.

Task 1: Create a New Subnet on the Existing VNet

Log in to the Azure portal.
In the search bar, type Virtual networks and select it under Services.
Select guided-project-vnet from the list.

In the left-hand menu under Settings, select Subnets.
Click + Subnet to add a new one.

Leave the Subnet purpose set to Default.
For Name, enter ftpSubnet.
Leave all other settings at their defaults and click Add.

Click Home to return to the portal home page.

You now have a dedicated subnet for your FTP server.

Task 2: Create a Network Security Group (NSG)

A Network Security Group acts like a firewall at the subnet level. It contains a set of inbound and outbound rules that control which traffic is allowed in or out.

From the portal home page, search for Virtual networks again and select it. This time, select Network security groups from the left-hand panel.
Click + Create.

Verify your subscription is correct.
Select guided-project-rg as the resource group.
Enter ftpNSG as the name.
Click Review + create, then Create once validation passes.
Wait for the deployment to complete, then click Go to resource.

Add an Inbound Security Rule

Now that the NSG exists, we need to tell it what traffic to allow. SFTP runs over SSH on port 22, so we will create a rule that permits inbound TCP traffic on that port.

In the NSG's left-hand menu under Settings, select Inbound security rules.
Click + Add.
Change the Destination port ranges value from 8080 to 22.
Set the Protocol to TCP.
Set the Name to ftpInbound.
Click Add.
Click Home to return to the portal home page.

The NSG now has a rule allowing inbound SFTP traffic on port 22. Next, we need to attach it to the subnet.

Task 3: Associate the NSG with the FTP Subnet

Creating an NSG and creating rules is not enough on its own. The NSG has to be associated with a subnet (or a network interface) before it actually does anything. Let us link ftpNSG to ftpSubnet.

Search for and select Virtual networks from the portal home page.
Select guided-project-vnet.
Under Settings, select Subnets.
Click on ftpSubnet to open it.
On the Edit subnet page, find the Security section and set the Network security group field to ftpNSG.
Click Save.

What You have Built

You have done something meaningful: segmented a virtual network, created a security boundary around it, and restricted access to a single protocol on a single port.

Here is a quick summary of what is now in place:

ftpSubnet — A dedicated subnet within guided-project-vnet, isolated from other VM traffic.
ftpNSG — A Network Security Group with an inbound rule permitting SSH/SFTP traffic on port 22 only.
The NSG is associated with ftpSubnet, meaning the rules are actively enforced on any resource deployed into that subnet.

Follow along to part 3. Let us keep building our Azure administration skills together.

Mastering Azure Management: (Part 1)

Emmanuel — Tue, 23 Jun 2026 23:44:39 +0000

Welcome to the first post in our series on mastering Microsoft Azure management. This series is built around a practical, guided project inspired by Microsoft.
We are going to move beyond theory and dive deep into a practical, guided project inspired by the official Microsoft Learn path: Introduction to Microsoft Azure Management tasks.

This learning path is designed to give you a solid foundation in managing core Azure resources. Over the next few clicks, we will confidently deploy, configure, and manage virtual networks, virtual machines, and storage accounts. As the official documentation states, "You'll have the opportunity to learn about managing virtual machines, virtual networks, and storage accounts, and then a guided project will give you hands-on experience actually managing Azure resources."

Part 1: Preparing Your Azure Environment

Our goal today is to create a resource group, a virtual network (VNet), a virtual machine (VM), and a storage account. This collection of resources will serve as our sandbox for all the management tasks to come.

Prerequisites
Before we begin, ensure you have the following:

• An active Microsoft Azure subscription. If you don't have one, you can sign up for a free account, which typically includes credits to get you started. The official path also notes, "Choose the Azure account that's right for you. Pay as you go or try Azure free for up to 30 days".

Note: In my screenshots, you will see the resource group may17rg — feel free to use your own unique name!

Task 1: Log in and Create a Resource Group
Everything in Azure starts with a resource group. It is a logical container that holds related resources for an Azure solution. Think of it as a folder on your computer where you organize all the files for a specific project.

Navigate to the Azure portal (portal.azure.com).
Search for "Resource groups" and select + Create.
Name your resource group something like guided-project-rg. To make things easy and clean next, choose your preferred region and click Review + create. Note from my resource group name, I already had a resource group, so it's not the name above.

Task 2: Deploy a Virtual Network (VNet)

Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. It enables many types of Azure resources, such as VMs, to securely communicate with each other, the internet, and on-premises networks.

From the Azure portal home page, search for and select Virtual networks.
Select + Create.
Under Instance details, ensure your resource group is selected and name your VNet guided-project-vnet. Leave the other settings as defaults for now and click Review + create.

Task 3: Provision a Virtual Machine (VM)

virtual machine. VMs are one of the most common Azure services, providing on-demand, scalable computing resources. We will be using a Linux VM for this project.

Search for and select Virtual machines.
Click + Create and then Virtual machine.
Under Instance details, select your resource group and name the VM guided-project-vm.
For the Image, select Ubuntu Server 24.04 LTS - x64 Gen2.
Under Administrator account, choose Password as the authentication type. Enter a username and a strong password (make sure you remember it!).
Leave the rest of the settings as defaults and click Review + create.

Task 4: Create a Storage Account

Finally, we need a storage account. This service provides a unique namespace in Azure, entirely lowercase and containing no hyphens/special characters for your data, storing everything from blobs (like files and images) to tables and queues.

Search for and select Storage accounts.
Click + Create.
Choose your resource group.
Enter a Storage account name. This name must be globally unique across all of Azure, so you may need to try a few variations (e.g., guidedprojectstorage123).
Leave all other settings at their defaults and click Review + create.

Conclusion and Next Steps
Congratulations! We have successfully set up the foundational Azure resources that form the core of our project environment. You performed the first crucial steps: creating a logical container, a secure network, a compute resource, and a storage account.
In the next part of this series, we will dive into the real management work. We'll update our virtual network configuration by creating a new subnet to support additional infrastructure requirements. Stay tuned for Part 2, where the real administration begins!

This series follows the Microsoft Learn path: Introduction to Microsoft Azure Management tasks.

Azure Resource Creation: A Step-by-Step Guide to Provisioning Core Infrastructure

Emmanuel — Tue, 09 Jun 2026 14:35:52 +0000

Azure Resource Creation: A Step-by-Step Guide to Provisioning Core Infrastructure
Estimated reading time: 15 minutes

Introduction
If you are just getting started with Microsoft Azure, one of the first skills you will need is creating basic infrastructure resources. Let us walk through this guide provisioning:

A Resource Group (to organize everything)
A Virtual Network with one subnet
A Linux Virtual Machine
A Storage Account

At the end, you will have a working Azure environment ready for management tasks and a solid foundation for future Azure projects.

Prerequisite: An active Azure subscription is needed. If you don't have one, you can sign up for a free Azure account that includes $200 in credits that would enable you practice.

Once logged in, you'll see the Azure Portal home page with dashboards and recent resources.

Step 1: Create a Resource Group
Resource groups are containers that hold related Azure resources. They make cleanup much easier when you are done with a project.

In the search bar at the top of the portal, type "resource groups" and select it from the results.

Click Create at the top of the Resource Groups page.

Fill in the following:

Subscription: Your active subscription (auto-selected)

Resource group name: guided-project-rg

Region: Leave the default (e.g., East US)

Click Review + create, then Create.

Click Home to return to the portal home page.

Pro tip: Take note of any existing resource groups (like NetworkWatcherRG). During cleanup later, you will want to delete only the groups you created.

Step 2: Create a Virtual Network with One Subnet
Virtual networks (VNets) provide the networking foundation for Azure resources like VMs.

From the portal home page, search for "virtual networks" and select it under Services.

Click Create > Virtual network.

On the Basics tab:

Resource group: Select guided-project-rg

Name: guided-project-vnet

Region: Same as your resource group

Click Next: IP Addresses. You'll see a default IPv4 address space of 10.0.0.0/16 with a default subnet 10.0.0.0/24. Keep these defaults.

Click Review + create, then Create.

Step 3: Create a Virtual Machine (Ubuntu Linux)
Now let's create an Ubuntu Linux VM inside your virtual network.

From the portal home page, search for "virtual machines" and select it.

Here is how you can create Ubuntu Linux Virtual machines from my previous article.

Link:

Click Create > Virtual machine.

Fill out the Basics tab:

Subscription: Your subscription (auto-selected)

Resource group: guided-project-rg

Virtual machine name: guided-project-vm

Region: Same as before

Image: Ubuntu Server 24.04 LTS - x64 Gen2 (or any recent Ubuntu LTS)

Size: Leave default (e.g., Standard B1s—free tier eligible)

Scroll to Administrator account:

Authentication type: Password

Username: guided-project-admin

Password: Enter a strong password (minimum 12 characters with uppercase, lowercase, digit, and special character)

Confirm password: Re-enter the same password

Leave all other settings as defaults. Scroll down and click Review + create.

Azure will validate your configuration. Once validation passes, you'll see a cost estimate.

Click Create to deploy the VM.

Wait for deployment to complete, then click Home to return to the portal home page.

Note: VM creation takes 2-3 minutes.

Step 4: Create a Storage Account
Storage accounts provide cloud storage for blobs, files, queues, and tables.

From the portal home page, search for "storage accounts" and select it.

Click Create.

On the Basics tab:

Subscription: Your subscription (auto-selected)

Resource group: guided-project-rg

Storage account name: Enter a globally unique name (e.g., guidedprojectsa2027). If the name is taken, try adding numbers or your initials.

Region: Same region

Performance: Standard

Redundancy: Locally-redundant storage (LRS)

Click Review + create.

After validation, click Create.

Wait for your deployment is complete, then click Home.

Step 5: Verify Your Deployed Resources
Let's confirm everything was created successfully.

From the portal home page, go to Resource groups.

Click on guided-project-rg.

You should see:

guided-project-vm (Virtual machine)

guided-project-vnet (Virtual network)

Your storage account name

Possibly NetworkWatcherRG (created automatically—do not delete if it existed before)

Cleanup (Optional but Recommended)
To avoid ongoing costs, delete the resource group when you're done:
Step 6:
Navigate to guided-project-rg

Click Delete resource group

Type the resource group name to confirm

Click Delete

Warning: Only delete the resource group you created. Do not delete NetworkWatcherRG if it existed before you started this guide.

What you have Accomplished
Congratulations! You've successfully provisioned:

Resource Purpose
Resource Group Logical container for organization
Virtual Network Networking foundation
Ubuntu VM Compute resource for running applications
Storage Account Persistent cloud storage

Cloud Concepts Explained: 6 Key Concepts Every Beginner Needs to Know

Emmanuel — Tue, 09 Jun 2026 14:17:27 +0000

understanding cloud now is a smart move. But if you have already started reading up on it, you have probably hit a wall of tech buzzwords.

Like; Scalability, agility, virtualization which can sound like a sci-fi movie.

Let us Strip away the jargon, the cloud is actually pretty straightforward. At its core, it is about helping businesses run faster, smarter, and more reliably.

Let us break down six essential cloud concepts in plain English and clear up the single biggest point of confusion: the difference between scalability and elasticity.

Virtualization: The magic trick behind the Cloud Before the cloud, if a company needed three different servers for three different tasks, they had to buy three physical boxes of hardware. Expensive and was wasteful.

Virtualization changes that. It is software that separates physical hardware from the operating systems. Think of it as turning one giant physical computer into multiple “virtual” computers (called Virtual Machines, or VMs) that run independently.

The Analogy: Imagine an apartment building. Instead of everyone buying their own private piece of land to build a tiny house (physical servers), virtualization builds one massive apartment complex where each person gets their own private, secure unit (virtual server). It maximizes space and resources.

Scalability: Growing Without growing Pains Ever tried to open a website on Black Friday only to have it crash? That is a scale issue.

Scalability is the cloud’s ability to handle increasing (or decreasing) workloads by adding or removing resources. If your website gets a sudden traffic spike, a scalable system lets you easily add more power so the site stays up.

Two ways to scale:

Vertical Scaling (Scaling Up): Making a single server more powerful (like adding more RAM or a faster CPU to your laptop).

Horizontal Scaling (Scaling Out): Adding more servers to share the load (like hiring five more people to move furniture instead of making one person carry it all).

Agility: Moving at the Speed of Ideas In the old IT world, getting a new server could take weeks—ordering hardware, shipping, setup. In the cloud, you can spin up a new server in minutes with a few clicks.

That’s agility. It means developers can test new ideas, launch features, or respond to customer feedback almost instantly. Instead of waiting for infrastructure, you just build.

Elasticity: The Key Difference from Scalability This is where most people get confused.

Scalability is planned. You know traffic will grow over time, so you design your system to handle more load by adding resources proactively.

Elasticity is automatic and dynamic. Resources scale up and down in real time, based on current demand—no human needed.

Example: A video streaming service expects more viewers on Friday night (scalability). But if a surprise live event causes a sudden spike, elasticity automatically adds more servers for 20 minutes, then removes them when traffic drops. You only pay for what you use.

Another analogy: Scalability is like adding more chairs to a conference room before a scheduled meeting. Elasticity is like a restaurant that magically expands and shrinks its floor space depending on the lunch rush.

Pay-as-You-Go: No More Guessing Traditional IT forced companies to buy enough capacity for peak demand—even if that peak happened only once a year. The rest of the time, those servers sat idle.

The cloud flips this. You pay only for what you actually use, by the second or hour. If you need less next month, you pay less. No waste, no guessing games.

Reliability: Not Putting All Your Eggs in One Basket In the old days, if a server’s hard drive failed, your website went down. In the cloud, your data is usually copied across multiple physical machines—often across different data centers in different regions.

If one server fails, another takes over seamlessly. This is called redundancy, and it is why cloud services can promise 99.9% uptime.

The Bottom Line
The cloud is not magic. It is just virtualization + automation + smart pricing.

Virtualization makes one physical server act like many.

Scalability lets you grow (or shrink) on purpose.

Elasticity does it automatically, in real time.

Agility means you can move fast.

Pay-as-you-go saves money.

Reliability keeps things running.

Once you separate the marketing hype from the actual mechanics, the cloud is one of the most practical tools businesses have ever had. If you did love to add to this article kindly leave a comment below.

Securing Azure Storage: A Hands-on Guide to Managed Identities, Key Vaults, and Immutability

Emmanuel — Wed, 27 May 2026 14:13:43 +0000

Azure Storage security involves multiple layers of protection
working together. In this guide from Microsoft Learn , we are going to eliminate that risk by configuring a User-Assigned Managed Identity (allowing our app to authenticate without passwords) and leveraging an Azure Key Vault to manage encryption keys securely.

You will learn how to:

Eliminate credential management using Managed Identities
Centralize key management using Azure Key Vault -Protect data from modification using Immutable Blob Storage
Add an extra encryption layer using Encryption Scopes

Who this is for:
Anyone new to Azure security who wants hands-on experience securing cloud storage.

Estimated time: 20–25 minutes

Task Overview:

Create the storage account and managed identity.
Secure access to the storage account with a key vault and key.
Configure the storage account to use the customer managed key in the key vault
Configure a time-based retention policy and an encryption scope.

STEP 01:

Create the storage account and managed identity

In the global Azure search bar, search for and select Storage accounts. Create a storage account for the web app.

Select + Create.
For the Resource group field, click Create new, assign your group a custom name, and select OK..
Provide a Storage account name. Ensure the name is unique and meets the naming requirements.

Click next to move to the Encryption tab.

Check the box for Enable infrastructure encryption.
Notice the warning, This option cannot be changed after this storage account is created. Select Review + Create. Wait for the resource to deploy.

STEP 02:

Provide a managed identity for the web app to use.

Search for and select Managed identities.

Select Create.
Select your resource group.
Give your managed identity a name.
Select Review and create, and then Create.

STEP 03:

Assign the correct permissions to the managed identity. The identity only needs to read and list containers and blobs.

Search for and select your storage account.
Select the Access Control (IAM) blade.
Select Add role assignment (center of the page).

On the Job functions roles page, search for and select the Storage Blob Data Reader role.

On the Members page, select Managed identity.
Select Select members, in the Managed identity drop-down select User-assigned managed identity.
Select the managed identity you created in the previous step.
Click Select and then Review + assign the role.
Select Review + assign a second time to add the role assignment.

Your storage account can now be accessed by a managed identity with the Storage Data Blob Reader permissions.

Secure access to the storage account with a key vault and key

STEP 04:
To create the key vault and key needed for this part of the lab, your user account must have Key Vault Administrator permissions.

In the portal, search for and select Resource groups. By now you know how to search using the Azure portal search bar.
Select your resource group, and then the Access Control (IAM) blade.
Select Add role assignment (center of the page).
On the Job functions roles page, search for and select the Key Vault Administrator role.

On the Members page, select User, group, or service principal.
Select Select members.
Search for and select your user account. Your user account is shown in the top right of the portal.
Click Select and then Review + assign.

Select Review + assign a second time to add the role assignment. You are now ready to continue with the lab.

STEP 05:

Create a key vault to store the access keys.

In the portal, search for and select Key vaults.

STEP 06:

Select Create.
Select your resource group.
Provide the name for the key vault. The name must be unique.
Ensure on the Access configuration tab that Azure role-based access control (recommended) is selected.
Select Review + create.

Wait for the validation checks to complete and then select Create.
After the deployment, select Go to resource. On the Overview blade ensure both Soft-delete and Purge protection are enabled.

STEP 07:
*Create a customer-managed key in the key vault.
*
Customer-managed keys allow organizations to control their own encryption lifecycle instead of relying solely on Microsoft-managed encryption.

In your key vault, in the Objects section, select the Keys blade.
Select Generate/Import and Name the key.
Take the defaults for the rest of the parameters, and Create the key.

Configure the storage account to use the customer managed key in the key vault

Before you can complete the next steps, you must assign the Key Vault Crypto Service Encryption User role to the managed identity.

STEP 08:

Select your resource group, and then the Access Control (IAM) blade.
Select Add role assignment (center of the page).
On the Job functions roles page, search for and select the Key Vault Crypto Service Encryption User role.

STEP 09:

On the Members page, select Managed identity.
Select Select members, in the Managed identity drop-down select User-assigned managed identity.
Select your managed identity.
Click Select and then Review + assign.

Select Review + assign a second time to add the role assignment.

Configure the storage account to use the customer managed key in your key vault.

STEP 10:

Return to your the storage account.
In the Security + networking section,
select the Encryption blade.
Select Customer-managed keys.
Select a key vault and key.

STEP 11:
Select your key vault and key.
Select to confirm your choices.
Ensure the Identity type is User-assigned.
Select an identity.
Select your managed identity then select Add.
Save your changes.

If you receive an error that your identity does not have the correct permissions, wait a minute and try again.

Configure a time-based retention policy and an encryption scope.

The developers require a storage container where files can’t be modified, even by the administrator.

STEP 12:
Navigate to your storage account. In the Data storage section,

Select the Containers blade.
Create a container called hold. Take the defaults. Be sure to Create the container.

Upload a file to the container.

In the Settings section, select the Access policy blade.
In the Immutable blob storage section, select + Add policy. Immutable Blob Storage helps organizations meet compliance requirements and protects against ransomware by preventing data deletion or modification during the retention period.
For the Policy type, select time-based retention.
Set the Retention period to 5 days.
Be sure to Save your changes.

Try to delete the file in the container.
Verify you are notified failed to delete blobs due to policy.

The developers require an encryption scope that enables infrastructure encryption. Learn more about infrastructure encryption.

Navigate back to your storage account.
In the Security + networking blade, select Encryption.
In the Encryption scopes tab, select Add.
Give your encryption scope a name.
The Encryption type is Microsoft-managed key.
Set Infrastructure encryption to Enable.
Create the encryption scope.

Return to your storage account and create a new container.
Notice on the New container page, there is the Name and Public access level.
Notice in the Advanced section you can select the Encryption scope you created and apply it to all blobs in the container.

What You Accomplished

In this guide you successfully implemented four layers of
Azure Storage security:

Managed Identity — your app accesses storage without storing credentials
Key Vault + Customer-Managed Key — you control the encryption keys for your storage data
Immutable Blob Storage — files in your container cannot be modified or deleted during the retention period
Encryption Scope — an additional encryption layer applied at the container level

These security controls work together to protect your data
against unauthorized access, accidental deletion, and
compliance risks.

You have successfully configured an end-to-end cloud security framework for Azure Storage! By leveraging managed identities, safeguarding keys via Azure Key Vault, and setting up time-based immutability parameters, you have built a production-ready, zero-trust storage layer.

How did you customize your configuration? Let me know in the comments section below!

Lock Down Your Cloud Shares: A Beginner’s Guide to Azure Files Security.

Emmanuel — Mon, 25 May 2026 11:32:43 +0000

Cloud storage makes file sharing easy, but it also creates new security risks if access is not controlled carefully.

Take this scenario for instance: Your finance team stores payroll files in the cloud, but a misconfigured setting accidentally exposed them to the public internet last week. This guide shows you how to prevent exactly that.

In this hands-on tutorial, you will learn the basics of securing Azure Storage using practical, layer-by-layer security steps: from automated backups to network-level blockades.

Why storage security matters
Azure Storage is designed to be secure, but the way you configure it determines how much protection your data actually gets.

*Tasks Overview *

Create a storage account specifically for file shares.
Configure a file share and directory.
Configure snapshots and practice restoring files.
Restrict access to a specific virtual network and subnet.

In the portal, search for and select Storage accounts.
Select + Create.

For resource group select Create new. Give your resource group a name- Provide a Storage account name. Ensure the name meets the naming requirements. Storage account names must be 3–24 characters, all lowercase, no spaces or hyphens. Example: exercise42026.
Azure will show a green checkmark if the name is valid and available.

NOTE: Premium = SSD-backed, low-latency storage. Use it when your app needs fast file access. Standard (HDD) is cheaper for less time-sensitive files. ZRS = Zone-Redundant Storage: your data is copied across 3 availability zones in the same region, protecting against a single data center going down.

Set the Performance to Premium.
Set the Premium account type to File shares.
Set the Redundancy to Zone-redundant storage.
Select Review and then Create the storage account.
Wait for the resource to deploy.
Select Go to resource.

Select Go to resource.

Azure Files is like a shared network drive in the cloud — multiple users or VMs can connect and access files simultaneously using the SMB protocol, just like a traditional office file server.

In the storage account, in the Data storage section,

select the File shares blade.
Select + File share and provide a Name.
Review the other options, but take the defaults.
Select Review + create, then Create.

Next Step:

Select your file share and select + Add directory.
Name the new directory finance.
Select Browse and then select the finance directory.
Notice you can Add directory to further organize your file share.
Upload a file of your choosing.

Similar to blob storage, you need to protect against accidental deletion of files. You decide to use snapshots. A snapshot is a read-only copy of your file share captured at a specific point in time like a save point in a video game. If someone accidentally deletes or overwrites a file, you can roll back to the snapshot and restore it. Here is how to create one:

Select your file share.
In the Operations section, select the Snapshots blade.
Select + Add snapshot. The comment is optional.
Select OK.
Select your snapshot and verify your file directory and uploaded file are included.

NEXT: Practice using snapshots to restore a file.

Return to your file share.
Browse to your file directory.
Locate your uploaded file and in the Properties pane select Delete. Select Yes to confirm the deletion.

Select the Snapshots blade and then select your snapshot.
Navigate to the file you want to restore,
Select the file and the select Restore.
Provide a Restored file name.

Verify your file directory has the restored file.
After restoring, go back to Browse in your file share. You should see the restored file listed alongside the original directory as shown in the screenshot above. The restored copy has a new name we provided, so the original is not overwritten.

Configure restricting storage access to selected virtual networks.

The tasks in this section require a virtual network and a subnet to demonstrate perimeter security.
A Virtual Network (VNet) is a private network in Azure — like your office's internal network, but in the cloud. A subnet is a segment within that network.

Search for and select Virtual networks.
Select Create.
Select your resource group. and give the virtual network a name.

Take the defaults for other parameters,
select Review + create, and then Create.
Wait for the resource to deploy.
Select Go to resource.

In the Settings section, select the Subnets blade.
Select the default subnet.
In the Service endpoints section choose Microsoft.Storage in the Services drop-down.
Do not make any other changes.
Be sure to Save your changes.
The storage account should only be accessed from the virtual network you just created.

Return to your files storage account.
In the Security + networking section, select the Networking blade.
Change the Public network access to Enabled from selected virtual networks and IP addresses.
In the Virtual networks section, select Add existing virtual network.
Select your virtual network and subnet, select Add.
Be sure to Save your changes.

Select the Storage browser and navigate to your file share.
Verify the message not authorized to perform this operation. You are not connecting from the virtual network. You should see a 403 error: This request is not authorized to perform this operation. This is expected — it confirms your network restriction is working. Your storage account is now only accessible from inside the virtual network you created.

Did this guide help you? Got stuck at a step or found something that could be explained better?
Drop a comment below I do read every one and I genuinely appreciate the feedback.
If you found this useful, consider sharing it with someone just getting started with Azure. As we all learn faster together.

Azure Blob Storage for Beginners: Private Access, SAS Tokens & Cost Savings Explained

Emmanuel — Tue, 19 May 2026 10:36:32 +0000

In this beginner walkthrough based on the Microsoft Learn guided exercise we configure a private Azure Blob Storage account for internal company documents.

Imagine your company stores HR files, contracts, or financial reports. You need them available 24/7, protected from public access, and cost-efficient to store long-term. That's exactly what this guide sets up.

What we will build:
•A private storage account with GRS redundancy
•A restricted blob container for internal documents
•A time-limited SAS token for partner access
•Automated lifecycle rules to move blobs to Cool tier after 30 days
•Cross-account object replication for public website backup

Overview
The solution uses a single private storage account containing two blob containers: one for internal documents and one named 'backup' that receives replicated content from the public website storage account.

In the portal, search for and select Storage accounts.
Select + Create.

Select the Resource group created in the previous lab.

Set the Storage account name to private. Add an identifier to the name to ensure the name is unique. Tip : Storage account names must be 3–24 characters, all lowercase, no spaces or special characters. Try something like privatecompany2025. Azure will tell you if it's already taken.

Select Review, and then Create the storage account.

Wait for the storage account to deploy, and then select Go to resource.

Configure the appropriate level of redundancy.

In the storage account, in the Data management section, select the Redundancy blade.
Ensure Geo-redundant storage (GRS) is selected.
Refresh the page.

What is GRS? Geo-Redundant Storage automatically copies your data to a second Azure region. So if a data center goes down, your files are still safe and accessible.

Review the primary and secondary location information.
Save your changes.

In the storage account, in the Data storage section, select the Containers blade. Select + Container.
Ensure the name of the container is private.
Ensure the Public access level is Private (no anonymous access).

Why Private? Setting the container to Private means no one can view or download files using just a URL. They need a key or a special token. This is what keeps internal company files away from the public internet. As you have time, review the Advanced settings, but take the defaults. Select Create.

For testing, upload a file to the private container. The type of file doesn’t matter. A small image or text file is a good choice. Test to ensure the file isn’t publically accessible.

Select the container.
Select Upload.
Browse to files and select a file.
Upload the file.
Select the uploaded file.
On the Overview tab, copy the URL.
Paste the URL into a new browser tab.

Verify the file doesn’t display and you receive an error. You should see a ResourceNotFound or 403 (Forbidden) error, this is correct! It confirms your container is properly locked down.

What is a SAS Token? A Shared Access Signature is like a temporary visitor badge. Instead of giving your partner your account password, you generate a special link that expires after a set time and only allows the permissions you choose (e.g., read-only). Once it expires, the link stops working automatically.

An external partner requires read and write access to the file for at least the next 24 hours. Configure and test a shared access signature (SAS).

Select your uploaded blob file and move to the Generate SAS tab- Select Generate SAS token and URL. Copy the SAS URL immediately. Azure will not show it again once you close this panel.Treat it like a password; don't share it publicly. In the Permissions drop-down, ensure the partner has only Read permissions.Verify the Start and expiry date/time is for the next 24 hours or time requested.

Copy the Blob SAS URL to a new browser tab.
Verify you can access the file. If you have uploaded an image file it will display in the browser as you have seen in the screenshot. Other file types will be downloaded.

Configure storage access tiers and content replication.

To save on costs, after 30 days, move blobs from the hot tier to the cool tier. Hot vs Cool Storage: Azure charges you based on how often data is accessed. Hot tier is for files you access frequently, faster but pricier. Cool tier is for files you rarely touch — slower but cheaper. Lifecycle rules automate the switch so you don't have to do it manually.

Return to the storage account.
In the Overview section, notice the Default access tier is set to Hot. In the Data management section, select the Lifecycle management blade. Select Add rule.Set the Rule name to movetocool.
Set the Rule scope to Apply rule to all blobs in the storage account.
Select Next.Ensure Last modified is selected.Set More than (days ago) to 30.In the drop-down select Move to cool storage.

As you have time, review other lifecycle options in the drop-down.
Add the rule.The public website files need to be backed up to another storage account.

In your storage account, create a new container called backup. Use the default values. Refer back to Lab 02a we did if you need detailed instructions.

Navigate to your publicwebsite storage account. This storage account was created in the previous exercise. If you don't already have a public storage account, create one using the same steps in Step 1 above, and name it publicwebsite. Create a container inside it called public and upload any file to it.

In the Data management section, select the Object replication blade. Select Create replication rules.
Set the Destination storage account to the private storage account.
Set the Source container to public and the Destination container to backup. Once done you can click create.

That's it — we've successfully concluded that the necessary steps needed to create a redundant storage account.

Great work! Here is what you have built:

Feature What It Does

GRS Storage Account - Keeps data safe across regions.
Private Container - Blocks public internet access.
SAS Token Grants time -limited partner access Lifecycle
Rule - Saves cost by moving old data to Cool tier Object Replication Auto - backs up your public website files.

Next steps: When you have time you could Explore Azure RBAC(https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) to control who in your team can manage storage, or try Azure Key Vault to manage SAS keys securely.

I did truly appreciate any insights or additions that could help enhance this article!

How to Deploy an Ubuntu Linux VM in Azure

Emmanuel — Sat, 16 May 2026 21:44:39 +0000

We will use the Azure Portal (GUI) to launch an Ubuntu Linux Virtual Machine (VM).

Note: Azure charges by the minute while your VM is running. Don't forget to delete everything at the end so you pay nothing (or just pennies).

Step 1: Create Your Resource Group
Think of a Resource Group as a folder that will hold your VM and all its related parts. Creating it first keeps things organized.

Create a Resource Group:

Click + Create a resource in the top left corner.

Type "Resource Group" in the search bar and select it.

Click Create.

Name it MyLinuxLab_RG

Select a Region close to you (e.g., East/West US)

Click Review + create → Create

Quick Definition: A Region is the physical location of the data center where your cloud resources will live.

Step 2: Create the Ubuntu Linux VM
Now that your folder (Resource Group) is ready, let's build the actual Linux computer.

Basics Tab:

Resource Group: Select MyLinuxLab_RG from the dropdown

Virtual Machine Name: Ubuntu-Lab-01

Region: Choose the same region you used for your Resource Group

Availability Options: Leave as "No infrastructure redundancy required" (fine for learning)

Image: Confirm it says Ubuntu Server 22.04 LTS (or newer)

Size: Choose Standard_B2s — it's cost-effective and perfect for learning or the default.

Administrator Account:

Authentication type: Select password

Username: azadmin (or a name you'll remember)

Quick Definition: SSH (Secure Shell) is the secure "door" that lets you type commands into your Linux VM from your own terminal. The key pair is like a digital lock and key.

Inbound Port Rules: Under "Public inbound ports," ensure Allow selected ports is checked Http Port 80 and SSH (22) is selected as we move forward we will learn more together.

Click Review + create → wait for the green "Validation passed" message → Click Create

Note: Don't worry if you see yellow warnings — those are usually fine. Look for the green checkmark.

To ensure that your terminal section does not go off. Click the IP address ensure you extend the time under networking.

Step 3:
Click Connect which would enable you remotely login to the Linux VM:

For windows you would need to open/launch Powershell and For Mac you would open/launch Terminal and run the ID and Ip given.
Now you see my powershell on my windows prompting for Password.

Next: We would login in as a root user which is the same as an administrator in Windows.
"sudo su" and run "apt update" which is to ensure that the latest update is installed.

Step 4: We would install the ntp package - also know as the package manager. "ntp install nginx"

This shows we did login in successfully and we can also remotely login using other options.

Step 5:
Remember to delete.

If this help you in any way kindly share. If you did like to spice up this beginner guide in the comment section I did love that.

How to Create a Windows 10 Virtual Machine in the Azure Portal (No CLI Needed)

Emmanuel — Wed, 13 May 2026 23:00:52 +0000

In this guide, we are going to bypass the command line entirely (that is the CLI — Command Line Interface, like PowerShell or Bash). We will use the Azure Portal (GUI) to launch a Windows 10 Virtual Machine (VM) in about 7 minutes.

Cost Note: Azure charges by the minute while your VM is running. Delete everything at the end and your cost will be minimal or zero, especially if you are on a free trial.

A Virtual Machine (VM) is a computer that runs inside another computer — entirely in the cloud. You access it remotely just like a normal PC.

Phase 1: The Setup

Sign In: Log into the Azure Portal.
Create a Resource: Click the + Create a resource button in the top left.

Resource Group: Click "Create new" and name it any name for example MyVMGroup. Virtual Machine Name: Name it DevOps-Lab-01. Region: Select the one closest to you (e.g., East US).

When finish go to the resource group you just created and open it.

Next Select the Service search bar: Type "Windows 10" in the search bar and select the Windows 10 option or the "consumer editions" or "Pro."

Quick Definition: A Region is simply the physical location of the data center where your virtual computer will live.

Phase 2: Configuration & Identity

Size: Choose Standard_B2s. It's cost-effective and perfect for learning.

The "Size" selection window showing the B2s option and its estimated monthly cost. Ensure you check the Run with Azure spot discount

This lets Azure use spare capacity to run your VM at a lower cost. It is perfect for learning because we are not running anything critical.

*7. Administrator Account: *

Enter a username and
A strong password.

⚠️ Important: Save these! You will need them to "log in" to your computer later.

*Inbound Port Rules: * Under "Public inbound ports," ensure Allow selected ports is checked and RDP (3389) & Http (80) is selected.

Review + Create: Skip the other tabs for now. Click the blue Review + Create button at the bottom.

The Deployment

Confirm: Azure will run a validation check. Look for the green "Validation passed" message. Then click Create.

Phase 3: Connecting via Remote Desktop (RDP)
Once the deployment is complete, click Go to resource.

Click the Connect button at the top left and select RDP.

Click Download RDP File. This file is your "digital key."
Open the downloaded file and click Connect.
Enter the Username and Password you created in Phase 2.
The Certificate Warning: A box will pop up saying the identity cannot be verified. This is normal! Click Yes.

VM running live.

You have just deployed a real cloud computer from scratch no command line needed.

What You Just Learned:
Azure Term : What It Actually Means
Resource Group: A folder for your cloud project
Region: Which data center your VM lives in
VM : A computer that runs inside another computer entirely in the cloud.
RDP: The remote "screen share" protocol
VM Size: How much CPU/RAM your lab computer gets

Next Step: Don't Forget to Clean Up!
When you are finished testing, delete your Resource Group to avoid any unnecessary charges:

Go to Resource groups in the Azure Portal.
Find MyVMGroup.
Click Delete resource group and type the name to confirm.

The Resource Group page showing the "Delete resource group" button and the confirmation text box.

If you found this helpful, kindly share it with someone else starting their DevOps journey. If you are on the same path, I did love to hear how your experience went — drop a comment or reach out.