Cram sheet — Configure Azure Files and Azure Blob Storage
AZ-104 › Unit 2 › Configure Azure Files and Azure Blob Storage
Cram sheet — Configure Azure Files and Azure Blob Storage
Configure Azure Files and Azure Blob Storage
- AZ104-U2.T3
- 7
- 25
- 7
Seven objectives, and they divide into two questions: what does this tier cost me to leave early, and which recovery feature gets this particular thing back. Four recovery features overlap here and they protect different objects.
Tiers and their minimum stays
| Tier | Minimum before an early-deletion penalty |
|---|---|
| Cool | 30 days |
| Cold | 90 days |
| Archive | 180 days |
- The penalty is prorated: move a blob to cool and delete it after 21 days and you are charged as though it stayed 30.
- Archive is offline. A blob there cannot be read or modified — you must rehydrate it to hot, cool or cold first, which can take up to 15 hours depending on the priority you choose.
- ⚠ You cannot rehydrate an archived blob using a lifecycle management policy. Lifecycle moves blobs to cooler tiers, not out of archive.
- ⚠ To change an account's redundancy while it holds archived blobs, you must rehydrate them all first.
- Capacity limits are set at the account level, not per tier.
Four recovery features, four different objects
| Feature | Protects | Retention |
|---|---|---|
| Blob soft delete | An individual blob, snapshot or version, deleted or overwritten | 1–365 days |
| Container soft delete | A deleted container and its contents | 1–365 days, default 7 |
| Blob versioning | Every write, automatically | Until you delete the versions |
| File share soft delete | A deleted file share | 1–365 days, default 7 |
- Container soft delete does not restore individual blobs deleted from a container that still exists — that is blob soft delete's job.
- New storage accounts have file-share soft delete enabled by default, and the setting is at the account level, applying to every share in it.
- Changing a retention period applies only to data deleted after the change. Anything already deleted keeps the period that was in force at the time.
Versioning versus snapshots
- With versioning on, every write operation creates a new version — automatically, with no action from anyone. That is the cost trap: it is why the documentation immediately recommends a lifecycle policy to delete old versions.
- A blob can have only one current version at a time. Modify a blob and the old current version becomes a previous version. Delete it and there is no current version at all, while previous versions persist.
- Azure Files uses share snapshots instead: read-only, point-in-time copies of the whole share.
- ⚠ Share snapshots provide only file-level protection. They do not prevent accidental deletion of the share or the storage account. Soft delete or a lock does that. This distinction is exam bait.
Lifecycle management
- A policy is a collection of rules in JSON. Each rule needs at least one action, and filters narrow it by name prefix or blob index tag.
- ⚠ A filter can say which blobs to include. There is no way to say which to exclude.
- ⚠ Adding or editing rules can take up to 24 hours to take effect and for the first run to start. A policy is not an immediate control, which is what makes it a wrong answer to any stem demanding something happen now.
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 |
|---|---|
| Access tiers for blob data | 78c82ab0e7da |
| Soft delete for blobs | c0acd68a6998 |
| Soft delete for containers | fdc676da4064 |
| Prevent accidental deletion of Azure file shares | 97e9b60325c0 |
| Blob versioning | 2b61a82792cf |
| Use share snapshots with Azure Files | b18da687afe1 |
| Optimize costs by automatically managing the data lifecycle | a6e60139abfb |