You have an app named App1 that uses an Azure Blob Storage container named app1data.
App1 uploads a cumulative transaction log file named File1.txt to a block blob in app1data once every hour. File1.txt only stores transaction data from the current day.
You need to ensure that you can restore the last uploaded version of File1.txt from any day for up to 30 days after the file was overwritten. The solution must minimize storage space.
What should you include in the solution?
To ensure that you can restore the last uploaded version of File1.txt from any day for up to 30 days after the file was overwritten, blob versioning is the optimal solution. Blob versioning automatically maintains previous versions of a blob when it is modified or deleted. This allows you to retrieve any previous state of the file within the retention period. Additionally, blob versioning stores only the changes between versions, optimizing storage space compared to maintaining multiple full snapshots of the file. This meets the requirement of minimizing storage space while ensuring the ability to restore specific versions.
I believe the given answer is correct. The key here is that File1.txt is changed every hour. Theoretically, you can do this with B as well but you need to configure a given time when the snapshot is taken. With blob versioning, you have access to 24 versions, and you can restore for example a version that took place 6 hours ago as opposed to when the blob snapshot took place (you will only have a single version, the one that the snapshot captured at the moment it was taken). For this reason I would go with D.
https://learn.microsoft.com/en-us/azure/storage/blobs/snapshots-overview Note Blob versioning offers a superior way to maintain previous versions of a blob. For more information, see Blob versioning. https://learn.microsoft.com/en-us/azure/storage/blobs/versioning-overview
I was debating whether to go with Blob Snapshots in the end because our requirement is that we only need one version of the file, so we can schedule a snapshot to take place let's say right before midnight, and it would work just fine. However, there's some administrative overhead to do so. https://learn.microsoft.com/en-us/azure/storage/blobs/snapshots-manage-dotnet https://learn.microsoft.com/en-us/azure/storage/blobs/snapshots-overview To automate the snapshot creation process, you can use Azure Logic Apps or Azure Functions.
I will, however, stick with Blob Versioning, even Microsoft suggests this is a better way. And to minimise the costs you can simply use lifecycle policies to delete old versions.
Yep, seems all right.
Yep, seems all right.
I will, however, stick with Blob Versioning, even Microsoft suggests this is a better way. And to minimise the costs you can simply use lifecycle policies to delete old versions.
Yep, seems all right.
Yep, seems all right.
I was debating whether to go with Blob Snapshots in the end because our requirement is that we only need one version of the file, so we can schedule a snapshot to take place let's say right before midnight, and it would work just fine. However, there's some administrative overhead to do so. https://learn.microsoft.com/en-us/azure/storage/blobs/snapshots-manage-dotnet https://learn.microsoft.com/en-us/azure/storage/blobs/snapshots-overview To automate the snapshot creation process, you can use Azure Logic Apps or Azure Functions.
I will, however, stick with Blob Versioning, even Microsoft suggests this is a better way. And to minimise the costs you can simply use lifecycle policies to delete old versions.
Yep, seems all right.
Yep, seems all right.
I will, however, stick with Blob Versioning, even Microsoft suggests this is a better way. And to minimise the costs you can simply use lifecycle policies to delete old versions.
Yep, seems all right.
Yep, seems all right.
"Microsoft recommends maintaining fewer than 1000 versions per blob" https://learn.microsoft.com/en-us/azure/storage/blobs/versioning-overview
Couldn't be more obvious to me. Versioning. File is uploaded every hour and we need to make sure we can restore the last upload. Snapshots are daily, a restore after 11pm would mean you'd miss out on the last 23 uploads. Question is pants but the answer is still clear.
I will vote for B here, as the requirement is to minimize storage costs and also states it is only needed to archive the *last uploaded version* of the day. I am not aware of a native solution to schedule those snapshots, but worst case we could use scheduled Azure Functions for that.
Versioning will store all 24 cumulative files daily. Instead we can do daily snapshots at the end of a day as it has cumulative data for the whole day. It will add administrative overhead, but reduce storage usage.
Versioning will store 24*delta content of file which is comparable stirage to daily snapshot
It says "cumulative transaction log file named File1.txt " means last file updated will have all the changes happened every hour. Taking snapshot of the last updated file at midnight will suffice the requirement. Answer B
I believe option D. Also, spoke to chat about it in comparison of minimize storage space: Why Blob Versioning Minimizes Storage: Versioning only stores a copy when the blob is modified, unlike snapshots which can be more space-intensive due to frequent captures. Retention policies can be configured with versioning to automatically delete older versions (e.g., after 30 days), helping to control storage space over time. Conclusion: Blob Versioning is the better choice for minimizing storage space, as it optimizes storage by only keeping changes between versions and can automatically prune older versions according to a defined retention period. This makes it more storage-efficient compared to snapshots. So, blob versioning remains the best solution for this scenario, as it balances the need for version recovery and storage efficiency.
Storage space: Blob versioning and daily snapshots both consume storage space, but blob versioning might consume more space if there are frequent changes to the blob. Daily snapshots only create one copy of the blob per day, while blob versioning creates a new version every time the blob is modified or deleted. Therefore, blob versioning might be more suitable for blobs that are rarely changed, while daily snapshots might be more suitable for blobs that are frequently changed. It is a very circumstantial question, I do not feel that enough information is provided. Copilot suggests Versioning would be the best option, but it is a terrible question.
I will go with blob-versioning for the reason that version optimizes storage by additionally storing the delta and not the entire data as in case of snapshots
Solution must minimize storage space... Versioning for sure. Snapshots every hour would cause a lot of administrative load to manage storage space consumption.
D. Blob Versioning Justification: Blob Versioning: Automatically keeps previous versions of an object when it is overwritten, enabling you to restore any version within the retention period. Storage Efficiency: Only stores the changes, minimizing the additional storage required.
I feel B is thr right answer. Reasons: We need only the last updated version for each day, so taking snapshot of a day at midnight would be sufficient. Secondly, we need to minimise storage space. versioning will make 24 versions for each day. Lifecycle mgmt rules can easily delete the snapshot after 30 days.
No. The file is updated hourly, so the last updated version is also hourly. You need to restore the last upload, which is hourly, not daily. Storage is minimized by keeping daily data available.
with blob snapshot we can fulfill the requirement of keeping the last version of the file of a particular day while minimizing storage space.
What happens after midnight when file1 gets deleted in order to be reset to empty in order to store transaction data for the current day only? There is not indication that policies will be created to store a snaphot in cheaper tier after the last change of the day. It seems like it would be a hassle to dig through the changes to get the last version of the file for a particular day.
D is correct
Because blob snapshot is for backing up, so blob versioning will be a good choice for roll back to a previous version of File1.txt
Blob versioning will use more storage space than Snapshots. Log file is cumulative, so with versioning will be storing larger and larger versions every hour. Daily snapshot taken at appropriate time will only have the final file of the day. Whether keep data Hot or move to Cool, there will be less data with snapshot approach. No requirement to restore each version; only the final file of the day. Log file 1h to 23h is of no interest. LifeCycle Policy can only delete versions created n days ago; it can't skip versions. If rule is to delete versions older than a day, you'll end up deleting all versions of the file1.txt including the one we want to keep for 30 days.