A lighthouse-keeper log blob is snapshotted, then the live blob’s Content-Type is changed. The app needs the headers from before that change. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
A snapshot is a time capsule—its Content-Type stays what it was when you snapped it. Read properties from that snapshot when you need the old headers. The live blob can change without rewriting history.
Full Explanation
After a lighthouse-keeper log blob is snapshotted and the live blob’s Content-Type is later changed, the app should read properties from the snapshot (or version) that captured the earlier headers. Snapshots preserve the properties and metadata that existed at creation time. Updates to the base blob’s Content-Type affect the live object only; existing snapshots keep the prior header set, which is how you recover the pre-change nameplate for the keeper’s log.
Always reading properties from the live blob base name only returns the new Content-Type and loses the historical headers the stem needs. Disabling versioning so snapshots inherit every later Content-Type change misunderstands snapshots: they do not keep mutating to follow the base blob, and turning versioning off does not make historical captures inherit future edits. Copying Content-Type into account-level firewall tags after each snapshot stores nothing useful for blob property recovery and confuses networking tags with blob headers.
Exam caveat: distinguish snapshots from blob versioning—both can preserve point-in-time state when enabled, but you must address the specific snapshot or version URI/version id when reading old properties.
Operational check: create a snapshot, change the base Content-Type, Get Properties on both the base and the snapshot URI, and confirm only the snapshot still reports the original Content-Type the log app requires.