A driftwood gallery must move last year’s exhibit photos to the Cool access tier immediately without waiting for a lifecycle policy evaluation. Which Blob SDK action should the developer take?
Select an answer to reveal the explanation.
Short Explanation
SetAccessTier is the manual thermostat: flip those blobs to Cool now. Lifecycle policies are the scheduled thermostat. Soft delete and renaming prefixes do not move a blob between Hot and Cool.
Full Explanation
Immediate, per-blob tier changes are performed with Set Blob Tier (REST) or SetAccessTier (SDK) on each target object. The driftwood gallery needs last year’s exhibit photos moved to Cool now, without waiting for lifecycle evaluation intervals. Calling SetAccessTier with Cool on those blobs updates their access tier promptly (subject to service processing), which is the supported manual control for online tier transitions. Lifecycle policies remain useful for scheduled automation, but they are not required—and not fast enough—when the requirement is an on-demand move.
Waiting for a lifecycle rule because the SDK cannot change access tiers fails factually: the data plane exposes tier change APIs for supported online tiers. Lifecycle is complementary automation, not the only mechanism.
Deleting and re-uploading every photo with a Cool container name prefix fails because access tier is a blob property, not a naming convention. Prefixes may help lifecycle filters later, but delete-and-reupload is wasteful and risk-prone when SetAccessTier can change tier in place.
Enabling soft delete fails because soft delete governs recoverability after deletion; it does not assign Cool to existing blobs.
Exam caveat: tiering has early-deletion/minimum-duration charges for some tiers, and Archive transitions have different rules than Hot/Cool/Cold—confirm cost impact before bulk immediate Cool moves. Operational check: SetAccessTier to Cool on a pilot blob, read AccessTier via GetProperties, and confirm the portal/metrics reflect Cool before running a bulk job.