Build Lab — Make the secondary region unreadable, then readable

Build brief

Unit: 3 — Business continuity
You need: Your own Azure subscription
Time: 15 minutes
Cost: Pennies — a few KB stored, deleted at the end
Interface: Azure CLI

This is the hands-on twin of the redundancy question in "Match the mechanism to the RTO and the RPO". That drill claimed GRS gives you a copy in another region that you cannot read, and that reading it requires the RA- variants. Claims like that are easy to nod at and easy to forget. Here you watch a storage account acquire a secondary endpoint, get refused when you read it, and then succeed after one SKU change.

Before you start

Azure CLI, and az login completed.
A storage account name must be globally unique, 3-24 characters, lowercase letters and numbers only. Every command below uses bblabstore plus a suffix you choose — replace NNNN with four digits of your own throughout.

What you are building

Loading Diagram...

Figure 1 — Mermaid diagram

Step 1 — create the account deliberately as LRS

bash

az group create --name bb-lab-redundancy --location westeurope

az storage account create \
  --name bblabstoreNNNN \
  --resource-group bb-lab-redundancy \
  --location westeurope \
  --sku Standard_LRS

Note the explicit --sku. The CLI documents that a storage account's SKU defaults to Standard_RAGRS — so if you omit it you start at the end of this lab and never see the interesting part. That default is also worth remembering on its own: the portal and CLI hand you geo-redundancy unless you say otherwise, which is a cost surprise in the other direction.

Step 2 — confirm there is no secondary at all

bash

az storage account show \
  --name bblabstoreNNNN \
  --resource-group bb-lab-redundancy \
  --query "{sku:sku.name, primary:primaryEndpoints.blob, secondary:secondaryEndpoints}" -o json

secondary is null. LRS keeps three copies inside one region — durable against drive and rack failure, and nothing at all against losing the region.

Step 3 — upload something to find later

bash

echo "parcel 4471 delivered" > claim.txt

az storage blob upload \
  --account-name bblabstoreNNNN \
  --container-name evidence \
  --name claim.txt \
  --file claim.txt \
  --auth-mode login

If the container does not exist yet:

bash

az storage container create \
  --account-name bblabstoreNNNN \
  --name evidence \
  --auth-mode login

Step 4 — upgrade to GRS and look again

bash

az storage account update \
  --name bblabstoreNNNN \
  --resource-group bb-lab-redundancy \
  --sku Standard_GRS

az storage account show \
  --name bblabstoreNNNN \
  --resource-group bb-lab-redundancy \
  --query "{sku:sku.name, secondary:secondaryEndpoints.blob}" -o json

A secondary endpoint URL now exists. A copy of your blob is in the paired region. Try to read it:

bash

curl -s -o /dev/null -w "%{http_code}\n" \
  "$(az storage account show --name bblabstoreNNNN --resource-group bb-lab-redundancy --query secondaryEndpoints.blob -o tsv)evidence/claim.txt"

Checkpoint — the moment worth pausing on

That request does not return your file. The endpoint exists, the data exists behind it, and you cannot read it. Sit with that for a second: the copy being present and the copy being reachable are two different things, and GRS gives you only the first. Every exam question that offers GRS for a "must remain readable during a regional outage" requirement is built on people conflating them.

Now change one thing:

bash

az storage account update \
  --name bblabstoreNNNN \
  --resource-group bb-lab-redundancy \
  --sku Standard_RAGRS

Wait a moment, then run the same curl again. Anonymous access may still be refused depending on your account's public-access settings — the meaningful change is that read-access to the secondary is now permitted by the SKU. To read it as yourself:

bash

az storage blob download \
  --account-name bblabstoreNNNN \
  --container-name evidence \
  --name claim.txt \
  --file from-secondary.txt \
  --auth-mode login

Why this matters on the exam

Multiple answer · MediumStorage redundancy

Based on what you just observed, which statements are true? Select all that apply.

Select all that apply

Teardown

bash

az group delete --name bb-lab-redundancy --yes --no-wait
rm -f claim.txt from-secondary.txt

Confirm it is going:

bash

az group exists --name bb-lab-redundancy

If it did not work

Three failures and what each one teaches

'The storage account name is already taken'
Account names are globally unique across all of Azure, not merely within your subscription — the same property that makes the endpoint a public DNS name. Pick different digits and continue.

Return to "Match the mechanism to the RTO and the RPO" and re-answer its redundancy card. You should now be able to say precisely what RA- buys, and why a durability figure is not an answer to an availability requirement — because you tried to read the copy and were refused.

Build Lab — Make the secondary region unreadable, then readable

Build Lab — Make the secondary region unreadable, then readable

Build brief

Before you start

What you are building

Step 1 — create the account deliberately as LRS

Step 2 — confirm there is no secondary at all

Step 3 — upload something to find later

Step 4 — upgrade to GRS and look again

Checkpoint — the moment worth pausing on

Why this matters on the exam

Teardown

If it did not work

Three failures and what each one teaches

'The storage account name is already taken'

Next