You have a line-of-business (LOB) app that reads files from and writes files to Azure Blob storage in an Azure Storage account.
You need to recommend changes to the storage account to meet the following requirements:
Provide the highest possible availability.
Minimize potential data loss.
Which three changes should you recommend? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
To provide the highest possible availability and minimize potential data loss for an Azure Storage account, the following changes should be implemented: 1) Enabling soft deletes protects your data from accidental or erroneous deletion, allowing recovery within a specified retention period. 2) Enabling read-access geo-redundant storage (RA-GRS) ensures high availability by replicating data to another region, making it available for read access if the primary region becomes unavailable. 3) Adding retry logic to the app’s interactions with the storage account ensures that operations can be retried in case of transient failures during failover, minimizing potential data loss. A time-based retention policy primarily helps with data lifecycle management rather than directly minimizing data loss.
The question is "You need to recommend *changes to the storage account* to meet the following requirements:", not changes to the app.. so it is BCE
I don't think so. That would be too easy.
BCD should be the correct answer, no disagreement with other comments on B and C. I would go with D because during failover some data transactions can potentially be lost hence the best practice is to have a re-try logic. This is one of the requirements as well "Minimize potential data loss". E to me doesn't make sense since it has to do more with data lifecycle management than minimizing potential data loss.
yes for that make changes to storage account(not to the app) cos that is the question about
yes for that make changes to storage account(not to the app) cos that is the question about
Am I the only one who says the correct answer is B, C, D?
I agree, BCD should be the correct answer, no disagreement with other comments on B and C. I would go with D because as MOe pointed out, during failover some requests can potentially be lost hence the best practice is to have a re-try logic. This is one of the requirements as well "Minimize potential data loss". E to me doesnt make sense since it has to do more with data lifecycle management than minimizing potential data loss.
yes for that make changes to storage account(not to the app) cos that is the question about
yes for that make changes to storage account(not to the app) cos that is the question about
Answer is correct RA-GRS for high availability soft delete and time retention for data loss protection
Time-based retention policy support: Users can set policies to store data for a specified interval. When a time-based retention policy is set, blobs can be created and read, but not modified or deleted. After the retention period has expired, blobs can be deleted but not overwritten. https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-immutable-storage B,C,E
ABC - https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy#read-access-to-data-in-the-secondary-region
This question could be interpreted another way: "Minimize potential data loss if the primary region has an outage". The question already mentions high availability, and there's no mention of file deletion, so I interpret this question as being focused entirely on high availability. In which case the answer would be: A, C, D. Enable RA-GRS. If the primary goes down, check the LastSyncTime of the storage account, and if data was written to the primary after the LastSyncTime, it will have been lost. Therefore, add retry logic to the app for storage account interactions to ensure such data is eventually written successfully. https://docs.microsoft.com/en-us/azure/storage/common/last-sync-time-get I know the question says "changes to the storage account", and there are indeed three answers that involve changes to the storage account, but that's effectively giving the solution away, and common sense suggests Microsoft aren't going to make it that easy for you :)
Soft delete is aimed at "minimizing potential data loss". Last Sync Time query is not required since sending a request to an unavailable zone or region would fail anyway. The retry mechanism is to hold the application write requests until Azure re-directs them to the paired region when it becomes writable; as the result of automatic fail-over. Re-direction of the read requests happens instantaneously in case of an outage --- My answers would be B, C, D.
I agree, BCD should be the correct answer, no disagreement with other comments on B and C. I would go with D because as MOe pointed out, during failover some requests can potentially be lost hence the best practice is to have a re-try logic. This is one of the requirements as well "Minimize potential data loss". E to me doesnt make sense since it has to do more with data lifecycle management than minimizing potential data loss.
Agree with you, the context of the question is based on reading and writing to the Storage account through app. There is no mention of deletion. Considering that, A,C,D looks logical.
I agree, BCD should be the correct answer, no disagreement with other comments on B and C. I would go with D because as MOe pointed out, during failover some requests can potentially be lost hence the best practice is to have a re-try logic. This is one of the requirements as well "Minimize potential data loss". E to me doesnt make sense since it has to do more with data lifecycle management than minimizing potential data loss.
I think the answers are right because of "Minimize potential data loss."
Answer: BCE correct agree
BCE is correct and not BCD. At first I also thought option E didn't make any sense, but it's not the "Lifecycle Management" feature (intended to move to cool or archive and then delete), this Time-Retention Policy is an access policy set up at container level to do exactly the opposite, to avoid deletes by setting up a time-retention period (and you can even lock those policies to comply with legal regulations). Definitely BCE.