A nettle-tea factory wants blobs unused for 30 days moved to Cool and blobs unused for 365 days deleted, without writing a timer Function that lists and deletes. What should the developer configure?
Select an answer to reveal the explanation.
Short Explanation
Lifecycle policies are the warehouse’s automatic schedule: after 30 quiet days, move to Cool; after 365, dispose. A handmade timer Function can mimic pieces of that, but the storage policy is the built-in tool. Soft delete and queues are different knobs.
Full Explanation
Blob Storage lifecycle management policies automate tier transitions and deletions based on age and filters without custom timers. The nettle-tea factory should configure one policy with an action that moves blobs to Cool after 30 days since last modification (or the age base the rule uses) and another action that deletes after 365 days—commonly expressed as multiple rules or actions in the same policy document. The storage resource provider evaluates the policy; no Azure Function is required to list and mutate blobs for this schedule.
An Azure Functions timer that lists every blob and deletes after 30 days only fails the requirement to avoid a handwritten timer and also collapses the two different thresholds (30-day Cool vs 365-day delete) into an incomplete custom approach.
Soft delete retention set to 30 days fails because soft delete recovers accidental deletes for a retention window; it does not tier to Cool and does not replace scheduled lifecycle deletion at 365 days.
A Queue Storage poison-queue rule that tiers blobs after 365 days fails because poison-queue handling is a Functions/queue processing pattern for failed messages, not Blob lifecycle tiering.
Exam caveat: lifecycle evaluation is periodic, not real-time to the minute, and last-access-time based rules need last access tracking enabled if you key off read activity rather than creation/modification. Operational check: enable a policy on a test prefix with short ages in a non-production account, wait for evaluation, and verify Cool tier then delete behavior before applying 30/365-day rules to production data.