AZ-104 storage explained
Implement and manage storage is worth 15–20% of AZ-104. It covers three areas: controlling access to storage accounts, creating and configuring the accounts themselves, and working with Azure Files and Blob Storage. The questions are detailed. You need to know which redundancy option survives which failure, which kind of SAS can be revoked, and which blob feature needs another feature switched on first.
Configure access to storage
Access keys
Every storage account has two access keys. Two, so you can rotate without downtime: move applications to key 2, regenerate key 1, then repeat later. A key grants full access to the whole account, which is why most scenarios steer you away from sharing it.
Shared access signatures
| SAS type | Signed with | Scope |
|---|---|---|
| Account SAS | Account key | One or more services in the account |
| Service SAS | Account key | One service, such as Blob or Files |
| User delegation SAS | Microsoft Entra credentials | Blob Storage only |
An ad hoc SAS carries its permissions and expiry inside the token and cannot be revoked individually; only rotating the key that signed it invalidates it. A stored access policy fixes that for service SAS tokens: the policy lives on the container, share, queue or table, the token refers to it, and changing or deleting the policy revokes every token tied to it. Microsoft recommends the user delegation SAS where Blob Storage is involved, because it avoids the account key altogether.
Firewalls and virtual networks
By default a storage account accepts traffic from all networks. You can restrict it to selected virtual networks and IP ranges. Two details show up in questions:
- A service endpoint on the subnet is needed before you can add that subnet as an allowed network.
- The trusted Microsoft services exception lets services such as Azure Backup reach the account through the firewall.
Identity-based access for Azure Files
SMB access to Azure Files can use identities from on-premises Active Directory Domain Services, Microsoft Entra Domain Services or Microsoft Entra Kerberos for hybrid identities. Access is layered: an Azure role such as Storage File Data SMB Share Contributor grants share-level access, and Windows ACLs control directories and files underneath.
Configure and manage storage accounts
Redundancy
| Option | Copies | Protects against |
|---|---|---|
| LRS | 3 in one datacenter | Disk and server failure |
| ZRS | 3 across availability zones | Datacenter failure |
| GRS | LRS here plus LRS in the paired region | Regional outage |
| GZRS | ZRS here plus LRS in the paired region | Datacenter and regional failure |
| RA-GRS / RA-GZRS | As above | Adds read access to the secondary |
Read the requirement carefully. “Read data during a regional outage without failing over” means an RA- option. “Survive a zone failure” rules out LRS and GRS.
Object replication, encryption and tools
Object replication copies block blobs asynchronously between containers in two accounts. It requires blob versioning on both accounts and the change feed on the source. Data is always encrypted at rest; the choice is between Microsoft-managed keys and customer-managed keys held in Key Vault. AzCopy is the command-line tool for bulk copies and syncs; Azure Storage Explorer is the desktop tool for browsing and managing data.
Azure Files and Blob Storage
Access tiers
| Tier | Use for | Minimum storage period |
|---|---|---|
| Hot | Frequent access | None |
| Cool | Infrequent access | 30 days |
| Cold | Rare access | 90 days |
| Archive | Offline, long-term | 180 days |
Archive blobs cannot be read until they are rehydrated to an online tier, which takes hours at standard priority. Moving a blob out of a tier before its minimum period incurs an early deletion charge.
Lifecycle management
Lifecycle rules move blobs between tiers or delete them based on age, last modification or last access, and can target prefixes or blob index tags. Typical rule: cool after 30 days, archive after 90, delete after seven years. Rules run once a day, so changes are not instant.
Protection features
- Blob soft delete keeps deleted blobs for a retention period; container soft delete does the same for containers.
- Versioning keeps every previous version of a blob automatically when it is overwritten.
- Azure Files snapshots are read-only, point-in-time copies of a share; file share soft delete protects against deleting the whole share.
Soft delete protects against deletion. Versioning protects against overwriting. Scenarios often need both.
Sample questions
Question 1. Logs are written to Blob Storage and read often for 30 days, rarely for the next year, and must then be kept for six more years at the lowest cost. Nobody wants to move blobs by hand. What should you configure?
- A. Set the account default access tier to cool
- B. A lifecycle management rule that moves blobs to cool and later archive
- C. Object replication to a second storage account
- D. Blob soft delete with a seven-year retention
Show answer
Answer: B
A lifecycle management policy can tier blobs to cool after 30 days, to archive after a year and delete them later, all automatically. Changing the account default tier affects new blobs only and never archives. Object replication copies data to another account without tiering it. Soft delete keeps deleted data, not old data.
Want more questions like this? Full AZ-104 practice tests →
Question 2. A storage account must keep serving reads if the primary region is unavailable, without waiting for a failover, and must also survive the loss of one datacenter in the primary region. Which redundancy option fits?
- A. ZRS
- B. GRS
- C. RA-GRS
- D. RA-GZRS
Show answer
Answer: D
RA-GZRS combines zone-redundant storage in the primary region with a readable copy in the secondary region. ZRS has no secondary region. GRS has a secondary but it is not readable without failover, and RA-GRS uses LRS in the primary, so a single datacenter failure can affect it.
Want more questions like this? Full AZ-104 practice tests →
Question 3. You try to configure object replication from a container in account A to a container in account B, but the option fails validation. Which prerequisite is most likely missing?
- A. Blob versioning on both accounts and the change feed on the source
- B. Customer-managed keys on both accounts
- C. The archive tier on the destination container
- D. A private endpoint on the source account
Show answer
Answer: A
Object replication requires blob versioning on both source and destination accounts and the change feed on the source. Customer-managed keys, the archive tier and a private endpoint are not prerequisites for object replication.
Want more questions like this? Full AZ-104 practice tests →
What to practise
Create one storage account and walk through the domain in an hour: rotate a key, issue a SAS from a stored access policy and revoke it, restrict the firewall to one subnet, add a lifecycle rule, enable soft delete and versioning, then overwrite and delete a blob and restore both. Copy a folder with AzCopy and look at it in Storage Explorer. After that, the storage questions become checks against things you have seen happen.