Lesson 2: Network Segmentation, Address Spaces and Creating a VNet

Before you start

This course is independent of Microsoft. It follows Microsoft's own Study guide for Exam AZ-700, which is free on Microsoft Learn and isn't reproduced here. Microsoft gives you 100 minutes for the exam, and you need a score of 700 or greater to pass. No course can promise you a pass. Hands-on practice gives you the best chance.

This level covers the first two bullets of the guide's Design and implement IP addressing for Azure resources objective:

• Plan and implement network segmentation and address spaces
• Create a virtual network (VNet)

Step 1: Understand address spaces and segmentation

A VNet is a private network in one Azure region. Every VNet has one or more address spaces (also called address prefixes): CIDR blocks such as 10.1.0.0/16. You segment the VNet by cutting its address space into subnets.

Rules to remember:

1. Each subnet must fall inside the VNet's address space.
2. Subnets in the same VNet can't overlap each other.
3. Address ranges use CIDR notation.
4. A VNet can have several address spaces, and you can add, remove or change them after you create it.
5. The smallest supported IPv4 subnet is /29. The largest is /2.

Use private RFC 1918 ranges:

• 10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
• 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
• 192.168.0.0 – 192.168.255.255 (192.168.0.0/16)

You can't add these ranges to a VNet: 224.0.0.0/4 (multicast), 255.255.255.255/32 (broadcast), 127.0.0.0/8 (loopback), 169.254.0.0/16 (link-local) and 168.63.129.16/32 (Azure's internal DNS, DHCP and Load Balancer health probe address).

Step 2: Design non-overlapping hub, spoke and on-premises ranges

You can only connect networks to each other if their CIDR blocks don't overlap. That applies to VNet-to-VNet links and to links with on-premises networks. Think of it like postcodes: two towns with the same postcode can't share one mail system. Get this right on day one, because renumbering a live network is painful.

Your task: write an address plan before you deploy anything. Worked example:

Planning checklist:

• List every existing range first: on-premises, branch offices, partner networks and other clouds.
• Give each VNet its own block that doesn't overlap any other block.
• Leave unused blocks between networks so each one can grow.
• Size subnets for the future, not just for today's VM count.
• Write the plan down and keep it up to date. It's your single source of truth.

Step 3: Calculate usable addresses

Azure reserves five IP addresses in every subnet: the first four and the last one. In 192.168.1.0/24 they are:

Formula: usable = 2^(32 − prefix) − 5

• /24 → 256 − 5 = 251
• /26 → 64 − 5 = 59
• /27 → 32 − 5 = 27
• /29 → 8 − 5 = 3

The first address you can assign is .4. For example, 10.1.1.4 is the first usable address in 10.1.1.0/24.

Step 4: Create a VNet in the Azure portal

1. Select Create a resource > Virtual network > Create.
2. On Basics, choose the subscription and resource group, then enter a name (vnet-spoke1) and a region.
3. Skip Security for now. Later levels cover those options.
4. On IP addresses, edit the default IPv4 address space to 10.1.0.0/16. Select Add IPv4 address space and add 10.201.0.0/24.
5. Delete or edit the default subnet. Add snet-app (10.1.1.0/24) and snet-data (10.1.2.0/24). The portal shows the size of each subnet as you type.
6. Add Tags if you need them, then select Review + create > Create.

Step 5: Create the same VNet with Azure CLI

az group create --name rg-net --location uksouth

az network vnet create \
  --resource-group rg-net \
  --name vnet-spoke1 \
  --location uksouth \
  --address-prefixes 10.1.0.0/16 10.201.0.0/24 \
  --subnet-name snet-app \
  --subnet-prefixes 10.1.1.0/24

az network vnet subnet create \
  --resource-group rg-net \
  --vnet-name vnet-spoke1 \
  --name snet-data \
  --address-prefixes 10.1.2.0/24

Notes:

• --address-prefixes takes a space-separated list. That's how you give a VNet more than one address space.
• If you leave out --address-prefixes, the VNet gets 10.0.0.0/16 by default. That range may clash with your plan, so always set it.
• To add an address space later, run az network vnet update --address-prefixes ... and list all the prefixes you want to keep.
• Check the result: az network vnet show -g rg-net -n vnet-spoke1 --query addressSpace.

Step 6: Create the same VNet with Bicep

resource vnet 'Microsoft.Network/virtualNetworks@2025-09-01' = {
  name: 'vnet-spoke1'
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.1.0.0/16'
        '10.201.0.0/24'
      ]
    }
    subnets: [
      {
        name: 'snet-app'
        properties: { addressPrefix: '10.1.1.0/24' }
      }
      {
        name: 'snet-data'
        properties: { addressPrefix: '10.1.2.0/24' }
      }
    ]
  }
}

Deploy it with az deployment group create -g rg-net --template-file vnet.bicep. The VNet's ranges go in addressSpace.addressPrefixes, which is an array. Each subnet's range goes in properties.addressPrefix, which is a single string.

What the exam asks about this

• Overlap scenarios: you're given on-premises and VNet ranges and asked which design lets you peer or connect them. Look for any overlapping CIDR block.
• Usable-address maths: questions like "how many VMs fit in a /27?" Always subtract 5.
• Reserved addresses: which address Azure reserves, or which address is the first one you can assign (.4).
• Adding address space: you can add a new, non-overlapping prefix to an existing VNet. You don't have to recreate it.
• Tool syntax: recognise az network vnet create --address-prefixes and the Bicep addressSpace.addressPrefixes property.

Key takeaways

• Plan every range (hub, spokes, on-premises) before you deploy, with no overlaps and room to grow.
• A VNet can have several address spaces, and you can change them after creation.
• Azure reserves 5 addresses per subnet (the first four and the last), so usable = 2^(32 − prefix) − 5.
• The smallest subnet is /29, which leaves 3 usable addresses.
• Portal, CLI (--address-prefixes, --subnet-prefixes) and Bicep (addressPrefixes, addressPrefix) all build the same VNet.