Forem: Precious Uchechukwu Nwafor

Project: Update and Maintain Azure Resources

Precious Uchechukwu Nwafor — Tue, 24 Mar 2026 01:51:20 +0000

This project gives us the chance to practice managing Azure resources, including networks, virtual machines, and storage blobs. We will also have the chance to work with tags and resource locks. In this article we will learn how to update a virtual network and subnet, manage virtual machines, control storage access, and manage resource tags and locks.

Note : This guided project requires us to provide an Azure subscription. Leaving resources provisioned and running after completion of the exercise may result in unexpected costs. It is important to keep track of resources you create to ensure you remove them during the clean-up task. Where possible, follow recommended naming conventions to make it easier to clean up the resource for this project at the end. Creating and using Azure resources for this project may increase your Azure costs.

Let's get to it!

Phase 1: The first phase is to prepare our environment.

Action plan:

Step 1: From the Azure portal home page, in the search box, enter resource groups. Select Resource groups under services.

Important: Take note of other resource groups that are already created. During clean up, you want to avoid deleting resource groups that were already here. Pay special attention for a resource group called NetworkWatcherRG. If it doesn’t already exist, the NetworkWatcherRG will be created during this guided project and should be deleted at the end. However, if the NetworkWatcherRG already exists prior to starting this project, you should NOT delete it at the end. It may be helpful to take a screenshot of resource groups that exist before you create the group for the guided project.

Step 2: Select Create.

Note: Your subscription should already be selected. If you have multiple Azure subscriptions associated with this login, select the one you’d like to use for the guided project.

Step 3: Enter guided-project-rg in the Resource group name field. The Region field will automatically populate. Leave the default value. Select Review + create.

Step 4: Select Create.

Step 5: Return to the home page of the Azure portal by selecting Home. If Home is not visible, select Microsoft Azure.

Step 6: Create a virtual network with one subnet
From the Azure portal home page, in the search box, enter virtual networks. Select virtual networks under services.

Step 7:Select Create.

Step 8: Click Resource group drop-down menu and select the Resource group we created earlier, guided-project-rg Scroll down to the Instance details section and enter guided-project-vnet for the Virtual network name. Select Review + create.

Step 9: Select Create. Wait for the screen to refresh and show Your deployment is complete.

Step 10: Select Home to return to the Azure portal home page.

Step 11: Create a virtual machine. From the Azure portal home page, in the search box, enter virtual machines. Select virtual machines under services.

Step 12: Select Create and then select Virtual machine.

Step 13: Select guided-project-rg for the Resource group.
Enter guided-project-vm for the Virtual machine name.

Important : Notice the error when you scroll down. This size is currently unavailable in East USfor the current subscription: NotAvailableForSubscription.

Troubleshooting Azure: Regional Quota & Resource Constraints

When deploying a Virtual Machine (VM) in Azure, you might hit a Subscription Quota or SKU Availability error. This usually means your chosen VM size isn't available in your current region (e.g., US East).

The quick fix? Deploy the VM to a region like Korea Central where the size is supported. But what happens to your existing infrastructure? Here is the breakdown:

1. The Resource Group (RG)

You do not need to delete your Resource Group in US East.

The Logic: An RG is a logical container used for management and metadata.
The Benefit: While the RG itself is located in US East to store its metadata, the actual resources inside it (VMs, Networks, Storage) can be located in any region supported by your subscription.

2. The Virtual Network (VNet) Dependency.

Unlike the Resource Group, a Virtual Machine must reside in the same region as its Virtual Network. Because we are moving the VM to Korea Central, the initial VNet in US East becomes incompatible.

The Fix: We must deploy a new Virtual Network in Korea Central to support the new VM.

3. The Implementation Strategy

If the project requires a specific, unique naming convention for the VNet:

Delete the initial Virtual Network in US East (to free up the name).
Deploy the new Virtual Machine to Korea Central.
Create the new Virtual Network in Korea Central during the deployment process, using the required name.

Key Takeaway

Resource Groups are globally flexible logical containers, but Networking and Compute resources are "region-locked" to each other. Always ensure your VNet and VM share the same regional home!

Step 14 : Now lets get back to creating our VM. Due to the Size constraint we will change the region to Korea Central. Once you notice the error is gone, proceed to the next step. For the Image, select one of the Ubuntu Server options. (For example, Ubuntu Server 24.04 LTS - x64 Gen2). Select an available size for your VM in your selected region. Continue further on the Basics page to the Administrator account section. Select Password for authentication type. Enter guided-project-admin for the admin Username. Enter a password for the admin account. Confirm the password for the admin account. Leave the rest of the settings as default settings. You can review the settings if you like, but shouldn’t change any. Select Review + create. Select create. Go to Home page after deployment confirmation.

Step 15: We will proceed create a Storage account. From the Azure portal home page, in the search box, enter storage accounts. Select Storage accounts under services. Select create.
Scroll down to the Instance details section and enter a name for the storage account. Storage accounts must be globally unique, so you may have to try a few different times to get a storage account name.
Select Review + create. Select Create. Wait for the screen to refresh and show Your deployment is complete. Select Home to return to the Azure portal home page. We have completed the Prepare exercise. Return to Microsoft Learn to continue to Phase 2.

Phase 2: Update the virtual network. We are helping an Azure Admin maintain resources. While we won’t be responsible for maintaining the entire infrastructure, the Admin will ask us to help out by completing certain tasks.

Currently, there’s a Linux virtual machine (VM) that’s underutilized, and a need for a new Linux machine to serve as an FTP server. However, the Azure admin wants to be able to track network flow and resource utilization for the needed FTP server, so has asked us to start out by provisioning a new subnet. The current subnet should be left alone, as there are future plans for using it for additional VMs.

Action plan:

Step 1: Create a new subnet on an existing virtual network (vNet).
From the Azure portal home page, in the search box, enter virtual networks. Select virtual networks under services. Select the guided-project-vnet virtual network. From the guided-project-vnet blade, under settings, select Subnets. To add a subnet, select + Subnet. For Subnet purpose leave it as Default. For Name* enter: ftpSubnet. Leave the rest of the settings alone and select Add. To increase security, you need to configure a Network security group to restrict which ports are allowed on the subnet.

Step 2 : Create a network security group . From the Azure portal home page, in the search box, enter virtual networks. Select virtual networks under services. Select Network security groups. Select + Create. Verify the subscription is correct*. Select the **guided-project-rg resource group. Enter ftpNSG for the network security group name. Select Review + create. Once the validation is complete, select Create. Wait for the screen to refresh and display Your deployment is complete. Select Go to resource.

Step 3 : Create an inbound security rule. Under settings, select Inbound security rules. Select + Add. Change the Destination port ranges from 8080 to 22. Select TCP for the protocol. Set the name to ftpInbound. Select Add.
Select Home to return to the Azure portal home page. We created a new Network security group and configured rules to allow inbound FTP traffic. Now, we will need to associate the new network security group with the ftpSubnet.

Step 4 : Associate a network security group to a subnet.
From the Azure portal home page, in the search box, enter virtual networks. Select virtual networks under services. Select the guided-project-vnet virtual network. Under settings, select Subnets. Select the ftpSubnet we created. On the Edit subnet page, under the Security section heading, update the Network security group field to ftpNSG. Select Save. We have completed the work needed to prepare the network for shifting the current Linux VM to a new subnet that’s designed to handle incoming FTP traffic. We will move to Phase 3.

Phase 3:Manage virtual machines. With the network settings updated to support segmenting the Linux virtual machine, you are ready to manage the virtual machine itself. The first thing the Azure admin asks us to complete is moving the virtual machine to the new subnet you created in the previous exercise.

Action plan:

Step 1: Move the virtual machine network to the new subnet
From the Azure portal home page, in the search box, enter virtual machines. Select virtual machines under services. Select the guided-project-vm virtual machine. If the virtual machine is running, select Stop. Wait for the Status field to update and show Stopped (deallocated). Within the Networking subsection of the menu, select Network settings. Select the Network interface / IP configuration hyperlink for the VM. On the IP Configurations page, update the Subnet to ftpSubnet. Select Apply. Good job! we have migrated the VM from one subnet to another. Remember, the new subnet had specific network security rules applied to help it function as an FTP server.

Step 2:The next task from the Azure admin relates to the computing power of the VM. The admin would like us to vertically scale the machine to increase the computing power . From the Azure portal home page, in the search box, enter virtual machines . Select virtual machines under services. Select the guided-project-vm virtual machine . Locate the Availability + scale submenu and select Size . Select a new VM size D2s_v5 for example . (Note: If you don’t see the same size as shown in this exercise, select something similar.) Select Resize . Note: The VM size may not update in the Azure UI until the VM is restarted. Select Home to return to the Azure portal home page.
With the VM scaled up to a more robust processor, it can handle the new role it’s being assigned. However, now the Azure admin realizes that if the VM is going to server as an FTP server, it needs more storage. The Azure admin asked us to attach a new data disk to the VM.

Step 3: Attach data disks to a virtual machine. From the Azure portal home page, in the search box, enter virtual machines. Select virtual machines under services. Select the **guided-project-vm virtual machine. Locate the settings submenu and select Disks. Select Create and attach a new disk.Leave LUN as default.Enter ftp-data-disk for the Disk name.Leave the Storage type as default.Enter 20 for the Size.Select Apply to create the new storage disk and attach the disk to the machine. Select Home to return to the Azure portal home page.

Awesome! Now the VM has enough storage to handle some uploads. The final thing the Azure admin is concerned about is the cost of running the computer 24 hours a day. The first thing they will do every morning is start up the FTP server. However, they’d like you to configure it to automatically shutdown every day at 7 PM Coordinated Universal Time (UTC).

Step 4 : Configure automatic shutdown on the virtual machine.
From the Azure portal home page, in the search box, enter virtual machines. Select virtual machines under services. Select the guided-project-vm virtual machine. Under the Operations submenu, select Auto-shutdown. In order to let late uploads finish, set the Scheduled shutdown to 7:15:00 PM. Select Save. Select Home to return to the Azure portal home page. Congratulations! We have successfully completed all of the management tasks the Azure admin needed a hand with for the virtual machine.

Phase 4: Control storage access. The Azure admin wants us to get more familiar with storage accounts, containers, and file shares. They anticipate needing to share an increasing number of files and need someone who is skilled using these services. They have given us a task of creating a storage container and a file share and uploading files to both locations.

Action plan:

Step 1: Create a storage container . From the Azure portal home page, in the search box, enter storage accounts. Select storage accounts under services. Select the storage account you created in the Prepare environmental variables. The storage account name is the hyperlink to the storage account. (Note: it should be associated with the resource group guided-project-rg.). On the storage account blade, under the Data storage submenu, select Containers. Select + Add container. In the Name field, enter storage-container.Select Create.

Step 2 : Upload a file to the storage container. With a storage container created, we can now upload a blob to the container. Now, Locate a picture that you can upload, either on your computer or from the internet, and save it locally to make uploading easier. Select the storage container you just created. Select Upload and upload the file you prepared. Once the file is ready for upload, select Upload.
With the file uploaded, notice that the Access tier is displayed. For something we uploaded just for testing, it doesn’t need to be assigned to the Hot access tier. In the next few steps, we will change the access tier for the file.

Step 3 : Change the access tier. Select the file you just uploaded (the file name is a hyperlink). Select Change tier. Select Cold. Select Save. Select Home to return to the Azure portal home page. Good job! We have successfully uploaded a storage blob and changed the access tier from Hot to Cold. Next, we work with file shares.

Step 4 : Create a file share . From the Azure portal home page, in the search box, enter storage accounts . Select storage accounts under services. Select the storage account. The storage account name is the hyperlink to the storage account. (Note: it should be associated with the resource group guided-project-rg.). On the storage account blade , under the Data storage submenu, select File shares . Select + File share . On the Basics tab , in the name field enter ** file-share** . On the Backup tab, uncheck Enable backup . Select Review + create . Select ** Create** . Once the file share is created , select Upload . Upload ** the same file you uploaded to the blob storage or a different file, it’s up to you.Select Home to return to the Azure portal home page.

The next piece of the puzzle is figuring one way to control access to the files that have been uploaded. Azure has many ways to control files, including things like role-based access control. In this scenario, the Azure admin wants us to use shared access tokens or keys.

Step 5 : Create a shared access signature token. From the Azure portal home page, in the search box, enter storage accounts. Select storage accounts under services. Select the storage account we created in the Prepare exercise. On the storage account blade, select Storage browser. Expand Blob containers. Note: Blob container is another name for the storage containers. Items uploaded to a storage container are called blobs. Select the storage container we created earlier, storage-container. Select the ellipses (three dots) on the end of the line for the image you uploaded. Select Generate SAS. Note: When you generate a shared access signature, you set the duration. Once the duration is over, the link stops working. The Start automatically populates with the current date and time. Set the signing method to Account key. Set Signing key to Key 1. Set Stored access policy to None. Set Permissions to Read. Enter a custom start and expiry time or leave the defaults. Set Allowed protocols to HTTPS only. Select Generate SAS token and URI. Copy the Blob SAS URL and paste it in another window or tab of your browser. It should display the image you uploaded. Keep this tab or window open. Select Home to return to the Azure portal home page. With the SAS token created, anyone with that link can access the file for the duration that was set when you created the SAS token. However, controlling access to a resource or file is about more than just granting access. It’s also about being able to revoke access. To revoke access with a SAS token, you need to invalidate the token. You invalidate the token by rotating the key that was used.

Step 6 : Expand the Security + networking submenu. Select Access keys. For Key 1, select Rotate key. Read and then acknowledge the warning about regenerating the access key by selecting Yes. Once you see the success message for rotating the access key, go back to the window or tab you used to check the SAS token and refresh the page. You should receive an authentication failed error.

Phase 5: Pleased with our progress so far, the Azure admin hopes that we can wrap a few things up to help with monitoring and protecting resources. They want to know that someone can’t accidentally get rid of the virtual machine that’s running as an FTP server, and they want a quick way to see what department is using resources and the resource’s purpose.

Action plan:

Step 1: Adding tags to resources is a quick way to be able to group and organize resources. Tags can be added at different levels, giving us the ability to organize and group resources at a level that makes sense. Add tags to a virtual machine . We will start by adding a pair of tags to the virtual machine. One tag will be to identify the purpose of the virtual machine and the other will be to indicate the department the machine supports. From the Azure portal home page, in the search box, enter virtual machines. Select virtual machines under services. Select the guided-project-vm virtual machine. From the menu pane, select Tags. On one line for Name enter Department and for Value enter Customer Service. On the next line, for Name enter Purpose and for Value enter FTP Server. Select Apply.

Step 2: Add a resource lock to a VM. If necessary, expand the Settings submenu. Select Locks. Select + Add. For the name, enter VM-delete-lock. For the Lock type, select Delete.You may enter a note to help remind you why you created the lock. Select OK. That’s it. Now the VM is protected from deletion and has tags assigned to help track use. Time to move onto the network. Select Home to return to the Azure portal home page.

Step 3 : Add tags to network resources. From the Azure portal home page, in the search box, enter virtual networks. Select virtual networks under services. Select the guided-project-vnet network. From the menu pane, select Tags. For the Name select Department. For the Value enter IT. Select Apply. Now both the VNet and VM have are organized.

Phase 6: Remove delete locks. If you attempt to delete a resource with a delete lock, you’ll receive a warning that the operation failed due to a delete lock being in place. To avoid that, it’s important to clear delete locks from resources you intend to delete before issuing the delete command.

Action plan:

Step 1 : From the Azure portal home page, in the search box, enter
virtual machines . Select virtual machines under services. Select the guided-project-vm virtual machine . If necessary, expand the Settings submenu . Select Locks . Select Delete on the line for the VM-delete-lock . On the pop-up window , select Delete to confirm deletion of the lock. Once the delete lock is removed, we will be able to delete the VM . While this is the only delete lock required by the exercise, if you applied other delete locks during the exercise, remove them now. When you’re done, select Home to return to the Azure portal home page.

Step 2 : Delete the project resource group . A key benefit of using resource groups is the ability to rapidly delete all of the resources assigned to a resource group at once. From the Azure portal home page, in the search box, enter Resource groups . Select resource groups under services. Select the guided-project-rg resource group . Select Delete resource group. Select Apply ** force delete** . Enter ** guided-project-rg** in the confirmation box . Select Delete . On the Delete confirmation pop-up , select Delete. It will approximately 5 minutes before the resource group is fully deleted . We will need to refresh the resource group page every few minutes until the guided-project-rg is gone to confirm complete deletion. Important: Recall at the beginning of the Project we checked for a NetworkWatcherRG resource group. If there WAS a NetworkWatcherRG when you started , then you’re finished . However, if the NetworkWatcherRG was created for the guided project, we will need to delete the NetworkWatcherRG as well following a nearly identical process.

Congratulations – We have finished the Project and the clean up task is completed

Mission Accomplished !

Server/VM/Instance: Connecting to Azure from your local environment

Precious Uchechukwu Nwafor — Sat, 14 Mar 2026 08:05:09 +0000

Building in the cloud often feels like magic, until you hit your first Deployment Failed error. Whether it’s a regional quota limit or a firewall blocking your path, the journey from your local terminal to a live web server is rarely a straight line.

In this article, I am taking you behind the scenes of my latest lab. We will move past the common hurdles, like regional capacity limits: by pivoting our deployment strategy, mastering the Azure CLI to build a fresh infrastructure, and using SSH one-liners to transform a blank Ubuntu instance into a live Nginx web server.

If you have ever wondered how to bridge the gap between your laptop and a powerful Azure VM while navigating real-world troubleshooting, this guide is for you.

Let's get to it!

Phase 1: Install Azure CLI & Login. We will install the Azure CLI on your machine and authenticate to your Azure subscription.

Action plan:

STEP 1: When you start a project the first thing to do is create a new directory

Open Linux Server Visual Studio Code, go to File and navigate dropdown. Click on open folder.

STEP 2: Click on New folder to create a folder. Rename folder Linux server, select the linux folder and save. Everything Linux we are handling will be saved in the folder.

STEP 3: We will be using terminal most of the time. To get to terminal click on view and process to click on the terminal icon in the dropdown

STEP 4: We are going to install Azure Cli in our terminal window. Go to your Google browser and open a new tab. Type and search for Azure cli. Proceed to install application

STEP 5: Select Microsoft installer (MSI) with powershell and locate PowerShell (winget install --exact --id Microsoft.AzureCLI), Copy the command

STEP 6: Scroll down and copy the installation command.

STEP 7: Proceed to paste command in Terminal and click enter to run command. Verify version installed by typing az -- version and click enter.

STEP 8: Once confirmation report is retrieved, proceed to login. Type

az login and click enter. Select account you want to login with.

STEP 9: Confirm your Azure subscription. I have just one active subsrcription, so I will write 1 and click enter

Phase 2: Create a Resource Group. This resource group is to act as the logical container for your entire lab environment.

Action plan:

STEP 1: We will proceed to set Environment variables. This environment variable is like a labeled box that holds a specific piece of information. Instead of your code needing to know exactly what is inside the box, it simply calls out the label on the box (the variable name). The system then opens the box and provides whatever value is currently kept inside. We will proceed to run the commands below in the terminal to condition our environment variable .

RG="azurecli-lab-rg : This sets the shell variable RG so later commands can reference it with $RG.
LOCATION="eastus" : Sets the shell variable LOCATION so later commands can reference it with $LOCATION.
az group create --name $RG --location $LOCATION : Creates a resource group called "$RG" — a logical container for all the Azure resources in this lab.
az group show --name $RG : Runs the Azure CLI command "az group show" — see "az group show --help" for details.

Phase 3: We will build a Virtual Network (VNet) & Subnet. Creating a secure private network for your Azure resources to communicate on.

Action plan:

Step 1 : Run this command in the terminal: az network vnet create --address-prefix 10.0.0.0/16 --resource-group $RG --name lab-vnet --location $LOCATION . This creates a Virtual Network (VNet) — the private network your Azure resources communicate on.

Step 2 : Create a Subnet. This carves out a smaller 10.0.1.0/24 piece (subnet) of the VNet specifically for your VMs. Segmenting networks allows you to apply different routing and firewall rules to different types of resources. We will proceed to run this command in the terminal: az network vnet subnet create --resource-group $RG --vnet-name lab-vnet --name lab-subnet --address-prefix 10.0.1.0/24. Check your Microsoft Azure portal to confirm creation of the lab-vnet

Step 3 : Create a Network Security Group (NSG), which acts as a virtual firewall. Without an NSG attached, Microsoft allows no inbound traffic but allows all outbound traffic. We need an NSG to poke specific holes in the firewall. We will proceed to run this command in the terminal: az network nsg create --resource-group $RG --name lab-nsg

Step 4 : Open port 22 (SSH) & 80 (HTTP). This adds inbound rules prioritizing SSH (port 22) and HTTP (port 80) access from the internet. We will need SSH to log in and configure the server, and HTTP so users can view the web page. Let us proceed to run this command in the terminal: az network nsg rule create --resource-group $RG --nsg-name lab-nsg --name AllowHTTP --priority 1010 --destination-port-ranges 80 --access Allow --protocol Tcp --direction Inbound

Step 5: Attach NSG to Subnet. Enforces the firewall rules (NSG) at the subnet boundary. Applying the NSG to the subnet ensures that any VM created in that subnet automatically inherits those exact firewall rules — protecting the entire subnet. Let us proceed to run this command in the terminal: az network vnet subnet update --resource-group $RG --vnet-name lab-vnet --name lab-subnet --network-security-group lab-nsg. You can run your code in a straight line or use the backtick (located under the Esc key) at the end of every line except the last one. Like this **az network vnet subnet update
--resource-group $RG
--vnet-name lab-vnet
--name lab-subnet
--network-security-group lab-nsg

Note: If you encounter errors, run the command again and ensure it is entered correctly.

Phase 4: We will provision a Linux Virtual Machine. Creating an Ubuntu VM with a public IP inside our VNet.

Action plan:

Step 1 : Allocate a Public IP. This allocates a static public IP address in Azure. Without a public IP, the VM can only be accessed internally through the VNet or a VPN. You need this to reach your web server from your browser. Run this command in the terminal: az network public-ip create --resource-group $RG --name lab-public-ip --allocation-method Static --sku Basic

From the error above, essentially, Azure is telling us that for our specific subscription and region, the limit for Basic SKU Public IPs is currently set to zero. Additionally, Microsoft is phasing out the Basic SKU in favor of the Standard SKU for better security and performance.
The Fix
To bypass this error, we will need to change the --sku to Standard. In Azure, a Standard SKU Public IP must also use the Static allocation method (it does not support Dynamic).
Run this command instead: az network public-ip create --resource-group $RG --name lab-public-ip --allocation-method Static --sku Standard

az network public-ip create
--resource-group $RG
--name lab-public-ip
--allocation-method Static
--sku Standard

Step 2 :Create the VM. This creates a B1s Ubuntu VM with auto-generated SSH keys and connects it to the existing subnet and firewall. This is the actual cloud compute instance that will run our web application code. Run this command: az vm create --resource-group azurecli-lab-rg --name lab-vm --image Ubuntu2204 --size Standard_B2s_v2 --location koreacentral --admin-username azureuser --generate-ssh-keys --vnet-name lab-vnet --subnet lab-subnet --public-ip-address lab-public-ip --nsg lab-nsg

Note: When I first tried to deploy my VM in East US, I received a red wall of text:
The requested VM size 'Standard_B1s' is currently not available in location 'East US' for this subscription.

What happened?

Cloud regions are essentially giant parking lots. Sometimes, the compact car spots (like the B1s or B2s sizes) are completely full in a specific region.

The Fix: We will pivot to Korea Central (koreacentral), a region that has plenty of space for my VM size.

Run this command in the terminal:

$RG="azurecli-lab-rg" - Set the Variable
az network nsg create --resource-group $RG --name lab1-nsg --location koreacentral - To create the Security Group
az network vnet create --resource-group $RG --name lab1-vnet --location koreacentral --subnet-name lab1-subnet- Create the Virtual Network.
az vm create --resource-group $RG --name lab1-vm --image Ubuntu2204 --size Standard_B2s_v2 --location koreacentral --admin-username azureuser --generate-ssh-keys --vnet-name lab1-vnet --subnet lab1-subnet --public-ip-address lab1-public-ip --nsg lab1-nsg - The Final Deployment.

Step 3 : Retrieve the public IP. Filters the Azure API response to return just the IP address string. We will need this IP to SSH into the machine and to test the web application. Run this command in the terminal: az network public-ip show --resource-group $RG --name lab1-public-ip --query ipAddress --output tsv

Step 4 : Verify the VM is running. This queries the VM status and displays it in a clean table format. Always verify provisioning success before attempting connections. Run this command in the terminal: az vm show --resource-group $RG --name lab1-vm --show-details --query '{Name:name, State:powerState, IP:publicIps}' --output table

Step 5 : SSH into your VM & install Nginx. Logs into the VM over the internet via SSH, installs the Nginx package using APT, and starts the service. A fresh VM is blank. Nginx serves as the web server to test our HTTP port 80 firewall rule. Run this command in the terminal:
ssh -i ~/.ssh/id_rsa azureuser@
sudo apt update && sudo apt install nginx -y
sudo systemctl enable nginx && sudo systemctl start nginx

The Connection timed out error in our latest screenshot indicates that while our VM is running, our terminal cannot reach it over port 22. This is almost certainly because the Network Security Group (NSG) for our new lab1 infrastructure does not yet have a rule allowing SSH traffic.
Think of the NSG as a locked door; even if the server is "home," you can't get in unless you specifically authorize the port.

The Fix: Open Port 22
Run this command to tell Azure to allow SSH connections into our lab1-nsg; az network nsg rule create --resource-group $RG --nsg-name lab1-nsg --name AllowSSH --priority 1000 --destination-port-ranges 22 --access Allow --protocol Tcp --direction Inbound

We will now SSH into our VM to remotely install and configure Nginx. Run this command: ssh -i ~/.ssh/id_rsa azureuser@20.214.200.240 "sudo apt update && sudo apt install nginx -y && sudo systemctl start nginx"

Conclusion: Since our terminal shows the installation is done, let's head over to Chrome to do a final verification. First we have to allow access
by running this final command in the terminal: az network nsg rule create --resource-group $RG --nsg-name lab1-nsg --name AllowHTTP --priority 1010 --destination-port-ranges 80 --access Allow --protocol Tcp --direction Inbound

Proceed to Open Chrome. Paste the IP address: http://20.214.200.240. The Result: You should see a white page with bold text saying "Welcome to nginx!".

MISSION ACCOMPLISHED!

Provide Storage for a New Company App

Precious Uchechukwu Nwafor — Fri, 27 Feb 2026 08:27:39 +0000

A company is designing and developing a new app and the developers need to ensure the storage is only accessed using keys and managed identities. The developers should use role-based access control. To help with testing, protected immutable storage is also needed.

To power the new application, we aren't just going to build a storage, we are building a fortress. This configuration ensures our developers can build and test with total confidence by leveraging three pillars of cloud security:

Identity over Passwords: We will use Managed Identities and Access Keys to eliminate hard-coded credentials, ensuring the app authenticates directly and securely.
Precision Control: We are going to use Role-Based Access Control (RBAC), and grant granular permissions to team members, ensuring everyone has exactly the access they need for testing; no more, no less.
Data Permanence: We will implement Immutable Storage, locking critical data in a 'write-once, read-many' state that protects against accidental deletion or modification during the development lifecycle. This isn't just a storage account; it’s a compliant, hacker-resistant environment designed for high-stakes application development.

Let's get to it !.

PHASE 1: Create a storage account for the managed identity

Action plan

1. Provide a storage account for the web app. In the Azure portal, search for and select Storage accounts. Select + Create. For Resource group select Create new. Give your resource group a name and select OK to save your changes. Provide a Storage account name. Ensure the name is unique and meets the naming requirements. 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.

PHASE 2 : Provide a managed identity for the web app to use.

Action plan

1 . 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.

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

Action plan

1 . Search for and select your storage account.Select the Access Control (IAM) blade.Select Add role assignment. 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. Once this is configured, our storage account can now be accessed by a managed identity with the Storage Data Blob Reader permissions.

PHASE 4 : Secure access to the storage account with a key vault and key.

Action plan

1 : In the portal, search for and select Resource groups. Select your resource group, and then the Access Control (IAM) blade. Select Add role assignment. 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.

PHASE 5 : Create a key vault to store the access keys

Action plan

1 : In the Azure portal, search for and select Key vaults. 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.

2. Create a customer-managed key in the key vault. 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.

PHASE 6 : 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.

Action plan

1 : In the portal, search for and select Resource groups. 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. 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.

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

Action plan

1 : 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. 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.

PHASE 8 : Configure a time-based retention policy and an encryption scope

Action plan

1 : The developers require a storage container where files can’t be modified, even by the administrator. So we will navigate to our 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. 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.

PHASE 9 : The developers require an encryption scope that enables infrastructure encryption.

Action plan

1 : 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.

Conclusion : Hooray, the mission is a success!. Our storage fortress is ready for the new app. By enforcing access via keys and managed identities, implementing RBAC for precise testing, and locking down protected immutable storage, we have built a resilient environment where data is both accessible to developers and safe from deletion.

Provide shared file storage for the company offices

Precious Uchechukwu Nwafor — Wed, 25 Feb 2026 22:09:11 +0000

In a world where teams are geographically dispersed but need to stay perfectly in sync, local hardware just doesn't cut it anymore. Welcome to your roadmap for building a rock-solid Azure Files infrastructure; designed for high-speed collaboration, protected by instant snapshots, and locked down behind a private virtual network.

Today, we will be working with a company that is geographically dispersed with offices in different locations. The offices need a way to share files and disseminate information. For example, the Finance department needs to confirm cost information for auditing and compliance. These files should be easy to access and load without delay. Some content should only be accessed from selected corporate virtual networks.

Let's get to it!

PHASE 1: Create a storage account for the finance department’s shared files

Action plan

1 : In the Azure portal, search for and select Storage accounts.

2 : Select + Create.

3 : For Resource group, select Create new. Give your resource group a name and select OK to save your changes. Proceed to provide a Storage account name. Set the Performance to Premium. Set the Premium account type to File shares. Set the Redundancy to Zone-redundant storage. Select Review + Create.

4 : Select Create.

5 : Wait for the resource to deploy. Select Go to resource.

PHASE 2: Create and configure a file share with directory.

Action plan

1 : Create a file share for the corporate office. In the storage account, in the Data storage section, select the File shares blade.Select + File share

2 : Proceed to provide a Name. Review the other options, but take the defaults. Select Review + Create. Select Create

3 : We will add a directory to the file share for the finance department. Select your file share and select +Add directory.
Name the new directory finance.

4 : 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.

PHASE 3: Configure and test snapshots. This is similar to blob storage, you need to protect against accidental deletion of files. We decide to use snapshots.

Action plan

1 : Select your file share. In the Operations section, select the Snapshots blade. Select + Add snapshot.

2: The comment is optional. Select OK.

3 : Select your snapshot and verify your file directory and uploaded file are included. In the Properties pane select Delete. Select Yes to confirm the deletion.

4 : Practice using snapshots to restore a file. Return to your file share. Browse to your file directory. Locate your uploaded file.

5 : Select the Snapshots blade and then select your snapshot. Navigate to the file you want to restore. Select the file and then select Restore. Provide a Restored file name. Verify your file directory has the restored file.

PHASE 4: Configure restricting storage access to selected virtual networks. This task in this section require a virtual network with subnet.

Action plan

1 : 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.

2 : The storage account should only be accessed from the virtual network we 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.

Conclusion : By completing this tutorial, we have successfully established a high-performance, enterprise-grade storage environment specifically engineered for secure corporate data sharing. We began by deploying a premium, zone-redundant storage account and organizing it with dedicated file shares and directories to ensure the finance department's auditing data remains easily accessible yet highly structured. To safeguard against data loss, we implemented a snapshot strategy and verified that files can be restored instantly, providing a vital safety net against accidental deletions. Finally, we hardened the entire infrastructure by restricting access exclusively to our authorized virtual network, ensuring the company's information is protected from unauthorized external connections.

MISSION ACCOMPLISHED!

Steps to Launch an EC2 Instance in AWS

Precious Uchechukwu Nwafor — Sat, 21 Feb 2026 08:45:34 +0000

Cloud infrastructure can feel abstract until you launch your first server.

In the world of cloud computing, servers aren’t racks of hardware sitting in a data center. They are on-demand, scalable, and provisioned in minutes.

On Amazon Web Services (AWS), this compute capability is delivered through Amazon Elastic Compute Cloud (EC2). Which is a service that lets you spin up virtual servers whenever you need them. If you are coming from Microsoft Azure, you will recognize this concept as a Virtual Machine. Different name, same fundamental idea: rentable compute power in the cloud.

In this guide, we will walk step-by-step through creating your own EC2 instance from configuration to launch.

Let’s build our EC2 instance. 🚀

STEP 1 : Create or login AWS Management Console account.

STEP 2 : Proceed to navigate to the Search bar icon above. Type EC2 and click enter. This opens the EC2 dashboard.

STEP 3 : Select Launch Instance on the dashboard

STEP 4 : Add a name tag and choose your operating system .

STEP 5 : Proceed to create a new key pair (optional). Give a unique name and create new key. This automatically downloads as a file

STEP 6 : Proceed to Launch instance.

STEP 7 : We have created the EC2. Proceed to connect to your instance

STEP 8 : We will use the cloud share that Amazon is providing and connect directly. Click connect

STEP 9: Wait for connection to be established. Congratulations, we have created our Ubuntu 24.04.3 LTS (GNU/Linux 6.14.0-1018-aws x86_64)

STEP 10: The EC2 connected and ready for use.

We can go further by entering the command sudo su at the prompt and press Enter to gain administrative access. Next, type sudo apt update and press Enter again. This will refresh your package lists and display the current status of your applications on the EC2 instance.

Note: If the terminal becomes unresponsive, first click directly inside the black window to ensure it has "focus." If it still won't record your commands, refresh your browser to reset the session. This can be due to lost focus or connection time out

MISSION SUCCESSFUL!

Creating a Windows Virtual Machine (VM) in Azure

Precious Uchechukwu Nwafor — Sat, 21 Feb 2026 02:33:12 +0000

Have you ever wished for a Undo button for your entire computer?

Imagine a high-stakes flight simulator. You have all the controls, all the power, and all the thrill of the sky, but if you crash, you don't fall. You just hit Restart and try again.

That is the magic of a Virtual Machine (VM). In the world of Cloud Engineering, we don’t let physical hardware limit our imagination. We turn heavy metal servers into fluid and digital sandboxes . Whether you want to test a dangerous virus, learn a new OS, or build the next big app, the VM is your playground.

Grab your digital hard hat and let's build a computer out of thin air.

STEP 1 : In the Azure portal, search for and select Virtual Machines.

STEP 2 : Select Virtual Machines.

STEP 3 : Go to Basic tab. Under Subscription & Resource Group: Select your subscription and create or choose a resource group.

VM Name: Enter a name for your VM.
Region: Pick an Azure region of your choice.
Availability Options: No infrastructure redundancy required for high availability and to lower cost.
Security: Select standard
Image: Confirm the Windows OS image.
Size: Select the VM size (CPU, RAM) based on your workload. This determines your VMs pricing on an hourly bases.

STEP 4 : Set an Administrator Account
Create a username and password for logging into the VM. Configure virtual network, subnet, and public IP. Use Http (80), RDP (Port 3389) to connect remotely. Confirm licensing option

STEP 5 : Configure Monitoring tab. Disable - Boot diagnostics to ensure privacy. Review and create

STEP 6 : Validation passed. Proceed to Create

STEP 7 : Deployment Complete. Go to resource

STEP 8 : Connect VM and download RDP file.

STEP 9 : Open and login to the downloaded RDP folder with your credentials.

STEP 10 : Verify credentials and connect

STEP 11 : Install and Run VM. Test application by downloading Screenpresso using Microsoft Edge

STEP 12 : Install and Run Screenpresso in VM.

MISSION ACCOMPLISHED!

Provide private storage for internal company documents

Precious Uchechukwu Nwafor — Fri, 20 Feb 2026 10:31:57 +0000

A company needs storage for their offices and departments. This content is private to the company and shouldn't be shared without consent. This storage requires high availability if there is a regional outage. The company wants to use this storage to back up the public website storage.

Let's get to it!

Phase 1: Create a storage account and configure high availability.

Action plan:

1 . In the portal, search for and select Storage accounts.

2 . Select + Create.

3 . Select the Resource group created in the previous lab - "sapublic". Set the Storage account name to private. Add an identifier to the name to ensure the name is unique. Select Review, and then Create the storage account.

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

5 . This storage requires high availability if there is a regional outage. Read access in the secondary region is not required. We have to configure the appropriate level of redundancy. To this, in the storage account, in the Data management section, select the Redundancy blade. Ensure Geo-redundant storage (GRS) is selected. Refresh the page. Review the primary and secondary location information. Save your changes.

Phase 2: Create a storage container, upload a file, and restrict access to the file.

Action plan:

Create a private storage container for the corporate data. 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). As you have time, review the Advanced settings, but take the defaults. Select Create.

2 . For testing, we will 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 publicly accessible. To do this, Select the container. Select Upload. Browse to files and select a file. Upload the file.

3 . 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.

Phase 3: 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).

Action plan:

1 . Select your uploaded blob file and move to the Generate SAS tab.

2 . 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. Select Generate SAS token and URL.

3 . 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. Other file types will be downloaded.

Phase 4: Configure storage access tiers and content replication. To save on costs, after 30 days, move blobs from the hot tier to the cool tier.

Action plan:

1 . Return to the storage account **. In the **Overview section, notice the Default access tier is set to Hot.

2 . In the Data management section, select the Lifecycle management blade. Select Add rule.

3 . Set the Rule name to movetocool. Set the Rule scope to Apply rule to all blobs in the storage account. Select Next.

4 . Ensure Last modified is selected. Set More than (days ago) to 30. In the Then drop-down select Move to cool storage. As you have time, review other lifecycle options in the drop-down.Add the rule.

Phase 5: The public website files need to be backed up to another storage account.

Action plan:

1 . In your storage account, create a new container called backup. Use the default values.

2 . Navigate to your publicwebsite storage account. This storage account was created in the previous exercise. In the Data management section, select the Object replication blade. Select Create replication rules.

3 . Set the Destination storage account to the private storage account.
Set the Source container to public and the Destination container to backup. Create the replication rule.

4 . Optionally, as you have time, upload a file to the public container. Return to the private storage account and refresh the backup container. Within a few minutes your public website file will appear in the backup folder.

Mission Accomplished!

Storage for a public website

Precious Uchechukwu Nwafor — Thu, 19 Feb 2026 21:12:53 +0000

Think of storage as a digital warehouse.

Just like a physical warehouse stores boxes safely so they can be retrieved later, digital storage keeps files and data safe so they can be accessed whenever needed.

When you upload a photo, a document, a video, or even a database record, that information needs a place to live.

That place is called storage.

Let's get to it!

Phase 1 - Create a storage account to support the public website.

The Action Plan :

1 . In the portal, search for and select Storage accounts.

2 . Select + Create.

3 . For resource group, select new . Give your resource group a name and select OK. Select Review and then Create

4 . Set the Storage account name to publicwebsite. Make sure the storage account name is unique by adding an identifier. Take the defaults for other settings.

5 . Select Create.

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

7 . This storage requires high availability if there’s a regional outage. Additionally, we will enable read access to the secondary region. In the storage account, in the Data management section, select the Redundancy blade. Ensure Read-access Geo-redundant storage is selected. Review the primary and secondary location information.

8 . Information on the public website should be accessible without requiring customers to login. So in the Settings section, select the Configuration blade. Ensuring the Allow blob anonymous access setting is Enabled and Save changes.

Phase 2 - Create a blob storage container with anonymous read access.

The Action Plan :

1 . In your storage account, in the Data storage section, select the Containers blade. Select + Container. Ensure the Name of the container is public. Select Create.

2 . Customers should be able to view the images without being authenticated. Configure anonymous read access for the public container blobs. Select your public container. On the Overview blade, select Change access level. Ensure the Public access level is Blob (anonymous read access for blobs only). Select OK.

Phase 3 - For testing, upload a file to the public container. The type of file doesn’t matter. A small image or text file is a good choice.

The Action Plan :

1 . Ensure you are viewing your container.
Select Upload. Browse to files and select a file. Browse to a file of your choice. Select Upload. Close the upload window, Refresh the page and ensure your file was uploaded.

2 . Determine the URL for your uploaded file. Open a browser and test the URL. Select your uploaded file. On the Overview tab, copy the URL. Paste the URL into a new browser tab. If you have uploaded an image file it will display in the browser. Other file types should be downloaded.

Phase 4 - It’s important that the website documents can be restored if they are deleted. We will proceed to Configure blob soft delete for 21 days.

The Action Plan :

1 . Go to the Overview blade of the storage account. On the Properties page, locate the Blob service section. Select the Blob soft delete setting.

2 . Ensure the Enable soft delete for blobs is checked. Change the Keep deleted blobs for (in days) setting to 21. Notice you can also Enable soft delete for containers. Save your changes.

3 . If something gets deleted, you need to practice using soft delete to restore the files. Navigate to your container where you uploaded a file. Select the file you uploaded and then select Delete.

4 . Select OK to confirm deleting the file.

5 . On the container Overview page, toggle the slider Show deleted blobs. This toggle is to the right of the search box. Select your deleted file, and use the ellipses on the far right, to Undelete the file.

Refresh the container and confirm the file has been restored.

Phase 5 - Configure blob versioning. It’s important to keep track of the different website product document versions.

The Action Plan :

1 . Go to the Overview blade of the storage account. In the Properties section, locate the Blob service section. Select the Versioning setting.

2 . Ensure the Enable versioning for blobs checkbox is checked. Notice your options to keep all versions or delete versions after. Don’t forget to Save your changes.

3 . As you have time experiment with restoring previous blob versions. Upload another version of your container file. This overwrites your existing file. Your previous file version is listed on Show deleted blobs page.

MISSION COMPLETE!

Deploying a Secure Resource Group and Storage Account

Precious Uchechukwu Nwafor — Fri, 13 Feb 2026 16:05:00 +0000

Let’s be honest: the first time you log into the Azure Portal, it looks like a giant wall of buttons and confusing menus. If you are a Cloud Engineer just starting out, the pressure to "get it right" is real, especially when it comes to keeping data safe.

Think of your Azure project like building a new house. Before you bring in the furniture, you need two things:

A Resource Group: This is like the land your house sits on. It keeps all your materials in one place so they don't get lost.
A Storage Account: This is your digital vault. It’s where you keep your most important files.

Though we aren't just going to click "Next" and hope for the best. We are going to "harden" our vault using the specific settings required for a secure setup:

Secure Transfer: We will make sure every request to our data is encrypted and safe.
TLS 1.2: This is the modern "secret code" that protects your data while it travels.  
Disabling Key Access: We'll turn off the "master keys" when they aren't needed to keep the vault extra tight.

No confusing jargon, just a clear, step-by-step path to building your first secure foundation in the cloud. Let’s dive in!

`Phase 1: Setting up the "Land" (Creating Your Resource Group)`

Every project in Azure needs a home. As a Cloud Engineer, your first task is to create a Resource Group. Think of this as a logical container, if you delete the group, everything inside it is cleaned up, which makes managing your project a breeze.

The Action Plan:

1 . In the Azure portal, search for and select Resource groups.

"Accessing the Resource Groups Blade to initialize the provisioning process"

2 . Select + Create.

"Opening the configuration blade and begins provisioning the resource group"

3 . Give your resource group a name example, storagerg and select a region which will be used region throughout the project.

"Defining the Resource Group name and selecting a Region to establish the geographical and logical foundation for our deployment"

4 . Select Review and create to validate the resource group.

" Running the final validation to ensure our configuration is sound before clicking Create to execute the deployment"

5 . Select Create to deploy the resource group.

"Initiating deployment process to finalize the creation of our logical container within the Azure environment"

`Phase 2: Provisioning the Secure Storage Account`

With our Resource Group successfully deployed, we have established the "logical house" for our project. Now, we will deploy the Storage Account—the vault where our data will live, ensuring we apply engineering best practices for performance and security from the very first click.

Action Plan :

1 . In the Azure portal, search for and select Storage accounts.

"Navigating to the storage accounts hub to begin the deployment of our core data infrastructure."

2 . Select + Create.

_"Selecting + Create to initialize the deployment workflow and open the storage configuration blade" _

3 . Provide a 'Storage account name'. The storage account name must be unique in Azure. Also set performance to 'standard'. Proceed to 'Review and Create'

"Defining the core parameters for our storage infrastructure, linking it to our existing resource group and selecting the standard performance tier before proceeding for final review and create"

4 . Select Create.

"Executing final deployment to provision of our storage infrastructure within the defined resource group"

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

"Deployment successful. Selecting Go to Resource for the new storage account"

`Phase 3: Configure simple settings in the storage account.`

Now that our storage account is live, we need to move beyond default settings. In a real-world scenario, "defaults" are rarely enough. In this phase, we will navigate the Management Blade to adjust redundancy and enforce security protocols, ensuring our data is stored efficiently and securely.

Action Plan :

1 . The data in this storage account doesn’t require high availability or durability. A lowest cost storage solution is desired.

In your storage account, in the Data management section, select the Redundancy blade.
Select Locally-redundant storage (LRS) in the Redundancy drop-down.
Be sure to Save your changes.
Refresh the page and notice the content only exists in the primary location.

"Optimizing redundancy level to LRS and committing the changes; the refresh feature ensures the management plane reflects the updated configuration immediately"

2 . The storage account should only accept requests from secure connections. Developers would like the storage account to use at least TLS version 1.2.

In the Settings section, select the Configuration blade.
Ensure Secure transfer required is Enabled.
Ensure the Minimal TLS version is set to Version 1.2.

"Enforcing data in transit security by requiring encrypted connections and setting TLS 1.2 protocol as the minimum standard for all incoming request"

3 . Until the storage is needed again, disable requests to the storage account.

In the Settings section, select the Configuration blade.
Ensure Allow storage account key access is Disabled.
Be sure to Save your changes.

"Disabling shared key access to shift toward a more secured, identity driven authentication model (RBAC), effectively mitigating the risk of leaked account keys"

4 . Ensure the storage account allows public access from all networks.

In the Security + networking section, select the Networking blade.
Ensure Public network access is set to Enabled from all networks.
Be sure to Save your changes.

"Configuring the Networking firewall to allow public access, ensuring the storage account is reachable from all external networks as required for this deployment's connectivity requirements."

`Mission Accomplished`

Deploying a storage account in Azure is a fundamental skill, but hardening it is what separates a beginner from a professional. Through this lab, we successfully established a secure foundation by first creating a dedicated Resource Group, then provisioning a Standard Storage Account with optimized LRS redundancy. By moving beyond default settings to enforce TLS 1.2, disabling Shared Key access, and configuring the Networking firewall, we have transformed a basic resource into a hardened, production-ready environment built with a security-first mindset.

Demystifying the Cloud: A Guide to the Core Pillars of Modern Infrastructure

Precious Uchechukwu Nwafor — Sat, 07 Feb 2026 09:06:08 +0000

Most people think of "The Cloud" as just someone else's computer, but it is actually a brilliant system designed to keep the world's apps running smoothly. To understand how modern software stays fast, safe, and available to everyone, we just need to look at a few core building blocks that work together:

It begins with Virtualization, the foundational magic that treats hardware like flexible software.
This flexibility gives developers the Agility to innovate at lightning speed and the Scalability to handle millions of users.
To ensure the app never goes down, we design for High Availability and Fault Tolerance, creating a "safety net" that survives hardware failures.
Finally, we push these apps to a Global Reach, while using Elasticity to ensure we only pay for exactly what we use.

Individually, these are just concepts; together, they are the blueprint for modern engineering.

Let’s dive deep into each pillar to see how they work under the hood.

1 . Virtualization 🖥️ ➡️ [ 💻 💻 💻 ]: The Foundation

Virtualization is the process of creating a software-based (virtual) representation of something, such as virtual applications, servers, storage, and networks. The "So What?": It allows one physical server to act like many, which reduces costs and waste.

The Link: Once we have virtualized our resources, we gain the ability to grow them. This leads us to our next pillar: Scalability.

2 . Scalability 🧱 ➡️ 🧱🧱🧱: Thinking Big

Scalability is the ability of a system to handle increased load by adding resources.
Vertical Scaling: Adding more power (CPU/RAM) to an existing server.
Horizontal Scaling: Adding more servers to your pool.

The Link: While scaling handles size, our next concept —Agility— is all about speed.

3 . Agility 🐌 ➡️ 🚀: The Need for Speed

In the cloud, Agility refers to the ability to rapidly develop, test, and launch software applications. The "So What?": Because you don't have to wait weeks for physical hardware to arrive, you can experiment and pivot your business in minutes.

The Link: Moving fast is great, but your app is useless if it crashes. That’s where High Availability comes in.

4 . High Availability (HA) 🚦 ➡️ 🟢: Always On

HA is a system design that ensures a pre-arranged level of operational performance (usually uptime) for a long period. The "So What?": It ensures that if one part of your system fails, another part is ready to take over immediately so the user never notices.

The Link: While High Availability focuses on minimizing downtime—meaning your app might go "blink" for a few seconds during a switch—our next concept, Fault Tolerance, takes this a step further by ensuring the user never feels a "blink" at all.

5 . Fault Tolerance ✈️ ➡️ ✈️: The Safety Net

This is the ability of a system to continue operating without interruption, even if one or more components fail completely. The Difference: While HA aims for "uptime," Fault Tolerance aims for "zero downtime and zero data loss" by having identical systems running in sync.

The Link _ : _To ensure this level of safety for everyone, we must expand our footprint globally.

6 . Global Reach 📍 ➡️ 🌎: No Borders

The ability to deploy your app in data centers located all over the world. The "So What?": This reduces latency (lag) for users. A user in Tokyo shouldn't have to wait for a server in New York to respond.

The Link: Expanding globally requires more than just servers; it requires a system that can grow and shrink automatically to handle the world's traffic. This brings us to our final and most important distinction: the difference between Scalability and Elasticity.

7 . The Great Debate 🎈: Scalability vs. Elasticity

While these two terms are often used interchangeably, they solve two different problems. Here is the easiest way to remember the difference:

Scalability (The Capacity)

What it is: The ability of your system to handle a growing amount of work.
The Action: You manually or strategically add resources (like adding more floors to a building) to handle long-term growth.
Best for: Planned events, like a permanent increase in users or a scheduled holiday sale.

Elasticity (The Automation)

What it is: The ability of your system to automatically grow and shrink based on real-time demand.
The Action: Like a rubber band, the system stretches when traffic spikes and snaps back when the crowd leaves to save you money.
Best for: Unpredictable traffic, like a tweet going viral or a sudden flash flood of users.

The Golden Rule 💡: You can have a Scalable system that isn't Elastic (meaning you can grow, but you have to do it manually), but you cannot have a truly Elastic system that isn't already Scalable.
Think of it this way : Scalability is the capability to grow; Elasticity is the automation that makes that growth happen exactly when needed.

In conclusion, mastering these seven concepts is about more than just passing an exam or memorizing definitions; it’s about learning to think like a Cloud Engineer.

In the real world, you won’t always need every one of these pillars at the same time. Some projects will prioritize Agility to get a product to market fast, while others like banking or healthcare apps will focus almost entirely on Fault Tolerance and High Availability.

The "magic" of the cloud isn't just that these tools exist, but that you now have the power to choose the right ones for the job.