Create a storage account, walk redundancy and access tiers, and upload a blob.
One account, four kinds of room
Think of a well-run warehouse. It has open shelving for boxes you fetch constantly, a loading dock where deliveries queue to be processed, a card index for looking things up, and a shared cupboard the office all reaches into. One building, one address, but four quite different ways of keeping things — and a good warehouse manager never confuses the loading dock with the shelves. An Azure storage account is that building: a single namespace that offers four distinct services, and the first skill is knowing which door a given thing goes through.
- Storage account
- A single Azure resource providing four data services under one name — Blob, File, Queue and Table — each with its own shape, its own use, and one shared set of security and redundancy settings.
The four doors, briefly, because picking the wrong one is a common early error. Blob is object storage — unstructured files: images, video, backups, logs — and the one you will reach for most. File is a managed network file share, mountable like a drive, for when existing software expects a folder. Queue is simple messaging, a buffer of small messages between parts of a system. Table is a basic key-value store for structured, non-relational data. Most of this class is really about Blob, because it is where the volume, the money and the security incidents live — but knowing the account holds all four, under one set of controls, is the frame everything else hangs on.
Which building you are renting: kind and performance
Before any door opens, the create flow asks a question this class has so far skipped past: what kind of account, at what performance. The default — and the right answer nearly every time — is StorageV2, general-purpose, standard performance: all four services under one roof, the full redundancy dial, every access tier. When an engineer says "a storage account" with no qualifier, this is the account they mean, and it is the one Campux runs.
The alternatives are specialists built on premium performance — SSD-backed, priced for speed rather than volume. A premium block blob account serves workloads that hammer small objects and cannot wait — interactive analytics, high-frequency logging. A premium file share account does the same for SMB shares that back latency-sensitive applications. They are single-purpose buildings: one door each, tuned hard, at several times the standard price per gigabyte kept.
The reason to meet this decision before the portal shows it to you: the kind-and-performance choice gates everything after it. Premium accounts offer only local and zone redundancy — no geo options — and the Hot, Cool and Archive tiers of §3 belong to standard general-purpose accounts; a premium block blob has no tiers to fall through. And the choice does not bend afterward: there is no in-place conversion between standard and premium, only a new account and a copy of every byte. It is the first dropdown on the form, and the one you cannot quietly change your mind about.
Redundancy is a dial with a price
Your data is copied for you — the question is only how far apart the copies sit, and each answer costs more than the last. Redundancy is a paranoia dial, and Figure 7 draws what each setting actually survives.
- 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 | Survives |
|---|---|---|
| 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 | The whole primary region lost |
| GZRS — geo + zone | Zone-spread, plus a second region | A zone loss and a region loss |
The judgement is the same one Class Two taught about nines: match the spend to the disaster you must actually survive, not to the worst you can imagine. Irreplaceable customer data may earn geo-redundancy; a cache you could regenerate in an afternoon does not. Turning the dial to maximum "to be safe" is the storage version of the oversized VM — safety in one direction, a bill in the other. And the dial interacts with the tiers of §3: not every redundancy option carries every tier.3
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.1 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.
The right posture is to let data cool as it ages, on purpose — which is what a lifecycle policy, in §5, automates.
Three ways in, and a clear order of preference
A storage account can be reached three ways, and Class Nine's hygiene ladder decides which you should reach for. From most dangerous to best:
- Account keys
- Two master keys that grant total control of the whole account. Powerful, and exactly the long-lived secret you were taught to fear — leak one and the account is wholly compromised. Avoid embedding them anywhere.
- SAS tokens
- A shared access signature — a URL granting scoped, time-limited access to specific data. Far better than a key when you must hand out access, provided it is narrow and short-lived.
- 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 shared access signature: a signed URL that grants limited, expiring access to storage without revealing an account key. Its safety lives entirely in its scope and its expiry.
The preference order is the whole point. Reach for Entra RBAC with a managed identity first — Campux's storefront reads its images exactly this way, holding no secret. Use a SAS when you genuinely must grant an outside party temporary access, and keep it tight and brief. Treat account keys as a last resort, rotated and never pasted into code. The account key in a config file from Class Nine's drill was a storage account key; this is the service it opened, and now you can see exactly how much it gave away.
The public-container epidemic
More organisations have been breached by a storage container left open to the internet than by any clever exploit. It is the single most common cloud data leak, and it happens the same way every time: a container's access level is set to allow anonymous public read "just to make something work," and months later a researcher — or someone worse — finds it indexed and open.
A public container is a breach you scheduled.
Microsoft has moved the floor in your favour: new storage accounts now prohibit anonymous access by default, so exposing a container is a deliberate act of switching a guard off, not an accident of leaving one on.2 But defaults protect only the accounts nobody overrode. The professional posture is to keep anonymous access disabled at the account level entirely — so it cannot be turned on per-container even by mistake — and to serve genuinely public content through a proper front door with its own controls, not by flinging a container open. This is Class One's lesson in its most literal form: the provider is not breached; a configuration is. The container that leaks was set to leak by someone who meant only to be quick.
Filing Campux's data correctly
Campux's product images go into Blob storage, read by the storefront through its managed identity and an Entra role — no key, no SAS, no public container. Current-season images sit in Hot; last season's, still occasionally viewed, belong in Cool. The nightly POS exports — written once, read almost never, but kept for reconciliation — land straight in Cool, and roll to Archive once they age past the point of likely use, since a wait to rehydrate an eighteen-month-old export is perfectly acceptable.
Rather than move blobs by hand, you write a lifecycle policy: a rule that automatically transitions objects Hot → Cool → Archive as they pass age thresholds, and deletes them when retention allows. It is the storage twin of the autoscale rule from last class — governance you configure once and never babysit. Redundancy is set per data, not per nerve: geo-redundant for the exports that must survive a regional disaster, cheaper local redundancy for images that could be re-uploaded. Everything filed by how it is actually used, which is the whole discipline of this class.
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.
Create a storage account the CLI way — closed by default
You will create an account, choose its redundancy, make a container reached by your Entra identity rather than a key, and confirm anonymous public access is off — the epidemic from §5, closed from the first command.
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 westeurope SA=campuxlab$RANDOM az storage account create --name $SA --resource-group rg-campux-lab \ --location westeurope --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.Create a container using your Entra identity, not a key:
az storage container create --account-name $SA \ --name images --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: confirm Allow enabling anonymous access on individual containers is unchecked.On screen: new accounts default this off — this is the guardrail against the public-container breach. Leaving it off means no container can be made public even by a hurried colleague.
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 7 for your own account.
Open Configuration and find the default access tier (Hot / Cool).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?
The four services share one account — one public-access setting, one firewall, one identity model. The convenience of one place is also a shared fate: a misconfiguration on the account touches all four doors at once.
The real constraint on storage is not space but exposure — a single container left public is the breach, no matter how the rest is secured. The weakest access setting is the ceiling.
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 burns down?" You do not guess. You explain the redundancy the account is set to, what survives a drive versus a region, and set the crown-jewel data to geo-redundant while the rebuildable temp files stay local and cheap. You match the blast radius to the value — and stop paying region prices for a scratch file.
This is the whiteboard round of an interview. Rehearse it where it is cheap.
The breach is a container left public, not a missing network appliance. If your sketch adds a firewall box and calls the data safe, you have drawn the wrong control. The one that matters is the public-access toggle on the blob container — leave it on and the images and exports are on the open internet no matter what else is in the picture. Draw that setting, mark it off, and you have drawn the thing this class exists to protect.
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. Surviving the loss of a whole region requires copies in a second region, which is what the geo options — GRS and GZRS — provide. A protects only against a failed disk; B against a lost zone within one region, but a region-wide outage takes all its zones at once. D is the dangerous assumption: redundancy is a setting you choose and pay for, and the default is not the most protective one. One precision worth carrying into interviews: plain GRS protects the data, but the secondary is not readable until a failover — continuing to serve through an outage wants the read-access variants (RA-GRS, RA-GZRS) from footnote 3. Match the option to the disaster, exactly as Figure 7 draws it — only copies across the red line survive a region.
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 SAS is scoped and time-limited. The two false statements are the dangerous beliefs: anonymous access is disabled by default on new accounts — assume the opposite and you will misjudge your exposure — and an account key is the master credential to the whole account, not a read-only scope to one container. Confusing a key's power with a SAS's narrowness is precisely how the wrong credential ends up handed out.
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. The value of a SAS is that it expires; a ten-year expiry throws that away and creates, in effect, a decade-long key. Over ten years that URL will be logged, forwarded, pasted into a ticket, and copied to a laptop that later leaves the company — and every copy stays valid the whole time. Lines one, two and four are exemplary: narrow permissions, scoped to one container, restricted to the partner's addresses.
Consider the consequence. A short expiry — hours or days, renewed as needed — means a leaked token is worthless almost immediately; a ten-year token means a leak discovered in year three is still a live breach with seven years to run. Worse, a SAS signed with an account key cannot be revoked without rotating that key, which breaks everything else using it. Short lifetimes are not caution; they are the entire mechanism working as designed.
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.
Right-size per data, not per fear. Match the redundancy to the value: geo-redundant for irreplaceable customer records and the POS exports that must survive a regional disaster; cheaper local or zone redundancy for logs, caches and temporary artifacts that are either short-lived or trivially rebuilt. The same dataset-by-dataset judgement you applied to tiers applies here.
Name the saving, because that is the argument leadership hears. Blanket GZRS can be several times the cost of local redundancy on the same volume, paid every month, for copies of data nobody would mourn. Redundancy chosen per dataset protects everything that matters and stops paying to protect everything that does not — which is the difference between careful and merely expensive.
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 a dial: LRS survives a disk, ZRS a zone, GRS and GZRS a whole region. Pay for the disaster you must actually outlast.
- 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.
- The public container is the most common cloud breach. Keep anonymous access off at the account level; a leak is a config someone chose.
- Rehydrating an archived blob can take up to around fifteen hours at standard priority, less if you pay for high priority — but "less" still means hours, not the instant read of an online tier. Treat the exact numbers as subject to change and the principle as fixed: Archive is for data you are confident you will not need quickly, and a backup you might restore under pressure does not belong there. ↩
- The default flipped in Microsoft's favour a couple of years ago: newly created accounts now disallow anonymous access unless someone deliberately enables it. Older accounts created under the previous default may still permit it, so never assume — check the account-level setting, and prefer to disable it outright so no container can be opened even by accident. Defaults help; they do not absolve you of looking. ↩
- A detail worth carrying: the Archive tier is not available on the zone-and-geo option GZRS (nor on ZRS or RA-GZRS) — it is supported on LRS, GRS and RA-GRS. So "archive it and make it geo-and-zone redundant" is not a combination you can pick, and a design that assumes it will fail at creation. When redundancy and tier interact, verify the specific pairing rather than assuming every option composes with every other. ↩