AZ-104 Implement and Manage Storage Practice Question
Your application stores compliance documents in Azure Blob Storage. The documents must be kept in a write-once-read-many state for five years and must not be altered or removed during that time. What should you configure?
⚠ Common exam trap
Many exam-takers confuse blob soft delete (which only recovers deleted blobs but does not prevent modification) with immutable storage, or mistakenly think lifecycle management or SAS tokens can enforce a write-once-read-many state.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Immutable blob storage with a time-based retention policy
Immutable blob storage with a time-based retention policy enforces a write-once-read-many (WORM) state, ensuring that blobs cannot be modified or deleted for a specified retention period. This directly meets the requirement of keeping compliance documents unaltered for five years, as the policy locks the data at the storage level, overriding any user permissions or delete operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Blob soft delete
Why it's wrong here
Blob soft delete acts as a safety net by retaining deleted blobs for a customer-configured retention period, enabling recovery after accidental deletion. However, it does not forbid deletion in the first place; data is still removed from active access and merely recoverable, and blobs can be overwritten normally during the retention window. Because soft delete only affects the deletion lifecycle, it does not enforce an immutable, write-once state required for compliance.
When this WOULD be correct
A question where the requirement is to recover blobs that were accidentally deleted or overwritten within a specified retention period, without needing to prevent intentional modification or deletion by authorized users.
- ✓
Immutable blob storage with a time-based retention policy
Why this is correct
Immutable blob storage with a time-based retention policy enforces a Write-Once, Read-Many (WORM) state, meaning blobs can be written but not modified or deleted until the retention interval expires. This satisfies regulatory compliance requirements by locking the data at the container or policy level, with explicit controls to extend the period but not shorten it. The policy is evaluated at the storage service level, so even an authorized user cannot bypass the lock.
- ✗
Blob lifecycle management to move data to Cool tier
Why it's wrong here
Blob lifecycle management automates transitioning blobs between access tiers—Hot, Cool, and Archive—based on rules such as last-modified time or size. While moving data to the Cool tier reduces storage costs, it neither prevents deletion nor blocks overwrites, because lifecycle actions are just background operations that change tier metadata. A user with write permissions could still modify or remove the blob, so this option provides no WORM or compliance assurance.
When this WOULD be correct
A question asks: 'You want to automatically move blobs older than 30 days to Cool tier to reduce costs. What should you configure?' In that scenario, blob lifecycle management is the correct answer.
- ✗
A shared access signature
Why it's wrong here
A shared access signature (SAS) is a token that grants granular, time-limited access permissions—read, write, delete, or list—to a container or blob. While a SAS can restrict an external party's actions, it is purely an authorization mechanism and has no bearing on how data is stored or retained. It cannot prevent an authorized holder of the token from modifying or deleting data, nor does it impose a retention period, so it is irrelevant to compliance document storage.
When this WOULD be correct
You need to grant a third-party application time-limited, restricted access to download specific blobs from a storage account without exposing the account key. A SAS token with read permissions and an expiry time would be correct.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Immutable blob storage with a time-based retention policyCorrect answer▾
Why this is correct
Immutable blob storage with a time-based retention policy enforces a Write-Once, Read-Many (WORM) state, meaning blobs can be written but not modified or deleted until the retention interval expires. This satisfies regulatory compliance requirements by locking the data at the container or policy level, with explicit controls to extend the period but not shorten it. The policy is evaluated at the storage service level, so even an authorized user cannot bypass the lock.
✗Blob soft deleteWrong answer — click to see why▾
Why this is wrong here
Blob soft delete protects against accidental deletion or overwriting, but it does not enforce a write-once-read-many (WORM) state; data can still be modified or deleted within the retention period if the soft delete policy is changed.
★ When this WOULD be the correct answer
A question where the requirement is to recover blobs that were accidentally deleted or overwritten within a specified retention period, without needing to prevent intentional modification or deletion by authorized users.
Why candidates choose this
Candidates may confuse soft delete with immutable storage because both involve retention periods, but soft delete is designed for recovery, not for enforcing data immutability against modification or deletion.
✗Blob lifecycle management to move data to Cool tierWrong answer — click to see why▾
Why this is wrong here
Blob lifecycle management moves data between tiers (e.g., Hot to Cool) based on age, but does not prevent deletion or modification. It cannot enforce a write-once-read-many state or protect against alterations.
★ When this WOULD be the correct answer
A question asks: 'You want to automatically move blobs older than 30 days to Cool tier to reduce costs. What should you configure?' In that scenario, blob lifecycle management is the correct answer.
Why candidates choose this
Candidates may confuse lifecycle management with retention policies, thinking that moving data to Cool tier somehow protects it, or they may assume that tiering implies immutability.
✗A shared access signatureWrong answer — click to see why▾
Why this is wrong here
A shared access signature (SAS) provides delegated access to blobs but does not prevent deletion or modification of blobs; it only controls who can access them, not enforce immutability.
★ When this WOULD be the correct answer
You need to grant a third-party application time-limited, restricted access to download specific blobs from a storage account without exposing the account key. A SAS token with read permissions and an expiry time would be correct.
Why candidates choose this
Candidates may think SAS can restrict write or delete operations by setting appropriate permissions, but SAS permissions apply to the accessor, not to the data itself, and cannot enforce a write-once-read-many state.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
Blob
A blob is a large piece of unstructured data, like a photo or video, stored in the cloud with a unique identifier.
Key term
Retention policy
A retention policy is a set of rules that determines how long an organization keeps its data and what happens to it when the retention period expires.
About these practice questions
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Your application stores compliance records in Azure Blob Storage. The records must remain in a write-once-read-many state for three years and must not be altered or deleted during that period. What should you configure?
hard- A.Blob soft delete
- ✓ B.Immutable blob storage with a time-based retention policy
- C.Lifecycle management to move data to Archive
- D.A shared access signature
Why B: Immutable blob storage with a time-based retention policy enforces a WORM (Write-Once, Read-Many) state, preventing any modification or deletion of blobs for a specified retention period. This meets the requirement of keeping compliance records unaltered for three years, as the policy locks the data at the storage level, overriding any user permissions or delete operations.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.