Build and Secure an Azure Virtual Network

Deploy a segmented Azure VNet with NSGs and VNet peering for AZ-104.

Introduction

30 Second Summary

Every company with cloud infrastructure faces the same challenge: how do you let your web servers talk to your databases without exposing everything to the internet? The answer is network segmentation. You split your cloud resources into isolated groups and control exactly which traffic can flow between them.

In this project, you will build a segmented network architecture in Azure with two Virtual Networks, multiple subnets, security rules, and cross-network peering. You will use both the Azure Portal and the Azure CLI to manage everything.

What You'll Build

A multi-network Azure environment simulating a real-world scenario: a Production VNet with frontend and backend subnets, a Management VNet with an admin subnet, Network Security Groups controlling traffic flow, and VNet peering connecting the two networks.

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

  • Two Virtual Networks with non-overlapping address spaces and three subnets deployed using the Azure CLI.
  • Custom NSG rules restricting traffic by source subnet and port, verified through CLI queries.
  • Bidirectional VNet peering with a confirmed "Connected" state, proving cross-network communication works.
  • Secret Mission: implement zero-trust network segmentation with a deny-all rule and a scoped SSH exception.

Are there any prerequisites?

No prior Azure experience is required. This project walks you through creating a free Azure account and installing all the tools you need. A Windows PC is all you need to get started.

Set Up Azure Account and CLI

Before you can build virtual networks in Azure, you need an Azure account and the tools to manage resources from your terminal.

In this step, you will create a free Azure account, install the Azure CLI on Windows, and sign in so your terminal can talk directly to Azure.

In this step, get ready to:
  • Create your Azure free account.
  • Install Azure CLI on Windows.
  • Sign in to Azure from the CLI.
Create your Azure free account

Azure offers a free account with $200 in credit for 30 days. This is more than enough to cover everything in this project.

  • Open your browser and go to:
  • https://azure.microsoft.com/en-us/free
  • Click Start free.
  • Sign in with a Microsoft account or GitHub account. If you do not have one, create a Microsoft account when prompted.
  • Complete the registration form with your phone number and a credit or debit card (non-prepaid) for identity verification.

Will I be charged?

No. The credit card is for identity verification only. You will not be charged unless you manually upgrade to a paid plan after using your $200 credit.

Install Azure CLI on Windows

The Azure CLI lets you create and manage Azure resources directly from your terminal. You will use it throughout this project to build virtual networks, subnets, and security rules.

  • Press the Windows key to open your search bar.
  • Type PowerShell.
  • Right-click Windows PowerShell and select Run as administrator.
  • If a User Account Control prompt appears, click Yes to allow it.
  • Check whether Azure CLI is already installed by running this command:
az version

✔️ I see version 2.87.0 or later

Azure CLI is already installed and up to date. Skip ahead to the next substep where you sign in.

ⓧ I see an older version

You have an older version of Azure CLI installed. Upgrade it to the latest version by running this command:

winget upgrade --exact --id Microsoft.AzureCLI
  • After the upgrade completes, close PowerShell completely.
  • Reopen PowerShell as Administrator (same steps as before).
  • Run az version again to confirm the version is 2.87.0 or later.

ⓧ Command not found

Azure CLI is not installed yet. Install it using WinGet by running this command:

winget install --exact --id Microsoft.AzureCLI

What does this command do?

WinGet is Windows' built-in package manager. The --exact --id flags ensure you install the correct package by its precise identifier, Microsoft.AzureCLI.

  • Wait for the installation to finish. You may see a progress bar and a success message.
  • Close PowerShell completely after installation.
  • Reopen PowerShell as Administrator (press the Windows key, type PowerShell, right-click, Run as administrator).
  • Verify the installation by running:
az version

You should see JSON output showing azure-cli with a version of 2.87.0 or later.

Command still not found after install?

Make sure you fully closed and reopened PowerShell after the installation. The new az command is only available in new terminal sessions.

If the issue persists, check that WinGet itself is working by running winget --version. WinGet comes pre-installed on Windows 10 (1709+) and Windows 11.

Help me fix Azure CLI not being recognized

Sign in to Azure from the CLI

Now that Azure CLI is installed, you need to authenticate it with your Azure account so it can create and manage resources on your behalf.

  • In your PowerShell window, sign in to Azure by running this command:
az login

What happens when you run this?

A browser window opens automatically and asks you to sign in with your Microsoft account. After you authenticate in the browser, the CLI receives your credentials and the browser window tells you to close it.

  • Sign in with the same Microsoft account you used to create your Azure free account.
  • After signing in, return to PowerShell. You should see JSON output showing your subscription details.
  • Confirm your subscription name and ID are correct by running this command:
az account show --query "{name:name, id:id}" --output table

You should see a table with your subscription name (likely Azure subscription 1) and your subscription ID.

What does this command do?

The --query flag uses JMESPath syntax to pick specific fields from the JSON output. The --output table flag formats the result as a readable table instead of raw JSON.

Browser did not open?

If no browser window appears, look for a URL in the terminal output. Copy that URL and paste it into your browser manually to complete authentication.

Help me authenticate Azure CLI

Your Azure account is active and your CLI is authenticated. Next up, you will create the virtual networks and subnets that form the backbone of your network architecture.

Create Virtual Networks and Subnets

Your Azure CLI is installed and authenticated. Now it's time to build the network foundation your production environment will run on.

Every Azure resource lives inside a resource group. In this step, you will create a resource group, then deploy two Virtual Networks (VNets) with multiple subnets to simulate a real production and management architecture.

In this step, get ready to:
  • Create a resource group to hold all networking resources.
  • Deploy two Virtual Networks with non-overlapping address spaces.
  • Verify your VNets and subnets exist via CLI and Azure Portal.
Create a resource group

A resource group is a logical container that holds related Azure resources. Creating one first keeps everything organized and makes cleanup simple later.

  • Create a resource group named az104-networking-rg in the eastus region by running this command:
az group create --name az104-networking-rg --location eastus
  • You should see a JSON response in your terminal with "provisioningState": "Succeeded" confirming the resource group was created.

Seeing an authorization error?

Make sure you are still signed in to Azure CLI. Run az account show to verify your session is active. If it expired, run az login again.

Help me fix this authorization error

Create the Production VNet and subnets

Your Production VNet simulates where frontend web servers and backend databases would live. You will give it an address space of 10.0.0.0/16 and split it into two subnets.

  • Create the Production VNet with a frontend subnet by running this command:
az network vnet create --resource-group az104-networking-rg --name prod-vnet --address-prefixes 10.0.0.0/16 --subnet-name frontend --subnet-prefixes 10.0.1.0/24

What does this command do?

  • --name prod-vnet creates a Virtual Network called prod-vnet.
  • --address-prefixes 10.0.0.0/16 defines the overall address space using CIDR notation. This gives you over 65,000 possible IP addresses within this VNet.
  • --subnet-name frontend and --subnet-prefixes 10.0.1.0/24 carve out a subnet with 256 addresses (251 usable, since Azure reserves 5 per subnet).
  • You should see a JSON response showing prod-vnet with its address space and the frontend subnet listed.
  • Add the backend subnet to prod-vnet by running this command:
az network vnet subnet create --resource-group az104-networking-rg --vnet-name prod-vnet --name backend --address-prefixes 10.0.2.0/24
  • You should see a JSON response showing the backend subnet with address prefix 10.0.2.0/24.

Command returning an error?

Check that the resource group name az104-networking-rg matches exactly what you created in the previous command. Names are case-sensitive.

Also confirm the subnet prefix 10.0.2.0/24 does not overlap with the existing frontend subnet 10.0.1.0/24. Overlapping address ranges cause an error.

Help me troubleshoot this subnet creation error

Create the Management VNet and verify both networks

The Management VNet is where administrators connect from. Its address space (10.1.0.0/16) deliberately does not overlap with the Production VNet. Non-overlapping address spaces are required for VNet Peering, which you will configure in a later step.

  • Create the Management VNet with an admin subnet by running this command:
az network vnet create --resource-group az104-networking-rg --name mgmt-vnet --address-prefixes 10.1.0.0/16 --subnet-name admin --subnet-prefixes 10.1.1.0/24

Why non-overlapping address spaces?

Azure requires non-overlapping address ranges between VNets that will be peered together. If prod-vnet uses 10.0.0.0/16 and mgmt-vnet uses 10.1.0.0/16, there is no overlap.

This is a common exam topic on the AZ-104. Overlapping ranges will cause the peering creation to fail.

  • You should see a JSON response confirming mgmt-vnet with the admin subnet.
  • Verify both VNets exist by running this command:
az network vnet list --resource-group az104-networking-rg --output table
  • You should see a table listing both prod-vnet and mgmt-vnet with their address prefixes and location.

Now confirm these same resources are visible in the Azure Portal.

  • Open your browser and go to portal.azure.com.
  • Sign in with the same Microsoft account you used for az login.
  • In the search bar at the top, type Virtual networks and select Virtual networks from the results.
  • You should see both prod-vnet and mgmt-vnet listed in the table.

What is the Azure Portal?

The Azure Portal is a web-based graphical interface for managing Azure resources. It shows the same underlying resources as the CLI.

The AZ-104 exam tests you on both the Portal and CLI interfaces, so practicing both builds the muscle memory you need on exam day.

Don't see your VNets in the Portal?

Make sure you are signed into the Portal with the same account connected to your Azure subscription. Check the subscription filter at the top of the Virtual networks page to confirm the correct subscription is selected.

Help me find my VNets in the Azure Portal

Your network foundation is in place. Next up, you will lock down traffic between these subnets using Network Security Groups.

Configure Network Security Groups

Your two VNets and subnets are in place. But right now, there's nothing stopping any traffic from reaching any subnet. In a real production environment, you need to lock down which traffic is allowed in and out.

Network Security Groups (NSGs) act as virtual firewalls that filter network traffic to and from Azure resources. In this step, you'll create NSGs, attach them to your subnets, and add rules that restrict traffic to only the ports and sources you explicitly allow.

In this step, get ready to:
  • Create two NSGs and associate them with subnets.
  • Add custom inbound rules controlling traffic by port and source.
  • Verify effective security rules via CLI.
Create NSGs and associate them with subnets

An NSG on its own does nothing until you associate it with a subnet or network interface. You'll create one NSG for the frontend subnet and another for the backend subnet, then link each to its target.

  • Create two Network Security Groups by running these commands:
az network nsg create --resource-group az104-networking-rg --name frontend-nsg
az network nsg create --resource-group az104-networking-rg --name backend-nsg
  • Each command outputs JSON. Confirm that both outputs contain "provisioningState": "Succeeded".

Seeing a resource group not found error?

Make sure you're using the exact resource group name az104-networking-rg. A typo in the name causes the command to fail. Also confirm you're signed in to the correct subscription with az account show.

Why is my NSG create command failing?

  • Associate frontend-nsg with the frontend subnet and backend-nsg with the backend subnet by running these commands:
az network vnet subnet update --resource-group az104-networking-rg --vnet-name prod-vnet --name frontend --network-security-group frontend-nsg
az network vnet subnet update --resource-group az104-networking-rg --vnet-name prod-vnet --name backend --network-security-group backend-nsg
  • The output for each command shows the updated subnet configuration. Look for the networkSecurityGroup field. It now contains the resource ID of your NSG.

Why associate at the subnet level?

NSGs can be associated with either a subnet or an individual network interface. Associating at the subnet level applies the rules to every resource in that subnet automatically. This is the standard approach for broad traffic policies.

Subnet update command not working?

Double-check that --vnet-name is prod-vnet and --name is the exact subnet name (frontend or backend). These are case-sensitive.

Help me fix my subnet update command.

Add custom inbound security rules

NSGs come with default rules that allow internal VNet traffic and deny most inbound traffic from the internet. Custom rules let you open specific ports to specific sources.

  • Add a rule to frontend-nsg that allows HTTP traffic (port 80) from any source by running:
az network nsg rule create --resource-group az104-networking-rg --nsg-name frontend-nsg --name AllowHTTP --priority 100 --direction Inbound --access Allow --protocol Tcp --source-address-prefix "*" --source-port-range "*" --destination-address-prefix "*" --destination-port-range 80
  • The output shows a JSON object with your rule details. Confirm that access is Allow and destinationPortRange is 80.

What do these flags mean?

  • --priority 100 sets evaluation order. Lower numbers are evaluated first. Custom rules use the 100-4096 range.
  • --direction Inbound means this rule applies to traffic coming into the subnet.
  • --source-address-prefix "*" means any source IP is allowed through. The frontend is public-facing, so it accepts traffic from anywhere.
  • --destination-port-range 80 limits the rule to HTTP traffic only.

Getting an invalid parameter error?

The wildcard * in --source-address-prefix and --source-port-range must be wrapped in quotes. Make sure you include the quotes around the asterisk.

Help me fix my NSG rule command.

  • Add a rule to backend-nsg that allows MySQL traffic (port 3306) only from the frontend subnet by running:
az network nsg rule create --resource-group az104-networking-rg --nsg-name backend-nsg --name AllowMySQLFromFrontend --priority 100 --direction Inbound --access Allow --protocol Tcp --source-address-prefix 10.0.1.0/24 --source-port-range "*" --destination-address-prefix "*" --destination-port-range 3306
  • Confirm the output shows sourceAddressPrefix as 10.0.1.0/24 and destinationPortRange as 3306.

Why restrict by source subnet?

The backend-nsg rule uses 10.0.1.0/24 (the frontend subnet's address range) as the source. This means only resources in the frontend subnet can reach port 3306 on the backend. Any other source is blocked by the default deny rule.

This is the foundation of network segmentation. You define exactly which subnet can talk to which, and on which ports.

Verify your security rules
  • List the custom rules for both NSGs to see them side by side. Run the first command:
az network nsg rule list --resource-group az104-networking-rg --nsg-name frontend-nsg --output table
  • You should see a table with one row: AllowHTTP with priority 100, direction Inbound, and port 80.
  • Now run the same for the backend NSG:
az network nsg rule list --resource-group az104-networking-rg --nsg-name backend-nsg --output table
  • You should see AllowMySQLFromFrontend with priority 100, source 10.0.1.0/24, and port 3306.

These tables only show your custom rules. Azure also applies default rules behind the scenes. Let's look at those too.

  • View the default rules that Azure automatically adds to every NSG by running:
az network nsg show --resource-group az104-networking-rg --name backend-nsg --query "defaultSecurityRules[]" --output table
  • You should see several rows including AllowVnetInBound, AllowAzureLoadBalancerInBound, and DenyAllInBound. These rules have priority numbers starting at 65000.

How do custom and default rules work together?

Azure evaluates rules in priority order. Your custom rules (priority 100) are checked before the default rules (priority 65000+). If a packet matches your AllowMySQLFromFrontend rule at priority 100, it's allowed in. If no custom rule matches, the packet eventually hits DenyAllInBound at priority 65500 and gets blocked.

This is why your backend is secure. Only MySQL traffic from the frontend subnet gets through. Everything else is denied by default.

Your subnets are now locked down with custom security rules. Only HTTP traffic reaches the frontend, and only the frontend subnet can reach the backend on port 3306. Next up, you'll connect your two VNets with peering so the Management network can reach Production.

Establish VNet Peering

Your two Virtual Networks are locked down with NSGs, but right now they are completely isolated from each other. A resource in prod-vnet cannot reach anything in mgmt-vnet, and vice versa.

VNet peering solves this by creating a private, high-bandwidth link between two Virtual Networks. Traffic flows over the Azure backbone instead of crossing the public internet. In this step, you will create bidirectional peering so that your Management network can communicate with your Production network.

In this step, get ready to:
  • Store both VNet resource IDs in PowerShell variables.
  • Create bidirectional VNet peering between prod-vnet and mgmt-vnet.
  • Verify that both peering connections reach "Connected" state.
Store VNet resource IDs in PowerShell variables

The peering commands need the full Azure resource ID of each VNet, not just its name. A resource ID is a long path that uniquely identifies any resource in your Azure subscription.

  • Retrieve the resource IDs for both VNets and store them in PowerShell variables by running these commands:
$prodVnetId = az network vnet show --resource-group az104-networking-rg --name prod-vnet --query id --output tsv
$mgmtVnetId = az network vnet show --resource-group az104-networking-rg --name mgmt-vnet --query id --output tsv

What do these commands do?

  • az network vnet show retrieves the full details of a VNet.
  • --query id uses a JMESPath query to extract only the id field from the JSON response.
  • --output tsv strips the surrounding quotes so the value is safe to assign directly to a shell variable.
  • Confirm the variables are set by running:
echo $prodVnetId
echo $mgmtVnetId

You should see two long paths that look like /subscriptions/<your-sub-id>/resourceGroups/az104-networking-rg/providers/Microsoft.Network/virtualNetworks/prod-vnet and the same pattern for mgmt-vnet.

Seeing empty output?

  • Make sure you are running both commands in the same PowerShell session. If you closed and reopened PowerShell, you need to run az login again before these commands will work.
  • Check for typos in the resource group name (az104-networking-rg) and VNet names (prod-vnet, mgmt-vnet).
  • help me troubleshoot why my VNet ID variable is empty in PowerShell
Create bidirectional peering

VNet peering must be created in both directions. A single-direction link results in an "Initiated" state, meaning peering is requested but not yet active.

  • Create the peering link from prod-vnet to mgmt-vnet by running:
az network vnet peering create --name prod-to-mgmt --resource-group az104-networking-rg --vnet-name prod-vnet --remote-vnet $mgmtVnetId --allow-vnet-access
  • Create the peering link from mgmt-vnet to prod-vnet by running:
az network vnet peering create --name mgmt-to-prod --resource-group az104-networking-rg --vnet-name mgmt-vnet --remote-vnet $prodVnetId --allow-vnet-access

Why both directions and why --allow-vnet-access?

Azure requires a peering link on each side. Only when both links exist does peering become "Connected" and traffic can flow.

The --allow-vnet-access flag is critical. Without it, a peering is established but no communication can flow through it. This is a common AZ-104 exam gotcha.

Each command returns JSON output showing the peering was created. Look for "peeringState": "Connected" in the output of the second command. The first command may show "Initiated" because the return trip did not exist yet.

Seeing an error about overlapping address spaces?

  • Peering requires non-overlapping address spaces. If you accidentally created both VNets with the same prefix (e.g. both 10.0.0.0/16), you need to delete and recreate one with a different range.
  • Confirm that prod-vnet uses 10.0.0.0/16 and mgmt-vnet uses 10.1.0.0/16.
  • help me fix an overlapping address space error when creating VNet peering
Verify peering state is Connected

Both peering links should now show "Connected". Let's confirm from both sides.

  • Check the peering state on the prod-vnet side by running:
az network vnet peering show --name prod-to-mgmt --resource-group az104-networking-rg --vnet-name prod-vnet --query peeringState
  • Check the peering state on the mgmt-vnet side by running:
az network vnet peering show --name mgmt-to-prod --resource-group az104-networking-rg --vnet-name mgmt-vnet --query peeringState

Both commands should output "Connected". This confirms traffic can now flow between the two VNets.

What are the three peering states?

  • Initiated means only one link exists. The other VNet has not peered back yet.
  • Connected means both links exist and traffic can flow.
  • Disconnected means one link was deleted. You must recreate both links to restore peering.
  • Verify the peering visually in the Azure Portal:
  • Navigate to Virtual networks in the portal search bar.
  • Click prod-vnet.
  • In the left menu, select Settings then Peerings.
  • You should see prod-to-mgmt with a status of Connected.

Peering shows Initiated instead of Connected?

  • This means only one direction was created. Make sure you ran both peering create commands (prod-to-mgmt and mgmt-to-prod).
  • If you see "Initiated" on the prod-vnet side, run the second peering create command for mgmt-vnet and then re-check.
  • help me fix VNet peering stuck in Initiated state

Your two VNets are now connected with bidirectional peering. Next up, you will explore this entire network topology using both the Azure Portal and CLI queries to solidify your understanding.

Verify and Explore via the Portal

Your peering connections are live and traffic can flow between both VNets. Now it's time to verify everything you've built by viewing it through two different lenses.

The AZ-104 exam tests your ability to work with both the Azure Portal and the Azure CLI. In this step, you'll explore your full network topology using both tools to confirm every resource is configured correctly.

In this step, get ready to:
  • Explore your VNets, subnets, and NSGs visually in the Azure Portal.
  • Query the network topology and verify IP availability using Azure CLI.
  • List all resources in your resource group to see the full picture.
Navigate to the Azure Portal

Every resource you created with the CLI exists as an Azure Resource Manager object. The Portal gives you a graphical view of the same data.

  • Open portal.azure.com in your browser.
  • In the search bar at the top, type Resource groups and select it from the results.
  • Click on az104-networking-rg to view all resources in your resource group.
  • Click on prod-vnet to open the Virtual Network details.

You should see the overview page for prod-vnet showing its address space and location.

  • In the left sidebar under Settings, click Subnets.
  • Confirm you see frontend and backend subnets with their associated NSGs listed.
  • In the left sidebar under Settings, click Peerings.
  • Confirm you see the prod-to-mgmt peering with a status of Connected.

Now check the NSG rules in the Portal.

  • Click the back arrow or navigate back to az104-networking-rg in the breadcrumb at the top.
  • Click on frontend-nsg.
  • In the left sidebar under Settings, click Inbound security rules.
  • Confirm you see your AllowHTTP rule listed alongside Azure's default security rules.

Why check the Portal?

The AZ-104 exam includes interactive lab scenarios where you must navigate the Portal to find specific settings. Practicing Portal navigation now builds muscle memory for exam day.

Notice that every resource you created using az commands appears here with the same names and values. The Portal and CLI are two views of the same underlying Azure Resource Manager objects.

Query the network topology using Azure CLI

Now let's verify the same resources from the command line. This confirms that both interfaces reflect identical data.

  • List all subnets in prod-vnet by running this command:
az network vnet subnet list --resource-group az104-networking-rg --vnet-name prod-vnet --output table

You should see both frontend and backend subnets listed with their address prefixes and associated NSG names.

  • View the peering details including the remote address space by running:
az network vnet peering show --name prod-to-mgmt --resource-group az104-networking-rg --vnet-name prod-vnet --query "{state:peeringState, remoteAddressSpace:remoteAddressSpace.addressPrefixes}"

You should see peeringState showing Connected and the remote address space 10.1.0.0/16 (the Management VNet).

What is the --query parameter doing?

The --query parameter uses JMESPath syntax to extract specific fields from the JSON response. Instead of reading through a wall of JSON, you pull out exactly the values you need.

On the AZ-104 exam, you may need to write CLI queries that return specific values from command output.

  • Check if a specific IP address is available in your VNet by running:
az network vnet check-ip-address --resource-group az104-networking-rg --name prod-vnet --ip-address 10.0.1.10

You should see "available": true in the output, confirming that 10.0.1.10 is free to use within the frontend subnet's range.

Seeing an error on any of these commands?

Make sure you completed all commands in Steps 2-4. These verification commands query resources that must already exist.

If you see ResourceNotFound, double check the resource group name is exactly az104-networking-rg and the VNet name is prod-vnet.

help me troubleshoot Azure CLI resource not found errors

List all resources in your resource group

As a final check, let's see every resource you created during this project in one view.

  • List all resources in your resource group by running:
az resource list --resource-group az104-networking-rg --output table

You should see your VNets, NSGs, and all associated resources listed with their types and locations.

Why is this useful?

Listing all resources in a resource group gives you a single inventory of everything you've deployed. On the AZ-104 exam, understanding resource group scope helps you answer questions about resource management, access control, and cleanup.

Notice that deleting a resource group removes everything inside it in one action. This is why grouping related resources together matters.

Secret mission

Implement Zero-Trust Network Segmentation

Your backend subnet currently allows MySQL traffic from the frontend. But in a real production environment, zero-trust means denying everything by default and only allowing what's explicitly needed. Can you add a deny-all rule and a scoped SSH exception to lock down the backend?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running or delete them entirely. The networking resources you created in this project (VNets, subnets, NSGs, and VNet peering) are free resources and do not consume your $200 Azure credit.

Cost warning

VNets, subnets, NSGs, and VNet peering connections are free resources. They will not use any of your Azure credit.

However, if you later deploy VMs, load balancers, or other compute resources into these VNets, those resources will consume your $200 free credit. Delete the resource group if you do not plan to continue building on this network topology.

Resources you used:

  • 1 resource group (az104-networking-rg).
  • 2 Virtual Networks (prod-vnet and mgmt-vnet).
  • 3 subnets (frontend, backend, admin).
  • 2 Network Security Groups (frontend-nsg and backend-nsg) with custom rules.
  • 2 VNet peering connections (prod-to-mgmt and mgmt-to-prod).

Keep everything running

No action needed. Choose this if you plan to continue building on this network topology for future AZ-104 projects (such as deploying VMs or configuring monitoring).

  • All networking resources in az104-networking-rg remain deployed at no cost.
  • Azure CLI remains installed on your machine for future use.
  • Your Azure free account stays active with the remaining balance of your $200 credit (valid for 30 days from signup).

Pause - I'll come back to this later

Since VNets, subnets, NSGs, and peering are free, there is nothing to pause. Your resources remain deployed without incurring charges.

  • Leave the resource group as-is. No charges accumulate from the networking resources.
  • When you return, sign in with az login and run az resource list --resource-group az104-networking-rg --output table to confirm everything is still in place.

Delete - I don't want to use this again

Remove all project resources in one command. Deleting the resource group removes every resource inside it (VNets, subnets, NSGs, peering connections).

  • Delete the entire resource group by running this command in PowerShell:
az group delete --name az104-networking-rg --yes --no-wait

What does this command do?

  • --yes skips the confirmation prompt.
  • --no-wait returns control to your terminal immediately while Azure deletes resources in the background.
  • Verify deletion is underway by running:
az group list --output table

After a few minutes, az104-networking-rg will no longer appear in the output.

Nice Work!

Nice Work!

You've just built a production-grade network topology in Azure with segmented subnets, locked-down security groups, and verified cross-VNet connectivity.

You've learned how to:

  • Created two Virtual Networks with distinct address spaces and configured multiple subnets to segment traffic across frontend, backend, and admin tiers.
  • Configured Network Security Groups with custom inbound rules that restrict traffic by source subnet and destination port.
  • Established bidirectional VNet peering and verified the "Connected" state using both the Azure Portal and Azure CLI.
  • Secret Mission: Implemented zero-trust network segmentation with a deny-all rule and a scoped SSH exception based on source subnet.

Ready to quiz yourself?