Segment an Azure Network with NSGs

Introduction

30 Second Summary

Think about how an office building has different floors for different departments, with security checkpoints controlling who can access each area. Cloud networks work the same way.

In this project, you will build a segmented network in Azure with multiple subnets and security rules that control exactly which traffic flows between them.

What You'll Build

A production-style segmented network with two subnets (web tier and data tier), each protected by its own Network Security Group with custom rules, and a Linux VM deployed to prove the rules work.

By the end of this project, you'll have:

• A Virtual Network with two isolated subnets (web tier and data tier) using proper CIDR addressing.
• Two Network Security Groups with custom inbound and outbound rules controlling traffic to each subnet.
• A Linux VM deployed into the web subnet, verified as reachable only on permitted ports.
• Secret Mission: Add VNet peering between two virtual networks and verify cross-network connectivity.

Are there any prerequisites?

You need a macOS computer and a Microsoft account. If you already use Microsoft 365 for work or school, that account will work perfectly.

No prior Azure experience is required. This guide walks you through setting up your free Azure account and installing all the tools you need.

Set Up Azure Account and CLI

Every cloud network starts with two things: an account to provision resources in, and a command-line tool to manage them efficiently.

In this step, you will create an Azure free account, install the Azure CLI on your Mac, and create a resource group to hold everything you build in this project.

In this step, get ready to:

• Sign up for an Azure free account and install Azure CLI.
• Create a resource group for the project.
• Set CLI defaults to streamline future commands.

Sign up for Azure and install the CLI

Azure offers a free account with $200 credit for 30 days, plus 750 free hours per month of a B1s virtual machine for 12 months. This is more than enough for this project.

• Open https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account in your browser.
• Click Try Azure for free.
• Sign in with your Microsoft account.
• Complete the signup process. You will need a phone number and a credit or debit card (non-prepaid) for identity verification.

Will I be charged?

No. Azure gives new accounts $200 in free credit for the first 30 days. The B1s VM you deploy later is also covered by 750 free hours per month for 12 months. You will not be charged for this project as long as you clean up resources afterwards.

Now install the Azure CLI so you can manage Azure resources from your terminal.

• Press Cmd+Space to open Spotlight, type Terminal, and press Enter to open it.
• Install Azure CLI via Homebrew by running this command:

brew update && brew install azure-cli

What does this command do?

This runs two commands in sequence. brew update refreshes Homebrew's package list so it knows about the latest versions. brew install azure-cli downloads and installs the Azure CLI tool on your machine.

• Verify the installation by running:

az version

You should see version information printed in your terminal, including a line showing the Azure CLI version number.

✔️ I see a version number

Azure CLI is installed and ready. Move on to the next step below.

ⓧ Command not found

If your terminal says the az command is not found, Homebrew may not be installed.

• Check if Homebrew is installed by running:

brew --version

If this also returns command not found, install Homebrew first by visiting https://brew.sh and following the install instructions. Then re-run the Azure CLI install command above.

Now sign in to Azure from your terminal.

• Sign in to your Azure account by running:

az login

What happens when you run this?

Azure CLI opens your default web browser to an Azure sign-in page. Sign in with the same Microsoft account you used to create your free account.

After you authenticate in the browser, the CLI receives your credentials and completes the login in your terminal. You will see JSON output listing your subscriptions.

Browser not opening?

If the browser does not open automatically, look for a URL and a code printed in your terminal. Open that URL in any browser and enter the code to complete sign-in.

You can also force this device-code flow by running az login --use-device-code instead.

help me sign in to Azure CLI

Create the project resource group

A resource group is a container that holds all the Azure resources for a project. Everything you build in this project will live inside one resource group, making it easy to manage and delete later.

• Create your resource group by running:

az group create --name rg-network-lab --location uksouth

What does this command do?

This creates a new resource group called rg-network-lab in the uksouth Azure region. All the networking resources you build later (virtual networks, security groups, VMs) will be placed in this group.

You should see JSON output with a provisioningState of Succeeded confirming the group was created.

• Verify the resource group exists by running:

az group show --name rg-network-lab

You should see a JSON object showing the name, location, and properties of your new resource group.

Seeing an authorization error?

Make sure you completed the az login step successfully. Run az login again if needed to refresh your session.

If you see a subscription-related error, your free account may not have activated yet. Wait a few minutes and try again.

help me fix my resource group creation error

Confirm your subscription and set defaults

Before continuing, confirm that the CLI is using the correct subscription. Then set default values so you do not have to type the resource group and location on every command.

• Confirm your active subscription by running:

az account show

You should see JSON output containing your subscription name and ID. Confirm it shows your Azure free account subscription.

• Set your CLI defaults so every future command in this project automatically uses your resource group and region:

az configure --defaults group=rg-network-lab location=uksouth

Why set defaults?

Without defaults, every Azure CLI command requires --resource-group and --location flags. Setting defaults saves typing and reduces the chance of accidentally creating resources in the wrong place.

Not sure which subscription is active?

If az account show displays a different subscription than expected, you may have multiple subscriptions. Use az account list --output table to see all subscriptions, then set the correct one.

help me choose the right Azure subscription

Your Azure environment is ready. Next up, you will build the virtual network and subnets that form the backbone of your segmented architecture.

Create the Virtual Network and Subnets

Your resource group is ready and your CLI defaults are configured. Now it's time to build the network foundation that all your resources will live inside.

In Azure, a Virtual Network (VNet) is the private address space where your cloud resources communicate. You divide that space into smaller sections called subnets to isolate workloads from each other.

In this step, get ready to:

• Create a VNet with a web-tier subnet.
• Add a second subnet for the data tier.
• Inspect the full network to confirm everything is in place.

Create the VNet with the first subnet

Every Azure network starts with an address space defined using CIDR notation. You will create a VNet with a large address block, then carve out a smaller subnet for web-facing resources.

• Create the VNet and its first subnet by running this command:

az network vnet create --name vnet-lab --address-prefixes 10.0.0.0/16 --subnet-name web-subnet --subnet-prefixes 10.0.1.0/24

What does this command do?

This single command creates two things at once: the VNet and its first subnet.

• `--address-prefixes 10.0.0.0/16` defines the overall address space. A /16 block gives you 65,536 possible addresses.
• `--subnet-name web-subnet` and `--subnet-prefixes 10.0.1.0/24` carve out a 256-address chunk from that space for web-tier resources.
• You did not need to specify `--resource-group` or `--location` because your CLI defaults handle those automatically.

• Confirm the VNet was created by checking the output. You should see a JSON response showing `vnet-lab` with `provisioningState` set to `Succeeded`.

What is CIDR notation?

CIDR (Classless Inter-Domain Routing) is how you define the size of a network block. The number after the slash tells you how many bits are fixed.

A /16 means the first 16 bits are locked, leaving room for 65,536 addresses. A /24 locks 24 bits, leaving 256 addresses. Smaller subnets sit inside larger ones, like folders inside folders.

Seeing an error about address space?

Make sure the subnet prefix (`10.0.1.0/24`) falls within the VNet prefix (`10.0.0.0/16`). If you changed either value, they must nest correctly.

Also confirm your CLI defaults are set. Run `az configure --list-defaults` and check that `group` shows `rg-network-lab`.

Help me troubleshoot my VNet creation error in Azure CLI.

Add the second subnet for the data tier

Your web subnet is ready. Now you need a separate subnet for data-tier resources like databases. Keeping these on different subnets lets you apply different security rules to each tier.

• Add the data subnet to your existing VNet by running this command:

az network vnet subnet create --vnet-name vnet-lab --name data-subnet --address-prefixes 10.0.2.0/24

What does this command do?

`az network vnet subnet create` adds a new subnet to an existing VNet.

• `--vnet-name vnet-lab` tells Azure which VNet to add the subnet to.
• `--address-prefixes 10.0.2.0/24` reserves a second 256-address block that does not overlap with `web-subnet` (which uses `10.0.1.0/24`).

• Verify both subnets exist by running this command:

az network vnet subnet list --vnet-name vnet-lab --output table

• You should see a table with two rows: `web-subnet` showing prefix `10.0.1.0/24`, and `data-subnet` showing prefix `10.0.2.0/24`.

Only seeing one subnet?

Double-check you ran the `az network vnet subnet create` command above. If it succeeded, the JSON output would have shown `provisioningState: Succeeded`.

Make sure `--vnet-name` is exactly `vnet-lab`. A typo creates the subnet in a different (or nonexistent) VNet.

Help me figure out why my second subnet isn't showing up.

Inspect the full VNet

• View the complete VNet configuration by running this command:

az network vnet show --name vnet-lab --output yaml

What should I see?

The YAML output displays the full picture of your network. Look for these key sections:

• `addressSpace.addressPrefixes` should list `10.0.0.0/16`.
• `subnets` should contain both `web-subnet` (prefix `10.0.1.0/24`) and `data-subnet` (prefix `10.0.2.0/24`).
• `provisioningState` should be `Succeeded` at both the VNet level and each subnet level.

Why two subnets instead of one?

Separating web and data workloads into distinct subnets is a core principle of network segmentation. Each subnet can have its own security rules, so you can allow public internet traffic to the web tier while completely blocking it from the data tier.

In the next step, you will create those security rules using Network Security Groups.

Your segmented network is in place with distinct web and data tiers. Next up, you will create Network Security Groups and attach custom rules that control exactly which traffic is allowed into each subnet.

Create and Configure Network Security Groups

In the previous step, you built a virtual network with two subnets. Right now, both subnets are wide open to any traffic flowing in or out.

In this step, you will create Network Security Groups (NSGs) and attach custom rules that control exactly which traffic is permitted. Think of NSGs as bouncers at each subnet's door, checking every packet against a list of rules to decide whether to let it through or turn it away.

In this step, get ready to:

• Create two NSGs, one for the web tier and one for the data tier.
• Add inbound rules to the web NSG that allow SSH and HTTP while blocking everything else.
• Add inbound rules to the data NSG that deny internet traffic but allow connections from the web subnet.

Create two NSGs (one per subnet)

Each subnet in your network gets its own NSG. This lets you apply different security postures to different tiers.

The web tier needs to accept traffic from the public internet on specific ports. The data tier needs to reject internet traffic entirely.

• Create the web tier NSG by running this command:

az network nsg create --name nsg-web

• Create the data tier NSG by running this command:

az network nsg create --name nsg-data

• Verify both NSGs exist by running:

az network nsg list --output table

You should see nsg-web and nsg-data listed in the table output, both in the uksouth location.

Why no --resource-group flag?

In a previous step you ran az configure --defaults to set your default resource group and location. Azure CLI automatically uses those defaults so you don't have to type them every time.

Seeing a permission or subscription error?

Make sure you are still signed in by running az account show. If your session expired, run az login again.

Confirm the active subscription has your free credit attached.

Help me troubleshoot this permission error

Add security rules to the web NSG

An NSG starts with Azure's default rules, which allow all outbound traffic and deny all inbound traffic from the internet. You need to punch specific holes to let SSH and HTTP through while keeping everything else locked down.

How does rule priority work?

Azure evaluates NSG rules starting from the lowest priority number. A rule at priority 100 is checked before a rule at priority 4000. The first matching rule wins and Azure stops evaluating further rules for that packet.

The valid range is 100 to 4096. By placing your Allow rules at low numbers and a catch-all Deny at 4000, you ensure allowed traffic matches first and everything else hits the deny.

• Allow SSH traffic on port 22 by running:

az network nsg rule create --nsg-name nsg-web --name AllowSSH --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 22

• Allow HTTP traffic on port 80 by running:

az network nsg rule create --nsg-name nsg-web --name AllowHTTP --priority 110 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 80

• Deny all other inbound traffic by running:

az network nsg rule create --nsg-name nsg-web --name DenyAllInbound --priority 4000 --direction Inbound --access Deny --protocol "*" --destination-port-ranges "*"

What do these three rules do together?

The three rules form a whitelist pattern. AllowSSH (priority 100) permits remote terminal access. AllowHTTP (priority 110) permits web traffic.

DenyAllInbound (priority 4000) rejects everything else that slips past the first two rules.

• Confirm all three rules are in place by running:

az network nsg rule list --nsg-name nsg-web --output table

You should see AllowSSH, AllowHTTP, and DenyAllInbound in the output with their respective priorities and access values.

Missing a rule in the output?

Check for typos in the --nsg-name flag. It must be exactly nsg-web. If a rule creation command returned an error, scroll up in your terminal to find the message and re-run the corrected command.

Help me fix my NSG rule issue

Add restrictive rules to the data NSG

The data tier stores sensitive resources like databases. It should never be directly reachable from the public internet.

Only the web subnet should be able to talk to the data tier, and only on specific ports.

• Deny all inbound traffic from the internet by running:

az network nsg rule create --nsg-name nsg-data --name DenyInternetInbound --priority 100 --direction Inbound --access Deny --protocol "*" --source-address-prefixes Internet --destination-port-ranges "*"

• Allow inbound traffic from the web subnet on port 1433 by running:

az network nsg rule create --nsg-name nsg-data --name AllowFromWebSubnet --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 10.0.1.0/24 --destination-port-ranges 1433

Why does order matter here?

The DenyInternetInbound rule at priority 100 blocks all internet-sourced traffic. The AllowFromWebSubnet rule at priority 200 permits traffic from 10.0.1.0/24 (your web subnet).

This works because internal VNet traffic has a source address from your private range, not tagged as Internet. So internal traffic skips the deny rule and matches the allow rule.

• Confirm both rules are in place by running:

az network nsg rule list --nsg-name nsg-data --output table

You should see DenyInternetInbound and AllowFromWebSubnet listed with their respective priorities and source address prefixes.

Rule not showing the right source address?

Double check that --source-address-prefixes is spelled with an s at the end (prefixes, not prefix). Also verify the CIDR notation is exactly 10.0.1.0/24 with no extra spaces.

Help me debug my data NSG rules

Your security groups are ready with custom rules that whitelist specific traffic for the web tier and lock down the data tier. In the next step, you will associate these NSGs with their subnets and deploy a VM to test connectivity.

Associate NSGs to Subnets and Deploy a VM

In the previous step, you created two Network Security Groups with custom rules defining which traffic is allowed and denied. Rules alone don't protect anything until the NSGs are attached to the subnets they're meant to guard.

In this step, you'll associate each NSG with its respective subnet, then deploy a Linux VM into the web subnet to prove the network is working. The VM gives you a real resource to test your security rules against in the next step.

In this step, get ready to:

• Associate each NSG with its corresponding subnet.
• Deploy a Linux VM into the web subnet.
• Verify SSH connectivity to the VM.

Associate each NSG with its subnet

An NSG only filters traffic once it's associated with a subnet or network interface. You'll update each subnet to attach the NSG you built for it.

• Associate nsg-web with web-subnet by running this command:

az network vnet subnet update --vnet-name vnet-lab --name web-subnet --network-security-group nsg-web

• Associate nsg-data with data-subnet by running this command:

az network vnet subnet update --vnet-name vnet-lab --name data-subnet --network-security-group nsg-data

What do these commands do?

The --network-security-group flag on az network vnet subnet update attaches the named NSG to the subnet.

Once attached, every resource deployed into that subnet inherits the NSG's inbound and outbound rules automatically.

• Verify both associations by running:

az network vnet subnet list --vnet-name vnet-lab --output table

You should see a table listing both web-subnet and data-subnet, each showing an NSG resource ID in the output.

Don't see the NSG association?

Make sure the NSG name matches exactly what you created in the previous step (nsg-web and nsg-data). Names are case-sensitive.

Also confirm your CLI defaults are still set to rg-network-lab by running az configure --list-defaults.

Help me troubleshoot my NSG subnet association

Deploy a Linux VM into the web subnet

With the NSGs guarding each subnet, you now need a resource inside the network to test against. You'll deploy a lightweight Linux VM into the web subnet.

• Create the VM by running this command:

az vm create --name vm-web --image Ubuntu2204 --vnet-name vnet-lab --subnet web-subnet --size Standard_B1s --admin-username azureuser --generate-ssh-keys --output json

What does this command do?

• --name vm-web names your virtual machine.
• --image Ubuntu2204 uses the Ubuntu 22.04 LTS image alias.
• --vnet-name vnet-lab --subnet web-subnet places the VM inside your secured web subnet.
• --size Standard_B1s selects the free-tier burstable VM size (750 free hours/month for 12 months).
• --generate-ssh-keys creates an SSH key pair if one doesn't already exist on your machine.
• --output json returns structured output so you can easily find the public IP.

This command takes a few minutes

Azure is provisioning the VM, a network interface, a public IP address, and an OS disk behind the scenes. Wait for the command to finish before proceeding.

When the command completes, you'll see JSON output. Look for the publicIpAddress field and note down its value.

What should I see?

The output includes fields like powerState, privateIpAddress, and publicIpAddress. The publicIpAddress is the address you'll use to SSH into the VM.

VM creation failed?

If you see a quota error, your subscription may not have capacity for the Standard_B1s size in uksouth. Check that you're using the Azure free account and haven't exhausted your credit.

If you see a key-related error, the --generate-ssh-keys flag reuses an existing id_rsa key if one already exists in ~/.ssh/. This is normal and not an error.

Help me troubleshoot my VM creation error

Verify the VM is running and SSH is accessible

Your NSG rules allow SSH (port 22) inbound to the web subnet. Connecting via SSH proves those rules are working as intended.

• Connect to your VM over SSH by running this command:

ssh azureuser@[[PUBLIC_IP="your VM's public IP address"]]

What happens when you connect?

The first time you SSH to a new host, your terminal asks you to confirm the server's fingerprint. Type yes and press Enter to continue connecting.

You should see a Linux terminal prompt showing azureuser@vm-web. This confirms that port 22 is open through your NSG and the VM is reachable.

What about HTTP (port 80)?

Your NSG allows HTTP inbound, but no web server is installed yet. If you tried to access port 80, the connection would be allowed by the NSG but refused by the VM because nothing is listening there. This is expected.

• Exit the SSH session by running:

exit

You're back in your local terminal.

SSH connection timed out?

Double-check the public IP address you copied from the VM creation output. A typo in the IP will cause a timeout.

If the IP is correct but you still can't connect, verify that nsg-web is associated with web-subnet by running az network vnet subnet show --vnet-name vnet-lab --name web-subnet --query networkSecurityGroup.

Help me fix my SSH connection to the Azure VM

Your VM is deployed and protected by the web NSG. Next up, you'll inspect the effective security rules and prove that blocked traffic is actually denied.

Verify Security Rules and Inspect Effective Rules

You have a segmented network with NSGs attached to each subnet and a VM deployed into the web tier. The next question is: are those security rules actually doing what you intended?

In this step you will inspect the effective rules that Azure applies to your VM's network interface, test that blocked traffic is genuinely denied, and take a final inventory of every resource in your project.

In this step, get ready to:

• List the effective security rules applied to your VM's network interface.
• Test that traffic to the data subnet is blocked as expected.
• Review every resource you created in the project.

List effective security rules on the VM's network interface

Azure can apply rules from multiple sources: the subnet-level NSG, a NIC-level NSG, and default platform rules. The "effective rules" view merges all of these into a single ordered list so you can see exactly what Azure will allow or deny.

• Get the resource ID of your VM's network interface by running this command:

az vm show --name vm-web --query "networkProfile.networkInterfaces[0].id" --output tsv

You should see a long resource ID string printed in the terminal, starting with /subscriptions/.

• Copy that entire output string.
• List the effective NSG rules for that NIC by running this command:

az network nic list-effective-nsg --ids [[NIC_ID="your NIC resource ID from the previous command"]] --output table

What does this output show?

The table lists every rule that Azure evaluates for traffic hitting your VM's NIC. You should see your custom rules (AllowSSH at priority 100, AllowHTTP at 110, DenyAllInbound at 4000) alongside Azure's built-in default rules.

Azure processes rules from lowest priority number to highest. The first matching rule wins. This is why your AllowSSH (100) takes effect before DenyAllInbound (4000).

Seeing an empty table or an error?

Make sure you pasted the full NIC resource ID (it starts with /subscriptions/ and ends with the NIC name).

The VM must be in a running state for this command to return results. If you deallocated it, start it again with az vm start --name vm-web.

Help me troubleshoot why my effective NSG rules command is returning empty results.

Test that blocked traffic is actually denied

Reading rules on paper is one thing. Proving they work by sending actual traffic is how you validate your security posture in production.

• SSH into your VM by running this command:

ssh azureuser@[[PUBLIC_IP="your VM's public IP address"]]

• From inside the VM, attempt to connect to the data subnet on port 1433 by running:

curl -v telnet://10.0.2.4:1433 --connect-timeout 5

After about 5 seconds, you should see the connection time out. There is no server at that address, and the data tier's NSG is configured to deny all inbound internet traffic.

How does Azure evaluate NSG rules?

Azure processes NSG rules by priority, lowest number first (100 before 200 before 4000). The first rule whose conditions match the traffic wins. All remaining rules are ignored for that packet.

On nsg-data, the DenyInternetInbound rule at priority 100 catches any traffic sourced from the Internet service tag before the AllowFromWebSubnet rule at 200 can act. This layered approach lets you build precise allow-lists while keeping a strong deny-by-default posture.

• Exit the SSH session by running:

exit

Connection refused instead of timeout?

A "connection refused" message means a host at that IP actively rejected the connection. Verify you typed the correct IP: 10.0.2.4.

If the curl command is not found inside the VM, install it with sudo apt-get install -y curl and try again.

Help me debug my connectivity test to the data subnet.

Review all resources created

Before wrapping up, take a full inventory of everything Azure provisioned for this project. This confirms nothing unexpected was created and gives you a clear picture of what you will clean up later.

• List every resource in your resource group by running:

az resource list --resource-group rg-network-lab --output table

You should see a table containing your VNet, two subnets, two NSGs, one VM, a public IP, a NIC, and an OS disk.

Why use a single resource group?

Placing every resource in one group (rg-network-lab) means a single az group delete command tears everything down at once. This is a best practice for lab environments so you never leave orphaned resources running up charges.

Missing resources in the list?

Make sure you include --resource-group rg-network-lab in the command. If your CLI defaults were cleared, the command may target the wrong group.

Help me figure out why some resources are missing from my resource list.

Your security rules are verified and every resource is accounted for. Next up is the Secret Mission, where you will peer two virtual networks together and prove private connectivity across them.

Secret mission

Add VNet Peering

Your segmented network is locked down tight. But enterprises rarely run just one VNet. Extend your architecture by peering two virtual networks together and proving that traffic flows privately between them while NSG rules still hold.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The B1s VMs in this project are covered by the Azure free account's 750 free hours per month for 12 months.

Cost warning

A single B1s VM running 24/7 uses about 720 hours per month, which fits within your 750-hour free allocation. If you completed the Secret Mission and have two B1s VMs running, you will exceed the free tier and incur charges.

If you have both VMs running, deallocate at least one (see the Pause tab) or delete everything (see the Delete tab) to avoid unexpected costs.

Resources you used:

• Resource group rg-network-lab containing: VNets, subnets, NSGs, VMs, public IPs, NICs, OS disks, and VNet peering connections.
• Azure CLI installed locally via Homebrew.

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with Azure networking concepts.

• Your single vm-web VM is covered by the 750 free B1s hours per month for 12 months.
• If you completed the Secret Mission, vm-peer is also running. Two B1s VMs exceed the free tier. Consider deallocating one.
• Your Azure CLI installation and ~/.azure configuration directory remain on your machine.

Pause - I'll come back to this later

Deallocate your VMs to stop compute charges while keeping all network resources intact. You can restart the VMs later without rebuilding anything.

• Deallocate your web VM by running:

az vm deallocate --name vm-web

• If you completed the Secret Mission, also deallocate your peer VM:

az vm deallocate --name vm-peer

• When you are ready to resume, start the VMs again with:

az vm start --name vm-web

• Your VNets, subnets, NSGs, and peering connections remain in place at no cost while the VMs are deallocated.

Delete - I don't want to use this again

Remove all project resources and start fresh. This deletes everything in one command because all resources live inside a single resource group.

• Delete the entire resource group by running:

az group delete --name rg-network-lab --yes --no-wait

What does this command do?

The --yes flag skips the confirmation prompt. The --no-wait flag returns control to your terminal immediately while Azure deletes the resources in the background.

• This removes the VNets, subnets, NSGs, both VMs, public IPs, NICs, OS disks, and all peering connections.
• Uninstall Azure CLI from your machine by running:

brew uninstall azure-cli

• Remove the Azure CLI configuration directory:

rm -rf ~/.azure

• Confirm the CLI is removed by running:

az version

• You should see a "command not found" message, confirming Azure CLI is fully removed.

Nice Work!

Nice Work!

Nice work! You just built a production-style segmented network in Azure with custom security controls, all from the command line.

You've learned how to:

• Built a multi-subnet virtual network with proper CIDR addressing to isolate web and data tiers.
• Created and configured Network Security Groups with custom inbound and outbound rules controlling traffic between subnets.
• Deployed a Linux VM into a secured subnet using Azure CLI and verified effective security rules by testing traffic filtering.
• Secret Mission: Established VNet peering between two virtual networks and verified cross-VNet private connectivity while confirming NSG rules still apply.

Ready to quiz yourself?