Create a storage account, walk redundancy and access tiers, and upload a blob.
One account, four kinds of room
A storage account is an Azure resource with a name, region, security settings, and a redundancy choice. A standard general-purpose v2 account can offer four services. Think of them as four tools: Blob stores objects such as photos, File provides shared folders, Queue passes small messages between programs, and Table stores records you look up by key. First choose the tool that matches the data. Then decide whether the services belong in one account or need separate settings.
- Storage account
- An Azure resource that can provide Blob, File, Queue and Table services under one account name. The account's redundancy setting applies to its data; each service also has its own access controls.
Blob is object storage for data such as images, video, and backups. File is a managed network file share for software that expects a folder. Queue holds small messages until another program processes them. Table holds non-relational records looked up by keys. This class spends most of its time on Blob because its access tiers and anonymous-read setting need careful choices. Account-level settings can affect multiple services, but each service also has distinct permissions.
Which building you are renting: kind and performance
Before any door opens, choose the account type and performance. Standard general-purpose v2 (StorageV2) is Microsoft's recommendation for most workloads. It offers Blob, File, Queue and Table services and a broad choice of redundancy options. Access tiers apply to eligible blobs, not to every object in the account.
Premium accounts serve workloads with specific latency and throughput needs. Premium block blob and premium file share accounts support different services and features. Compare the measured workload and current regional pricing before paying for one; do not assume a fixed price multiple.
Account type limits later choices. Premium block blob and file accounts offer LRS or ZRS where supported, not geo redundancy; premium block blobs cannot use Hot, Cool, Cold or Archive tiering. Check the supported migration path before changing an existing account's type or performance.4
Redundancy is a dial with a price
Azure copies data according to the storage account's redundancy setting. The question is how far apart the copies sit, what outage you need to handle, and what each option costs. Figure 2 shows the locations; the setting applies to the account, not to each blob separately.
- Redundancy
- How many copies of your data Azure keeps, and how far apart. More distance survives larger disasters — a failed disk, a lost datacentre, an entire region offline — at steadily higher cost.
| Option | Copies | Protects against |
|---|---|---|
| LRS — local | 3, one datacenter | A failed disk or rack |
| ZRS — zone | 3, across zones in one region | An entire zone lost |
| GRS — geo | 6, across two regions | Primary-region loss, subject to asynchronous copy and failover |
| GZRS — geo + zone | Zone-spread, plus a second region | Zone or primary-region loss, subject to asynchronous copy and failover |
Match the account's redundancy to its datasets and recovery target. If exports require geo copies but images can be rebuilt locally, place them in separate storage accounts so each can have the right setting. A geo copy does not replace backup: deletion or corruption can also replicate. Not every redundancy option supports every blob tier.1
Tiers, and the truth about getting data back
Not all data is touched equally. A blob storage account lets you place each object in an access tier that trades storage price against access price — cheaper to keep, dearer to read, the further down you go.
| Tier | For | Min. retention | Getting it back |
|---|---|---|---|
| Hot | Data read often | None | Instant |
| Cool | Infrequent, kept ~30+ days | 30 days | Instant, higher read cost |
| Cold | Rare, kept ~90+ days | 90 days | Instant, higher read cost |
| Archive | Almost never, compliance | 180 days | Hours — must rehydrate first |
Two truths matter more than the prices. First, the minimum retention: move a blob to Cool and delete it a week later and you are still billed as though it stayed 30 days — the cheaper tiers assume you meant it, and punish churn. Second, and the one that ends careers when forgotten: Archive is offline. You cannot read an archived blob at all; you must first rehydrate it to an online tier, which can take many hours.2 Archive is superb for "the law says keep this for seven years and we hope never to look at it" and catastrophic for anything you might need in a hurry. Put your only backup in Archive and discover, mid-incident, that restoring it starts with a wait measured in hours, not minutes.
Move data to cheaper tiers only when its access pattern and restore target justify the move. A lifecycle policy can automate that decision for eligible blobs, but you still need to review the rule and its results.
Three ways in, and a clear order of preference
These are three common ways to authorize access to storage data. Each grants a different amount of control:
- Account keys
- Shared keys grant broad access to the account's data. Treat them as powerful long-lived secrets; restrict access, rotate after suspected compromise, and never put them in application source.
- SAS tokens
- A shared access signature can grant limited, expiring access to selected storage data. For Blob data, prefer a user delegation SAS signed through Entra credentials when direct identity access is not possible. Anyone holding a valid SAS can use its permissions.
- Entra ID + RBAC
- Grant a role such as Storage Blob Data Reader to an identity — ideally a managed identity — so access is governed by Class Eight's roles and carries no stored secret at all. The top of the ladder.
- SAS
- A signed token placed in a storage URL. Its permissions, resource scope, lifetime, and signing method determine its risk. Treat the URL as a secret.
For an Azure-hosted app, start with Entra RBAC and a managed identity, scoped to the data it needs. Use a short-lived, narrowly scoped SAS when a client cannot use that identity; prefer user delegation for Blob data. Keep account keys as a last resort. This identity choice is separate from network access: an authorized app still needs a network path to the storage endpoint.6
The public-container epidemic
An accidentally public container can expose sensitive blobs without a password. This can happen when an authorized user changes a container's access level to allow anonymous read. You need to check the container setting and the account setting together.
Private data needs two checks: the container and its account.
A new container is private by default. That is different from the account-level setting: Microsoft's storage-account create flow currently allows an authorized user to enable anonymous access on individual containers by default. A container becomes publicly readable only when someone explicitly changes its access level. For private data, also disable anonymous access at the account level so that change cannot be made accidentally.3 Check both settings on existing accounts instead of trusting a default.
Filing Campux's data correctly
Campux's product images belong in one Blob account. The storefront reads private blobs using its managed identity and a data-reader role. Frequently read images stay Hot; older, rarely viewed images can move to Cool if the total storage and retrieval cost is lower. The nightly POS exports belong in a separate account if they need a different redundancy setting. After the business confirms its retention and recovery needs, older exports may move to Archive if a rehydration wait is acceptable.
A lifecycle policy can move eligible blobs between tiers and delete them according to rules you configure. Test the rules against legal retention and restore needs; monitor their results. Choose redundancy per account: for example, a geo-redundant export account and a lower-cost image account if images can be rebuilt. If exports must enter Archive, choose a geo configuration that supports Archive, such as GRS rather than GZRS.
Next class gives all of this a front door and learns to spread traffic across it.
The official module, and a CAMPUX overview
Create an Azure storage account (docs)
learn.microsoft.com/azure/storage/common/storage-account-create
Security depth: Secure your Azure Storage account
learn.microsoft.com/training/modules/secure-azure-storage-account/
A short walkthrough of redundancy, access tiers, and the public-container setting will live here. Video to be added.
Play it through
Work through an intentionally misconfigured account. Close anonymous access, choose a geo copy, and see what the secondary can and cannot do during a regional outage. The activity pauses for your choices.
Create a storage account the CLI way — closed by default
The game was a model; now create a temporary account. Choose its redundancy, give your signed-in identity a Blob data role, make a private container without retrieving an account key, and confirm anonymous access is disabled.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)
Create a group and a storage account, choosing redundancy explicitly and forbidding anonymous access:
az group create --name rg-campux-lab --location eastus SA=campuxlab$RANDOM az storage account create --name $SA --resource-group rg-campux-lab \ --location eastus --sku Standard_LRS \ --allow-blob-public-access false
What just happened: Standard_LRS is the cheapest rung of the redundancy dial — three copies in one datacenter. Swap it for Standard_GRS to reach a second region. And --allow-blob-public-access false shuts the public-container door at the account level.Before using your Entra identity for Blob data, assign it the Storage Blob Data Contributor role at this temporary account. Creating the account does not automatically grant a Blob data role. This step requires permission to assign roles; ask your lab administrator if you do not have it. Role changes can take a few minutes to propagate.
ACCOUNT_ID=$(az storage account show --name "$SA" \ --resource-group rg-campux-lab --query id -o tsv) MY_ID=$(az ad signed-in-user show --query id -o tsv) az role assignment create --assignee-object-id "$MY_ID" \ --assignee-principal-type User --role "Storage Blob Data Contributor" \ --scope "$ACCOUNT_ID"
Then create a container using that identity, not a key:
az storage container create --account-name $SA \ --name images --public-access off --auth-mode login
On screen: --auth-mode login uses your signed-in identity and RBAC — the top of Class Nine's hygiene ladder. You never fetched an account key, which is exactly the point.Confirm the redundancy and the closed door:
az storage account show --name $SA --resource-group rg-campux-lab \ --query "{sku:sku.name, publicAccess:allowBlobPublicAccess}"The lesson: allowBlobPublicAccess: false means no container here can be opened to the internet even by mistake — a leak is now a deliberate act, not an accident.Tear down:
az group delete --name rg-campux-lab --yes --no-wait
Create a storage account by hand
Now build it by clicking — the Basics tab is where you turn the redundancy dial, and an Advanced toggle is where you keep the public door shut. Use a throwaway resource group.
Go to portal.azure.com and sign in.
In the search bar at the top, type Storage accounts, select it, then click + Create.
Basics tab: subscription, a throwaway resource group, a unique account name, a region, and the Redundancy dropdown.On screen: the Redundancy dropdown is the paranoia dial itself — LRS, ZRS, GRS, GZRS, priced from cheapest to dearest. Pick LRS for a throwaway; note that GRS/GZRS are what survive a whole region failing.
Advanced tab: uncheck Allow enabling anonymous access on individual containers.On screen: this account-level option is enabled by default in Microsoft's documented create flow. Individual containers are private by default, but disabling the account option prevents an authorized user from later making one public.
Review + create, then Create. Open the account, go to Containers, and add one named images.On screen: when you create the container, the "Public access level" is fixed to Private because you disabled anonymous access on the account — the setting cascades exactly as intended.
Tear down: delete the throwaway resource group.
Portal wording drifts; if a label here does not match your screen, the anchors are the Storage accounts create flow, the Redundancy dropdown, and the anonymous-access toggle on Advanced.
Read redundancy, tiers, and the door on the blades
Open the account you built and let each blade confirm a fact from the class.
On the storage account, read the Overview and Redundancy blades.On screen: the redundancy setting, and — for a geo option — the primary and secondary regions drawn out. This is Figure 2 for your own account.
Open Configuration and find the default access tier (Hot / Cool / Cold).On screen: the tier dial that trades storage cost against access cost. Remember Archive is set per blob and is offline — reading it means hours of rehydration.
Open Networking, then Containers, and read the access posture.On screen: public network access and the per-container "Public access: Private" — the whole security story of the account at a glance, with the public door shut.
Open Data protection and note soft delete and versioning.The point: redundancy is not backup. Soft delete and versioning are what protect you from a human deleting a blob — a different problem from a datacenter failing, needing a different switch.
Zoom out: storage is the one thing you cannot redeploy, wearing four doors
You can tell blob from file from queue from table. Now reason about what a storage account does to the whole system, because its contents are the unrepeatable memory of the business — and its weakest setting is the estate's exposure.
Storage is cheap per gigabyte, so nobody deletes anything, so the account fills with data nobody queries and the bill and the blast radius both grow. What lifecycle rule trims it before it becomes the audit finding?
Services in one account share the account's redundancy and some network and authorization settings. Service-specific permissions still differ. Separate accounts when one dataset needs a different recovery or access boundary.
Sensitive data needs a tested access and recovery design. Check who can read it, what happens after deletion or corruption, and how quickly it can be restored.
Tiering to cool and archive saves money and quietly adds latency and retrieval cost — so the "cheap" archive becomes expensive the day someone needs it fast. You bought storage savings with retrieval risk.
Access decided per container by hand is fine at three and unauditable at three hundred — which is why "no public access" has to be a policy on the account, enforced, before the estate outgrows the eye that would catch a mistake.
The engineer who ships is asked "is it stored?" The engineer who gets promoted is asked "and who can read it that shouldn't?" — and closed the public door by rule, not by hope.
Matching the blast radius to the value
A stakeholder asks, "What happens to our files if a datacenter fails?" Check the current account's redundancy, where its copies live, and the application's recovery target. If irreplaceable records need geo copies while scratch files do not, place them in separate accounts with suitable settings. Test backup and restore separately.
This is the whiteboard round of an interview. Rehearse it where it is cheap.
Check both settings. A container is private by default, but an authorized user may make it public if the account permits that change. Disable anonymous access on the account for private data and verify the container itself is private. Network rules and identity roles are separate controls; draw them only when you can explain what each protects.
Examination
The Whiteboard above, four drills here, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
C. GRS copies data to a second region; LRS and ZRS do not. Geo-copying is asynchronous, so recent writes can be lost in a regional disaster. Plain GRS does not allow reads from the secondary until failover. RA-GRS or RA-GZRS allows secondary reads, but your application must use that endpoint and plan for unavailable writes.
B. LRS keeps its three copies in one datacenter, so a zone failure can take all of them; ZRS spreads copies across zones, surviving one zone going dark. A overstates it — neither LRS nor ZRS crosses into a second region, so neither survives a full regional loss. C and D are the important reminder that redundancy is not backup or security: copies protect against infrastructure failure, not against a human deleting data or a stolen key. Those need soft-delete, versioning, and the access controls of §4 — different problems, different tools.
Archive needs rehydration, Cool has a 30-day minimum, and a properly scoped SAS can expire. New containers are private by default, even though Microsoft's account-create flow currently allows an authorized user to enable anonymous access later. An account key grants broad account-data access, not read-only access to one container.
SAS — partner upload to 'inbound' container
1. Permissions: write, list (this container only)
2. Start time: now
3. Expiry: now + 10 years
4. Allowed IPs: the partner's published address range
Line three. A ten-year token remains usable far beyond this upload task if it is leaked and the account's policies permit that lifetime. Use the shortest lifetime that meets the partner's transfer window, require HTTPS, and plan how to revoke it. Also question line one's list permission if the partner only needs to upload.
For Blob uploads, prefer a user delegation SAS where possible. A service SAS tied to a stored access policy may be revoked through that policy; other SAS forms have different revocation options. Do not assume every key-signed SAS requires rotating the account key.6
Close it first; investigate second. The bleeding stops before the autopsy — set the container back to private and, better, disable anonymous access at the account level so it cannot recur. Every minute spent investigating while it is still open is another minute of exposure. This ordering is the whole discipline of an incident: contain, then understand.
Then find out how bad, assuming the worst. Anything public should be treated as already copied and indexed — search logs for access, check whether it was crawled, and determine exactly what customer data those exports contained, because that scopes your breach-notification obligations. "It was probably fine" is not a finding; the logs are.
Then remediate the cause, not just the instance. Rotate or invalidate anything sensitive that was exposed, and prevent recurrence with an Azure Policy that denies public access across every account — the Class Eight move that turns "we closed it" into "it cannot be opened." Close the door, learn what left through it, then take the handle off. In that order.
This is the "to be safe" instinct again, now spending on distance. GZRS everywhere feels responsible, but redundancy is a dial with a price, and paying the top rate to protect data you could regenerate in an afternoon is waste dressed as prudence. The question is never "could we lose it" but "what does losing it actually cost" — and for a cache or a build artifact, the answer is close to nothing.
Separate workloads when their needs differ. Redundancy is set on the storage account, so put records that need geo copies in a suitable account and rebuildable logs or caches in another account with the appropriate local or zone setting. Check whether each account's tiers and regional availability fit its data.
Show the cost and recovery tradeoff. Estimate stored bytes, reads, writes, retrieval fees, and each candidate account's current regional pricing. Document recovery targets and test restore. GZRS does not prevent accidental deletion or corruption from replicating.
Five things worth carrying out of this class
- One storage account, four services: Blob, File, Queue, Table. Blob — object storage — is where the volume, money and incidents live.
- Redundancy is set per account: LRS keeps local copies, ZRS spreads copies across zones, and GRS/GZRS add a second region. Geo-copying is asynchronous; separate datasets when their needs differ.
- Tiers trade storage cost for access cost. Cheaper tiers have minimum retention, and Archive is offline — reading it means hours of rehydration.
- Reach for Entra RBAC with a managed identity first, a scoped short-lived SAS when you must, and account keys almost never.
- A new container is private by default, but the account may permit someone to change that. For private data, disable anonymous access at the account and verify each container.
- Microsoft lists Archive support for LRS, GRS and RA-GRS, not ZRS, GZRS or RA-GZRS. Check tier and redundancy compatibility before designing a lifecycle policy. ↩
- Microsoft explains Archive rehydration and minimum retention. Test restore time against your recovery target rather than storing the only quickly needed copy offline. ↩
- Microsoft's account create guide shows the account-level option to permit anonymous containers as enabled by default, while its anonymous access guide says each container is private by default. These are separate controls. ↩
- Microsoft's account-type matrix lists the supported redundancy options for standard and premium accounts. ↩
- Microsoft's redundancy guide covers asynchronous geo-copying, read-access variants, and secondary-region behavior. ↩
- Microsoft documents SAS signing and revocation options and the Blob data role needed for CLI login authorization. ↩
Choose a storage account, separate datasets that need different redundancy, and check both anonymous-access controls.
Play the lesson above to stamp this class.