AZ-104 Implement and Manage Storage Practice Question
A storage account hosts blobs used by a public website. You need to reduce the risk of accidental deletion by developers while allowing updates to existing blobs. What should you configure?
⚠ Common exam trap
Watch out — candidates often confuse blob soft delete with immutable storage, assuming both prevent deletion, but immutable storage also blocks updates, which violates the requirement to allow modifications to existing blobs.
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
✓
Enable blob soft delete.
Blob soft delete protects against accidental deletion by retaining deleted blobs for a specified retention period, allowing recovery. This meets the requirement to reduce risk from developers while still permitting updates to existing blobs, as soft delete only applies to delete operations, not overwrites.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable blob soft delete.
Why this is correct
Enabling blob soft delete in the storage account preserves a soft-deleted copy for a configurable retention interval (typically 1 to 365 days) when a blob is deleted. Because it only intercepts delete operations, normal HTTP PUT and overwrite requests from the public website continue to succeed without modification or versioning overhead. This directly meets the requirement to maintain availability for updates while providing rollback capability after accidental deletion.
- ✗
Enable immutable storage for the container.
Why it's wrong here
Immutable storage uses WORM (write-once-read-many) policies that prevent blobs from being modified or deleted during a specified retention period. While this would absolutely protect against accidental deletion, it also blocks the very PUT/overwrite operations the public website relies on for normal updates, causing updates to fail with a 409 Conflict. This makes it unsuitable for a dynamic site that requires frequent content changes.
When this WOULD be correct
When the requirement is to prevent deletion or modification of blobs for a specified retention period, such as for regulatory compliance (e.g., SEC 17a-4) or legal hold, and no updates are needed.
- ✗
Move the account to premium performance.
Why it's wrong here
Premium performance, such as the BlockBlobStorage tier, uses solid-state drives to deliver higher I/O throughput and lower latency, but the performance tier has no bearing on data integrity or deletion recovery. A delete request still permanently removes the blob from the storage account unless a separate feature like soft delete or versioning is enabled. Thus, upgrading performance does not mitigate the risk of accidental deletion.
When this WOULD be correct
A question asks: 'You need to ensure low-latency access for frequently accessed blobs in a storage account. What should you configure?' In that case, enabling premium performance (Azure Premium Blob Storage) would be correct.
- ✗
Enable static website hosting only.
Why it's wrong here
Static website hosting configures the storage account to serve pre-defined index and 404 documents over HTTP(S) for a custom domain, but it is purely a content-delivery feature. It adds no data protection layer—if a blob is deleted, the website immediately returns 404 and the data is permanently lost unless another mechanism like soft delete is active. Therefore, enabling only this feature fails to protect against accidental deletion while not hindering updates.
When this WOULD be correct
If the question asked how to host a static website (e.g., HTML, CSS, JS) from Azure Storage with a custom domain, enabling static website hosting would be the correct answer.
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.
✓Enable blob soft delete.Correct answer▾
Why this is correct
Enabling blob soft delete in the storage account preserves a soft-deleted copy for a configurable retention interval (typically 1 to 365 days) when a blob is deleted. Because it only intercepts delete operations, normal HTTP PUT and overwrite requests from the public website continue to succeed without modification or versioning overhead. This directly meets the requirement to maintain availability for updates while providing rollback capability after accidental deletion.
✗Enable immutable storage for the container.Wrong answer — click to see why▾
Why this is wrong here
Immutable storage prevents any modifications or deletions to blobs during the retention period, which conflicts with the requirement to allow updates to existing blobs.
★ When this WOULD be the correct answer
When the requirement is to prevent deletion or modification of blobs for a specified retention period, such as for regulatory compliance (e.g., SEC 17a-4) or legal hold, and no updates are needed.
Why candidates choose this
Candidates may think immutable storage protects against accidental deletion, but they overlook that it also blocks updates, which is explicitly required in this scenario.
✗Move the account to premium performance.Wrong answer — click to see why▾
Why this is wrong here
Moving the account to premium performance does not address accidental deletion; it only improves latency and throughput for workloads requiring consistent low-latency access, not data protection against deletion.
★ When this WOULD be the correct answer
A question asks: 'You need to ensure low-latency access for frequently accessed blobs in a storage account. What should you configure?' In that case, enabling premium performance (Azure Premium Blob Storage) would be correct.
Why candidates choose this
Candidates may think premium performance implies better data protection or durability, confusing performance tiers with data management features like soft delete.
✗Enable static website hosting only.Wrong answer — click to see why▾
Why this is wrong here
Enabling static website hosting only does not prevent accidental deletion; it merely configures the storage account to serve static content. It provides no protection against blob deletion.
★ When this WOULD be the correct answer
If the question asked how to host a static website (e.g., HTML, CSS, JS) from Azure Storage with a custom domain, enabling static website hosting would be the correct answer.
Why candidates choose this
Candidates may confuse the requirement to reduce deletion risk with the need to configure the storage account for public website access, assuming that hosting configuration inherently includes protection.
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?”
Go deeper
Related to this question
Learn chapter
Customer-Managed Keys (CMK) for Storage Encryption
Key term
Risk
Risk is the possibility that an event or action will negatively affect an organization's ability to achieve its goals, often measured in terms of likelihood and impact.
Key term
Soft delete
A soft delete marks data as deleted without actually removing it from the database, allowing recovery if needed.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.