Make data survive a regional outage, and enforce a location rule

short · 30 min · Skills measured 1.2

Before you start — what this lab needs, and what it can cost

This lab runs in your own Azure subscription: an Azure free account or a pay-as-you-go subscription, so every command acts on something real and billed to you. Charges are possible, so do the clean-up the same day; the Azure pricing calculator gives current rates for anything you are unsure of. Work in Azure Cloud Shell (Bash), opened from the Cloud Shell button in the Azure portal's top bar: it already has the Azure CLI and your sign-in, so nothing is installed and no credentials are handled. The first time it starts, choose No storage account required, so Cloud Shell itself creates nothing billable. Work with the least privilege the lab allows: assigning an Azure Policy needs more than Contributor, so you need the Owner role on the subscription, or the Contributor role together with the Resource Policy Contributor role; nothing here needs more than that, and you never need Global Administrator. On a brand-new account the first user is the subscription's Owner and the directory's Global Administrator, so if that is the only identity you have, use it carefully and only for the steps written here. This lab relies on the budget alert you set in lesson 1's lab, az900-monthly-budget, which emails you as this subscription's costs build up. A budget only warns: it never stops or deletes anything, so the clean-up is still yours to do. Every command uses the region eastus. You may choose one nearer to you, but then use it in every command of the lab, and expect your region wherever a step shows eastus. Some names must be unique across all of Azure, so they end in NNNNN: replace NNNNN with five random digits you choose, and use the same five digits everywhere in the lab.

This lab ends with a clean-up. Do it the same day: anything left running in your subscription is billed to you.

Task

Turn two of lesson 3's benefits into something you can check. For reliability, create a storage account whose copies stay in one datacenter, then convert it to geo-redundant storage and read the secondary region Azure now copies it to. For governance, assign the built-in Azure Policy "Allowed locations" to your lab's resource group and watch it refuse a resource in another region. On the way, use the pricing calculator to see that more reliability usually costs more, which is cost predictability before deployment. Finish by sorting a set of examples into availability, scalability, reliability, predictability and the two kinds of manageability.

Steps

Open Cloud Shell (Bash) and create the lab's resource group:

az group create --name az900-lab03-rg --location eastus

Create a private storage account with locally redundant storage (LRS), whose copies all sit in one datacenter, and read where its data lives:

az storage account create --name az900lab03NNNNN --resource-group az900-lab03-rg --location eastus --sku Standard_LRS --kind StorageV2 --allow-blob-public-access false --min-tls-version TLS1_2
az storage account show --name az900lab03NNNNN --resource-group az900-lab03-rg --query '[sku.name, primaryLocation, secondaryLocation]' -o tsv

The second command prints Standard_LRS and eastus, and nothing for the secondary location: there is no copy outside this region. 3. Make the data survive the loss of the whole region. Convert the account to geo-redundant storage (GRS) and read it again:

az storage account update --name az900lab03NNNNN --resource-group az900-lab03-rg --sku Standard_GRS
az storage account show --name az900lab03NNNNN --resource-group az900-lab03-rg --query '[sku.name, primaryLocation, secondaryLocation]' -o tsv

It now prints Standard_GRS, eastus and westus: Azure copies this account's data to a second region far from the first. That is reliability, and it happened because you configured it. Azure does not copy every resource to another region by itself. 4. Add a governance rule. Assign the built-in policy definition "Allowed locations" to this resource group only, allowing eastus and nothing else:

az policy assignment create --name az900-lab03-allowed-locations --display-name "Allowed locations: eastus only" --policy e56962a6-4747-49cd-b67b-bf8b01975c4c --resource-group az900-lab03-rg --params '{"listOfAllowedLocations": {"value": ["eastus"]}}'

A new assignment can take some minutes to start denying requests, so do step 5 before you test it. 5. See cost predictability before deployment while the policy takes effect. Open the Azure pricing calculator in a new tab (no sign-in needed) and add Storage Accounts. Set the region to East US, then switch Redundancy between LRS and GRS and watch the estimate change. Write down only which is higher, not the figures. Geo-redundancy buys reliability, and it usually adds cost rather than saving it. After deployment, Cost Management's Cost analysis shows what resources have actually cost, and the budget from lesson 1 alerts you as spending nears its limit. 6. Test the rule. Try to create a second storage account in another region, in the same resource group:

az storage account create --name az900lab03NNNNN9 --resource-group az900-lab03-rg --location westus --sku Standard_LRS --allow-blob-public-access false

Azure refuses it with the error code RequestDisallowedByPolicy. That is governance that is enforced rather than hoped for: whoever tries, the resource is never created. If the account is created instead, the assignment had not taken effect yet: delete it with az storage account delete --name az900lab03NNNNN9 --resource-group az900-lab03-rg --yes, wait five minutes and try again. 7. Sort each example into high availability, scalability, reliability, performance predictability, cost predictability, management of the cloud, or management in the cloud. (a) Two VMs behind Azure Load Balancer, so one can fail without users noticing. (b) A copy of an application in a second region to fail over to after a disaster. (c) Adding web app instances for a yearly sale and removing them afterwards. (d) The pricing calculator, used before anything is built. (e) A metric alert that tells the operations team when a VM's CPU stays high. (f) The Azure CLI commands you have just run. (g) The geo-redundant storage you configured in step 3. Check your answers in the Notes.

Verify

Read the policy assignment's allowed region:

az policy assignment show --name az900-lab03-allowed-locations --resource-group az900-lab03-rg --query 'parameters.listOfAllowedLocations.value[0]' -o tsv

Expected output: eastus.

Confirm the storage account is geo-redundant:

az storage account show --name az900lab03NNNNN --resource-group az900-lab03-rg --query sku.name -o tsv

Expected output: Standard_GRS.

Confirm the policy kept the second account out:

az storage account list --resource-group az900-lab03-rg --query 'length(@)' -o tsv

Expected output: 1.

Cost and clean-up

Charges are possible but small: a storage account holding no data is billed for little more than the requests made to it, and geo-redundancy costs more per gigabyte stored than local redundancy. Policy assignments of built-in definitions carry no charge. Delete everything the same day.

Created by this lab: the resource group az900-lab03-rg; the storage account az900lab03NNNNN, converted to geo-redundant storage; the policy assignment az900-lab03-allowed-locations on the resource group; the storage account az900lab03NNNNN9, only if step 6 ran before the policy took effect.

Delete the policy assignment by name. A policy assignment is not an ordinary resource in the group, so remove it explicitly first:

az policy assignment delete --name az900-lab03-allowed-locations --resource-group az900-lab03-rg

Delete the resource group, which deletes the storage account az900lab03NNNNN, and az900lab03NNNNN9 if it exists, with it:

az group delete --name az900-lab03-rg --yes

Close the pricing calculator tab without saving anything.

Check it is gone

az group exists --name az900-lab03-rg

Expected output: false.

Notes

Step 7 answers. (a) High availability: no single point of failure. (b) Reliability: recovering from a larger event. (c) Scalability, here scaling out and in; done automatically it is autoscaling, or elasticity. (d) Cost predictability, before deployment; Cost Management budgets and alerts give it after deployment. (e) Management of the cloud: something the platform does with the resources. (f) Management in the cloud: a tool you use to do the work, like the portal, Azure PowerShell and the REST APIs. (g) Reliability: geo-redundant storage keeps the data through the loss of the primary region; zone-redundant storage would survive a datacenter, but not a region.

Azure Policy controls what resources may look like, such as where they are deployed, whoever creates them. Azure role-based access control (RBAC) controls what people may do. A rule for many subscriptions goes on a management group instead of one resource group.

The policy definition ID e56962a6-4747-49cd-b67b-bf8b01975c4c is the built-in "Allowed locations". az policy definition show --name e56962a6-4747-49cd-b67b-bf8b01975c4c --query displayName -o tsv prints its name. The secondary region in step 3 is Microsoft's fixed pair for your primary region: westus for eastus. If you chose another region, you will see its pair.

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.