Exam AZ-305 topic 2 question 21 discussion

1. correct 2. Should be COntainer Policy for immutable storage. A resource lock does not prevent removal of files and folders. Prevents deleting resource inside the resource group

1 is correct 2 - Container access policy

General purpose v2 with Cool access tier for blobs - It offers lower access costs than the Hot tier. Container access policy - You can configure immutability policies.

Storage account type: General purpose v2 with Hot access tier for blobs. Hot access is the cheapest. Configuration to prevent modifications and deletions: Storage account resource lock. Container Access Policy is for SAS.

Azure Blob Storage (Hot Tier) Optimized for frequent access with low data access charges. Provides high availability and redundancy options like Geo-Redundant Storage (GRS) for added protection. Immutable Blob Storage with Time-Based Retention Enforces write-once, read-many (WORM) policies to prevent modification or deletion for five years. After five years, the data can be deleted, but never modified. Configured via Storage Account Blob Immutability Policies. Data Retention Policy Apply an Immutable Policy for five years using the following command: Set-AzStorageBlobImmutabilityPolicy -ContainerName "data-container" -PolicyName "RetentionPolicy" -RetentionInDays 1825

1. GPv2 with hot access tier for blobs 2. Container access policy

Storage account type: General purpose v2 with Hot access tier for blobs: This option provides a balance between performance and cost, ideal for daily access. Configuration to prevent modifications and deletions: Container access policy with an immutable blob policy: This ensures that data cannot be modified or deleted, strictly adhering to the requirement of read-only access until the data can be deleted after five years.

Storage account type: General purpose v2 with HOT access tier for blobs, it is most expensive in storage cost but CHEAPEST in access costs and hence meets requirements https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview Once the data is written, the data can only be read. Modifications and deletion must be prevented. is called WORM and can only be done via policy and hence container access policy. For those who say Storage resource lock is NOT correct because it can achieve the required goal however it fails to stop it being modified i.e. in order to delete the storage/blob you need to remove the lock from read and make it modify at that moment no guarantee that no one is accessing it and modifying it and other problem is resource lock are way to administrative as compared to Container policy (automated) i.e. who will remember to remove lock of storage acc and allow for delete without ever being modified after 5 years!! Good Luck :)

Storage account type: General purpose v2 with Cool access tier for blobs. This option is suitable because it allows storing data that is infrequently accessed, which helps minimize data access charges, and it supports blob storage which can handle datasets under 10 GB. Configuration to prevent modifications and deletions: Storage account resource lock. This option prevents modifications or deletions of the storage account resources, ensuring that once written, the data can only be read as required.

Box 2 is a container access policy (for immutable storage) A resource lock will only prevent the modification/deletion of the said resource, not of the data inside of that resource.

Same as Question #17 1. GPv2 with hot access tier for blobs 2. Container access policy

1. Storage account type: C. General purpose v2 with hot access tier for blobs The hot access tier provides lower data access costs compared to the cool access tier, making it more suitable for minimizing charges when data is accessed daily. Although the cool tier has lower storage costs, the data access charges are higher, which would not be ideal for your scenario. Premium block blobs are meant for high-performance scenarios and are not necessary for a small dataset of less than 10 GB. 2. Configuration to prevent modifications and deletions: B. Container access policy You can create a container access policy with specific permissions (in this case, read-only) and set an expiry time of five years. This policy prevents modifications and deletions, while still allowing the data to be read. After five years, the policy will expire, and the data can be deleted but not modified. Storage account resource locks and container access level settings don't offer the same granularity of control over the data as the container access policy.

1. Premium block blobs 2. Container Policy https://azure.microsoft.com/en-us/pricing/details/storage/blobs/ Operations and data transfer

premium block blob, container access policy We only need to minimize access charge, not storage cost. https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-block-blob-premium In other words, to access same amount of data within a given time - 500 million reads /second. That is much faster than GPv2 hot tier milisecond access time

1. GPv2 with hot access tier for blobs 2. Container access policy https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview 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.

For Data Storage and Access, Premium will be the cheapest. https://azure.microsoft.com/en-us/pricing/details/storage/blobs/

The second answer is wrong. A resource lock does exactly what the name suggests - it locks the resource itself. To prevent modification of the files, a container access policy is needed.