Cram sheet — Configure and manage storage accounts
AZ-104 › Unit 2 › Configure and manage storage accounts
Cram sheet — Configure and manage storage accounts
Configure and manage storage accounts
- AZ104-U2.T2
- 5
- 25
- 4
Redundancy is the heart of this topic, and the exam separates two things learners routinely merge: what a copy protects you from, and where the copy lives. Nothing here protects you from a deletion.
Redundancy, by what it actually protects
| Option | Copies | Durability over a year |
|---|---|---|
| LRS | Within a single physical datacenter in the primary region | at least 11 nines |
| ZRS | Synchronously across three or more availability zones in the primary region | at least 12 nines |
| GRS | LRS in the primary, then asynchronously to the secondary region | — |
| GZRS | ZRS in the primary, then asynchronously to the secondary region | — |
- The primary difference between GRS and GZRS is how data is replicated in the primary region. In the secondary region, both always use LRS.
- The paired secondary region is determined by the primary and cannot be changed. It is not a setting.
- Copying to the secondary is asynchronous, so a regional failure can lose the most recent writes. Read access to the secondary is the separate RA- prefix.
- ZRS, GZRS and RA-GZRS are not available for all storage account types, and availability varies by region as well as by type.
Encryption is not a decision
- Service-side encryption uses 256-bit AES in Galois/Counter Mode, it is enabled for all storage accounts, and you cannot disable it.
- What you can decide is the key: Microsoft-managed or customer-managed. And you can add infrastructure encryption, which encrypts twice, at service and infrastructure level, with two different algorithms and two different keys.
- So an option that offers to turn encryption on is describing something already true, and an option that offers to turn it off is describing something impossible.
Object replication has prerequisites
- Change feed must be enabled on the source account.
- Blob versioning must be enabled on both source and destination.
- And it locks in: if the account has object replication policies in effect, you cannot disable blob versioning until you delete those policies.
- Replication is asynchronous — Azure checks the source's change feed periodically — so this is not a synchronous mirror and latency depends on blob size.
Traps
Check yourself
Where these figures come from
Every figure above was read from the raw documentation below on the day this sheet was written. The sha1 is git hash-object over the bytes as fetched, so a doc that changes underneath this sheet can be detected rather than assumed.
| Document | sha1 |
|---|---|
| Azure Storage redundancy | c09bcf4095c8 |
| Storage account overview | 6348a1847dd2 |
| Azure Storage encryption for data at rest | 40f490e7ed52 |
| Object replication for block blobs | 39c6a30c368d |