Read Azure's physical footprint, then place a zonal and a zone-redundant resource

short · 25 min · Skills measured 2.1

Task

Use read-only commands to see Azure's physical footprint from your own subscription: how many regions you can deploy to, which geography and which physical location a region sits in, which region Microsoft paired it with, and whether it has availability zones. Then make the difference between zonal and zone-redundant concrete: create a small managed disk pinned to zone 1, and a storage account whose data is copied across the region's zones. Finish by naming the sovereign clouds your CLI knows about, and by matching six failures and requirements to the layer that handles them.

Steps

  1. Open Cloud Shell (Bash) and count the regions your subscription can deploy to, then list them with their geography group:
az account list-locations --query 'length([?metadata.regionType==`Physical`])' -o tsv
az account list-locations --query '[?metadata.regionType==`Physical`].{name:name, display:displayName, geography:metadata.geographyGroup}' -o table

Each row is a region: one or more datacenters close enough to be linked by a fast, low-latency network. The geography column groups them into markets such as US and Europe, which are also the data residency boundaries. 2. Read one region's place in the world and its pair:

az account list-locations --query '[?name==`eastus`].[displayName, metadata.physicalLocation, metadata.pairedRegion[0].name]' -o tsv

It prints East US, Virginia and westus. The physical location is a state, never a street address: customers deploy to a region and Azure picks the datacenter. Microsoft sets the pair, and you cannot choose another one. Platform updates go to one region of a pair at a time, and in a broad outage one region of each pair is restored first. 3. See which regions have availability zones. Read the zones of eastus, then of its pair:

az account list-locations --query '[?name==`eastus`].availabilityZoneMappings[].logicalZone' -o tsv
az account list-locations --query '[?name==`westus`].availabilityZoneMappings[].logicalZone' -o tsv

The first prints 1, 2 and 3, one per line: a region that has zones has at least three. The second prints nothing, because West US has no availability zones. Not every region has zones, and not every region is paired either. If the first command also prints nothing, your CLI does not show that field yet; step 5 still proves the zones are there. 4. Create the lab's resource group and a zone-redundant storage account, whose data Azure copies synchronously across the region's three zones:

az group create --name az900-lab05-rg --location eastus
az storage account create --name az900lab05NNNNN --resource-group az900-lab05-rg --location eastus --sku Standard_ZRS --kind StorageV2 --allow-blob-public-access false --min-tls-version TLS1_2

This account keeps working if one datacenter in the region fails, and every copy stays inside eastus, which suits a rule that data must stay in one region. 5. Create a zonal resource: a small, empty managed disk pinned to zone 1:

az disk create --resource-group az900-lab05-rg --name az900-lab05-disk --location eastus --size-gb 4 --sku Standard_LRS --zone 1
az disk show --resource-group az900-lab05-rg --name az900-lab05-disk --query zones -o tsv

The second command prints 1. A zonal resource lives in the one zone you chose: if zone 1 failed, this disk would be unavailable until it recovered. To survive a zone failure with zonal resources, you deploy more than one and place them in different zones. 6. Name the clouds that are not public Azure, and see a non-regional service:

az cloud list --query '[].name' -o tsv
az ad signed-in-user show --query userPrincipalName -o tsv

The first list includes AzureCloud, the public cloud you are using, and AzureUSGovernment and AzureChinaCloud: sovereign clouds, physically and logically isolated from public Azure, with their own accounts and portals. Your account cannot sign in to them, and this lab never switches to them. The second command answered from Microsoft Entra ID, a non-regional service: you never chose a region for it. 7. Match each failure or requirement to the layer that handles it: an availability set, availability zones, a region pair, a sovereign region, or a different region. (a) One rack in a datacenter loses power. (b) A whole datacenter in the region loses power. (c) A disaster takes out the entire region. (d) A US agency needs isolation from public Azure, run by screened US personnel. (e) Customers in Japan find an app in East US slow. (f) A Canadian bank's records must stay in Canada. Check your answers in the Notes.

Verify

Confirm the zonal disk and the zone-redundant account:

az disk show --resource-group az900-lab05-rg --name az900-lab05-disk --query 'zones[0]' -o tsv

Expected output: 1.

az storage account show --name az900lab05NNNNN --resource-group az900-lab05-rg --query sku.name -o tsv

Expected output: Standard_ZRS.

Confirm which cloud you are in, and the pair you read:

az cloud show --query name -o tsv

Expected output: AzureCloud.

az account list-locations --query '[?name==`eastus`].metadata.pairedRegion[0].name' -o tsv

Expected output: westus.

Cost and clean-up

Charges are possible but small: the managed disk is billed for as long as it exists, even empty and attached to nothing, and the storage account for what it stores and the requests made to it. Every other step only reads. Delete the resource group the same day.

Created by this lab: the resource group az900-lab05-rg; the zone-redundant storage account az900lab05NNNNN; the zonal managed disk az900-lab05-disk in zone 1.

  1. Delete the resource group, which deletes the disk az900-lab05-disk and the storage account az900lab05NNNNN with it:
az group delete --name az900-lab05-rg --yes

Check it is gone

az group exists --name az900-lab05-rg

Expected output: false.

Notes

Step 7 answers. (a) An availability set: fault domains inside one datacenter. (b) Availability zones, or zone-redundant storage like the account you made. (c) The paired region, through geo-replication and Microsoft's recovery priority. (d) A sovereign region: Azure Government. A region pair inside the United States is still public Azure. (e) A different region, closer to Japan. More zones or bigger VMs do not shorten the distance. (f) A region physically in Canada.

The physical layers stack up: datacenters make up availability zones, zones (or the datacenters themselves, in a region without zones) make up a region, and regions are grouped into geographies, many of them in pairs. A resource group is none of these: it is a logical container with no physical existence.

Zone numbers are logical. Zone 1 in your subscription is not necessarily the same building as zone 1 in someone else's, which is what the availability zone mappings in step 3 record.

If you chose a region other than eastus, step 2 and Verify print your region's pair, step 3 may print nothing if your region has no zones, and step 5 then fails with a zone error: use a region with zones for this lab.

This is an independent study companion for the Microsoft Azure Fundamentals (AZ-900) exam and is not produced by or endorsed by Microsoft. Microsoft, Azure and Microsoft Entra are trademarks of the Microsoft group of companies.

This is an independent study companion for Microsoft Azure Fundamentals AZ-900 and is not produced by or endorsed by CompTIA.