In the AZ-104 exam, the storage domain accounts for 15–20% of the total. There are many unfamiliar terms at first glance, but approaching them through real-life analogies makes them much easier to understand. This article explains the core concepts one by one — storage account configuration, access control, Blob Storage, and Azure Files — in a friendly and approachable way.
Storage Accounts
A storage account is like a bank vault. Just as a bank has different types of vaults (checking, savings, safe deposit boxes), an Azure storage account contains multiple types of storage spaces (Blob, Files, Queue, Table). The storage account itself acts as a "container" that bundles and manages all of these.
For example, you can manage your company website's image files, log records, and employee shared folders all under a single storage account. The very first thing you need to decide when creating a storage account is Redundancy — that is, how many copies of your data to keep and where to store them.
Redundancy Options
Redundancy is about "how many places to back up your data." To avoid losing data when a hard drive suddenly fails, when an entire building loses power, or even when a natural disaster damages an entire data center, you need to create copies in multiple locations.
| Option | Copy Location | Regional Disaster Protection | One-Line Summary | |--------|--------------|------------------------------|------------------| | LRS | 3 copies within a single data center | No | Cheapest; protects within the same building | | ZRS | Copies across 3 Availability Zones (AZs) in the same region | No | Protects against building-level failures | | GRS | LRS + copies to another region hundreds of km away (6 total) | Yes (read unavailable before failover) | Protects against regional disasters | | RA-GRS | Same as GRS + read access from remote region | Yes (read available) | Maintains read service even during a disaster | | GZRS | ZRS + LRS in remote region (6 total) | Yes (highest durability) | The strongest protection available |
Understanding with real-life analogies
LRS is like making three copies of important documents in three different office cabinets. If one cabinet breaks down it's fine, but if the office building burns down you lose everything. ZRS is like storing documents in vaults at three different buildings in the same city. Even if one building collapses, your data survives in the other buildings. GRS is like keeping the original in a Seoul office while hiding a copy in a Busan warehouse. Even if all of Seoul is hit by a disaster, the Busan copy remains. However, you cannot directly access the Busan copy under normal circumstances — you must go through a recovery process first. RA-GRS is the same as GRS, except you can access the Busan warehouse in "read-only" mode at any time. You can even configure it so that read requests are served from Busan when Seoul is busy. GZRS is the ultimate combination of ZRS and GRS. Within the same region, data is distributed across three buildings, and an additional copy is maintained in a remote region.
On the exam, if asked to choose the "cheapest option" select LRS; if "regional disaster protection + remote read" is required, select RA-GRS.
!5 storage redundancy options
Access Control
Access control is about managing who can access the storage account and how. Just like a building entry system, it manages keys and badges so that only authorized people can enter.
Access Keys
Access keys are the master key of the storage account. With just this one key, you can access and modify all data in that storage account. It is like a master key that can open every room in the entire building. That makes it very powerful — and just as dangerous. You must never write it directly into code or expose it externally; it is strongly recommended to store it securely in Azure Key Vault.
SAS (Shared Access Signature)
SAS is like a temporary visitor badge. You use it when you do not want to hand out the master key, but want to grant access to a specific room, for a limited time, with specific permissions only (such as read-only).
For example, if you want to give an external partner a link to download an image file for 24 hours only, you generate a URL containing a SAS token and share it with them. After 24 hours, the link is automatically invalidated.
The types of SAS are as follows:
Service SAS: Grants access to a specific service (e.g., Blob only, or Files only). Account SAS: Grants access across multiple services within a storage account. Stored Access Policy: By associating a SAS with a policy, you can centrally invalidate all related SAS tokens simply by deleting or modifying that policy. It is like changing the "company visitor badge issuance policy" — all badges issued under that policy instantly become invalid.
Storage Firewall
The storage firewall is like a building security gate. It allows access only from a specific company network (VNet) or specific IP addresses, and blocks all other access. For example, by configuring the storage to be accessible only from the company's internal network, you can fundamentally block unauthorized access from outside.
Blob Storage
Blob Storage is like a digital warehouse. It can store almost any type of file — images, videos, documents, log files, backup data — regardless of format. "Blob" stands for Binary Large Object and is optimized for storing unstructured data.
Blob Types
Even within Blob Storage, there are three types depending on the characteristics of the data being stored. Just like a warehouse has regular shelves, a freezer, and a filing cabinet — each serving a different purpose.
Block Blob: The most common type. Used for data that is stored and read in "chunks" — images, videos, documents, music files. This is the default type used in most scenarios. Because files are split into multiple blocks for uploading, even large files are handled efficiently.
Page Blob: A type specialized for storing virtual machine (VM) disk files (VHD). Used when random read/write operations to specific locations are frequent — like a hard drive. When you create a VM, Page Blob internally acts as the disk.
Append Blob: A type optimized for data that is "only ever appended to the end" — like log data. Once written, content cannot be modified or deleted; only new content can be appended to the end. Suitable for data that accumulates in chronological order, such as server access records or system event logs.
Storage Tiers and Lifecycle
Blob Storage can be managed across four tiers with different costs depending on how frequently the data is accessed. It is similar to warehouse rental fees — store frequently accessed items in a nearby warehouse, and put rarely used items in a distant but cheaper one.
Hot: Data that is accessed frequently. Storage cost is high but read cost is low. Suitable for images or documents that are currently being served. Cool: Data that is not used much for 30 days or more. Storage cost is lower than Hot but read cost is higher. Suitable for files that are only occasionally retrieved, such as monthly reports. Cold: Data that is rarely used for 90 days or more. Even cheaper, but read cost is even higher. Archive: Data that is almost never accessed for 180 days or more. The cheapest tier, but to read the data you must first go through a "rehydration" process (which takes several hours). Because it is offline, data cannot be read immediately. Suitable for old documents subject to legal retention requirements or long-term backups.
Lifecycle Management Policy
Manually deciding "this file should now be moved to Cool" every day is not realistic. Lifecycle management policies automate this process. For example, you can create a policy such as "automatically move files not accessed for 30 or more days to the Cool tier, move files not accessed for 90 or more days to Archive, and automatically delete files after 1 year" — and Azure will handle it for you.
!The 4 Blob Storage tiers
Data Protection
To guard against accidental deletion or overwriting of important data, Azure provides several data protection features.
Soft Delete
Soft Delete works like a recycle bin. Even if you delete a file, it does not disappear immediately — it is kept in a recycle bin for a configured period (e.g., 14 days). It can be recovered at any point within that period. This feature is a lifesaver when you accidentally delete an important file.
Blob Versioning
Blob versioning is like the auto-save history of a document editor. Every time a file is modified, the previous version is automatically preserved. In situations like "I want to roll back to yesterday's version," you can restore a previous version at any time.
Blob Snapshots
A snapshot is a feature that takes a photograph of a file's state at a specific point in time. Unlike versioning which automatically saves every time a file is modified, a snapshot is a read-only copy that you take manually (or according to a policy) at a specific point of your choosing. Taking a snapshot before applying a large update means you can quickly restore to that point if something goes wrong.
Azure Files
Azure Files is like taking a company shared drive and moving it to the cloud. Have you ever used a "Z drive" or a "team shared folder" at work? Azure Files offers exactly that — a shared folder in the cloud where multiple people can share files and edit them simultaneously.
Because it supports SMB (the Windows file-sharing protocol) and NFS (the Linux file-sharing protocol), it can be mounted on both Windows and Linux just like a local drive.
Identity-Based Access
Just like a regular company shared drive, Azure Files can be accessed by logging in with a company account. It supports Kerberos authentication through Azure AD DS (Azure Active Directory Domain Services) or on-premises AD DS. This means you can manage permissions using your existing company account system — for exam