Azure Storage Solution for Five-Year Immutable Daily-Access Data?

Design data storage solutions for semi-structured and unstructured data Design governance

Answer Recommend a General Purpose v2 storage account with the Hot access tier and a container-level access policy enabling a five-year time-based immutable retention interval.

HOTSPOT You are planning an Azure Storage solution for sensitive data. The data will be accessed daily. The dataset is less than 10 GB. You need to recommend a storage solution that meets the following requirements: ✑ All the data written to storage must be retained for five years. ✑ Once the data is written, the data can only be read. Modifications and deletion must be prevented. ✑ After five years, the data can be deleted, but never modified. ✑ Data access charges must be minimized. What should you recommend? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Hot Area: [sampleXML/xmlfile-110_1.jpg]

Community Insight

The exam tests whether you know that blob immutability is a container/blob-level WORM policy, not an Azure Resource Manager lock, and that daily reads force the Hot tier for cost minimization.

This AZ-305 hotspot asks you to pair the right Azure Storage account/tier with the right WORM configuration so that a sub-10 GB dataset read daily is immutable for five years at the lowest access cost. The page establishes that a General Purpose v2 account on the Hot access tier plus a container-level time-based immutable retention policy is the correct pairing.

Most candidates reach for a storage account resource lock (CanNotDelete) or a legal hold; the lock only protects the account resource from deletion while blobs can still be edited or deleted, and a legal hold never expires so it cannot express 'deletable after five years'.

Community Discussion (40 comments)

mesloth 👍 1

Refer https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview#summary-of-access-tier-options Latency

MasterMans 👍 4

General purpose v2 with Cool access tier for blobs -The Cool tier is optimized for data that is infrequently accessed, but still needs to be available for reading. It offers lower access costs than the Hot tier and is more suitable than Archive for daily access. Archive tier is not appropriate because it has high latency and is meant for rarely accessed data. Container access policy - You can use immutability policies (via container access policy) to enforce write-once-read-many (WORM) behavior. This ensures that data cannot be modified or deleted for a specified retention period (e.g., 5 years). Resource locks only prevent deletion of the storage account or configuration changes, not individual blob modifications.

vrm1358 👍 2

Got this on may. 02, 2025 , Score 925, the second box :container access policy

Ghada1 👍 1

2. Container access policy the second select should be container access policy, because with access policy you're not only preventing data from deletion/modification (like what you could've done using locks) but you also can set a retention policy which is a requirement in this question

Lazylinux 👍 4

i would go for gpv2 hot tier and container access policy

Azure2020 👍 3

1 Hot tier 2 should be access policy. PS Locking a storage account does not protect containers or blobs within that account from being deleted or overwritten!!!

Zein135 👍 1

I think the right choice for second question is "Container Access Level" we can adjust access level to read only

Robtin 👍 1

A Container Access Policy defines how data within a container can be accessed by managing roles and permissions. What it does: It controls read and write permissions for data in a container. Limitations: It does not prevent data from being modified or deleted. It only regulates who can access the data and what they can do with it. Conclusion: This does not guarantee data immutability or enforce a retention period.

Daychill 👍 1

Immutability policies can be scoped to a blob version or to a container. How an object behaves under an immutability policy depends on the scope of the policy. For more information about policy scope for each type of immutability policy, see the following sections: Time-based retention policy scope Legal hold scope Depending on the scope, you can configure both a time-based retention policy and a legal hold for a resource (container or blob version).

nav109 👍 5

Got this on Nov. 17, 2023

mark_af 👍 3

1. "Hot tier". Lower access transaction costs, meats requirement "Data access charges must be minimized" 2. "Container access policy" seems to be the best one. I still struggle to find it in the documentation (only found immutable storage references)

xRiot007 👍 3

1. Wrong, the cheapest tier is Archive, then Cool, then Hot. The reason why we need Hot access is because this data has to be accessed a lot on a daily basis.

jcxxxxx2020 👍 9

This question appeared on my Exam today 10/22/2023 Total of 48 questions

babakeyfgir 👍 1

answer?

GeorgiAngelov 👍 1

General purpose v2 with Hot access tier and Storage resource lock.

aksrav 👍 3

its general puprose v2 with hot tier container access policy

NotMeAnyWay 👍 16

1. Storage Account type: c. GP v2 Hot. Considering the data will be accessed daily, the Hot access tier is the most cost-effective for storing frequently accessed data. 2. Configuration to prevent the modification and deletions: Container access policy. The Container access policy is indeed the place to configure Azure's Immutable Blob Storage to ensure data is retained without modifications or deletions for a specified amount of time, which suits your needs. The Azure Blob Storage's Immutable Blob Storage feature provides a WORM (Write Once, Read Many) capability which aligns with your requirements perfectly.

sw1000 👍 9

Moderator/Admins: could you please update the answer. We have a lot of consense here that the answers are General Purpose v2 Blobs + hot tier AND Container Access Policy are needed to get the desired outcome.

ZUMY 👍 6

General Purpose V2 Hot tier Container access policy I would recommend using Azure hot Blob Storage with a WORM (Write Once Read Many) policy. WORM policies prevent data from being modified or deleted after it has been written, and they can be applied to individual blobs or entire containers.

ZUMY 👍 3

To implement this solution, you can follow these steps: Create an Azure Blob Storage account and enable the WORM feature. This can be done through the Azure Portal or via Azure CLI or PowerShell. Create a new blob container for your sensitive data. Set the WORM policy for the container to enforce write-once-read-many access for all blobs in the container. Upload your sensitive data to the blob container. Configure a retention period of five years for the data in the container.

malcubierre 👍 8

General Purpose V2 Hot tier Container access policy

Stone82 👍 5

Second is Container Access Policy

MadPanda 👍 3

It should be Hot Tier with Container Access Policy. Storage Account Resource Lock does not prevent the data from being modified/deleted inside the container. https://learn.microsoft.com/en-us/azure/storage/blobs/data-protection-overview#overview-of-data-protection-options

👍 1

-Gen2 Hot Access -Container access policy (immutable storage time-based retention policy) https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-time-based-retention-policy-overview#container-level-policy-scope https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-container-scope?tabs=azure-portal Note: A storage account resource lock will apply restrictions to the control plane only (i.e. no changes to the storage resource properties/settings). It would not prevent changes to the data plane. https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources#understand-scope-of-locks https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources#considerations-before-applying-your-locks

orionduo 👍 1

Answer should be: Hot&Container access policy Requirement: The data will be accessed daily Hot access tier is optimized for storing data that is accessed frequently Immutable storage for Azure Blob Storage enables users to store business-critical data in a WORM (Write Once, Read Many) state. While in a WORM state, data cannot be modified or deleted for a user-specified interval. By configuring immutability policies for blob data, you can protect your data from overwrites and deletes.

OPT_001122 👍 6

Box 1: General purpose v2 with Hot access tier for blobs Box 2: container access policy

uacanillo 👍 2

Container access level and container access policy can be used to control access to the container but they don't prevent modification and deletion of the data itself. Storage account resource lock provides a way to prevent accidental deletion of resources at the subscription level and it's the best way to prevent modifications and deletions on the data once it's written to storage.

CineZorro824 👍 1

Data lock should be Container Access policy, which is the scope of the Immutable Policy on a Storage Account. Storage Account resource lock is wrong, this only prevents the Storage Account from being deleted, it says nothing about data modification.

CineZorro824 👍 1

https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-container-scope?tabs=azure-portal

RandomNickname 👍 3

Agree with C & B C: Hot due to request in question. B: See url and extraction from URL; https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json A cannot-delete lock on a storage account doesn't protect account data from deletion or modification. It only protects the storage account from deletion. If a request uses data plane operations, the lock on the storage account doesn't protect blob, queue, table, or file data within that storage account. If the request uses control plane operations, however, the lock protects those resources. If a request uses File Shares - Delete, for example, which is a control plane operation, the deletion fails. If the request uses Delete Share, which is a data plane operation, the deletion succeeds. We recommend that you use a control plane operation. A read-only lock on a storage account doesn't prevent its data from deletion or modification. It also doesn't protect its blob, queue, table, or file data.

A_GEE 👍 2

The second should be Container Access policy Should use immutable storage for Azure Blob Storage. Time-based retention Policy https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview

M_r_Cloud 👍 1

Both C&C and C&B are suitable for this

kJigneshk 👍 2

yes you set the resources lock as read-only and delete prevention but can to for data, that is only for resources change not for in the data.

scottims 👍 3

GPv2 hot and container access policy Immutable storage for Azure Blob Storage enables users to store business-critical data in a WORM (Write Once, Read Many) state. While in a WORM state, data cannot be modified or deleted for a user-specified interval. By configuring immutability policies for blob data, you can protect your data from overwrites and deletes. Immutability policies include time-based retention policies and legal holds. https://docs.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-container-scope?tabs=azure-portal

codingdown 👍 5

clearly HOT and storage account policy ( not resource lock )

Gowind 👍 53

Answer is GPv2 HOT to have frequent access : https://docs.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview Answer is container access (immutable) policy at least at the container scope. https://docs.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview

mse89 👍 151

gpv2 hot tier, container access policy to configure a time-based retention policy for immutable storage. Storage account resource lock does not prevent data editing or deletion, but only the storage account deletion.

mesloth 👍 1

Even Cool Tier has real time retrieval response and it is cheaper than Hot tier. So its should be gpv2 cool tier for first question.

webbies 👍 4

You can set the storage resource lock to CannotDelete and ReadOnly isnt? https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json

ike001 👍 8

agree 100%

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The dataset is under 10 GB but is read every day, so a general-purpose v2 account using the Hot access tier keeps per-GB access charges at their lowest for frequently read blobs. The WORM requirements must be enforced where the blobs actually live: a container-level access policy that applies a time-based immutable retention interval of five years. With that policy in place, blobs can be written and read but cannot be overwritten or deleted for the entire interval, which satisfies 'once written, the data can only be read' and 'modifications and deletion must be prevented'. When the five-year interval expires the blobs become removable, matching 'after five years the data can be deleted'. Hot rather than Cool or Archive is chosen because the access-charge requirement dominates a dataset this small that is touched daily.

Why Other Candidate Answers Are Wrong

A resource lock such as CanNotDelete is applied by Azure Resource Manager to the storage account resource itself, so it blocks account deletion while leaving blob overwrite, blob delete and container delete fully possible. A legal hold also produces immutable blobs, but a hold has no expiry and persists until it is manually cleared, so it cannot express the requirement that data becomes deletable after exactly five years. Configuring Cool, Cold or Archive access tiers would satisfy retention but inflate transaction and retrieval charges for a workload read daily, directly contradicting the cost-minimization requirement. Premium block blobs or Azure Files add cost without contributing any capability the WORM and retention requirements ask for.

Community Comment Notes

mse89 states the answer as "container access policy to configure a time-based retention policy for immutable storage" and warns that a Storage account resource lock "does not prevent data editing or deletion". Gowind reaches the same conclusion, citing the access tiers overview for GPv2 Hot and the immutable storage overview for a retention policy scoped at least to the container, and NotMeAnyWay argues daily access makes Hot the most cost-effective tier for the WORM-protected container. sw1000 asks the moderators to update the posted answer because "we have a lot of consense here" that General Purpose v2 with a Hot tier plus a Container Access Policy is what delivers the stated outcome. jcxxxxx2020 and nav109 both report seeing this exact hotspot on live exams in late 2023, reinforcing that container-level immutability rather than an account lock is the tested concept.

Official Reference

Exam Strategy

Treat each hotspot box independently: Box 1 is a storage account/tier decision driven by frequency of access (Hot for daily reads), Box 2 is a data-protection decision driven by 'cannot be modified or deleted' (container-level immutable policy). Whenever a question says written data must be read-only, think blob immutability, and only fall back to resource locks when the requirement talks about the account itself, not the data.

Frequently Asked Questions

Why isn't a storage account resource lock enough to make the blobs immutable?

A resource lock protects only the account resource from deletion; blobs inside can still be overwritten or deleted. Immutability must come from a container-level retention policy.

Could a legal hold replace the time-based retention policy for the five-year requirement?

No. A legal hold has no expiry and stays until manually cleared, so it cannot express 'deletable after five years'; a five-year time-based interval can.

More AZ-305 FAQ →

Related Analysis

Practice All AZ-305 Questions

Access 95 questions with complete answers and detailed explanations.

View Full AZ-305 Practice Test →

← Back to AZ-305 Study Guide