Legal counsel at Cascade Regional Airlines places a hold on a set of incident-investigation blobs pending litigation, requiring that they cannot be deleted or altered by anyone, with no expiration date, until legal explicitly releases the hold? Which immutability feature fits this open-ended requirement?
Select an answer to reveal the explanation.
Short Explanation
A time-based lock is great when you know the exact date the freeze should end, but litigation rarely works on a fixed calendar. A legal hold has no expiration built in at all — it stays in force indefinitely until someone with authority explicitly removes it, which is exactly the open-ended control legal counsel needs here.
Full Explanation
A legal hold, applied alongside immutable blob storage policies, prevents deletion and modification of the blobs it covers indefinitely, with no built-in expiration; it is lifted only when an authorized user explicitly removes the hold, making it the correct tool for open-ended litigation scenarios where the end date is unknown in advance. A time-based retention policy, by contrast, is defined for a fixed interval and automatically permits deletion once that interval elapses, which is the wrong shape for a requirement with no known end date — setting it to one day would actively fail the requirement almost immediately. Blob soft delete caps out at 365 days and, more importantly, does not prevent deletion or modification at all — it only preserves a recoverable copy after the fact, which does not satisfy 'cannot be deleted or altered.' A lifecycle management rule that deletes blobs after a guessed litigation timeline directly contradicts the requirement by scheduling automatic deletion, and guessing a legal timeline is also operationally risky. A concrete check: query the blob's immutability policy properties via the SDK or CLI to confirm legalHold is reported as true, and re-verify it periodically since a hold must be explicitly cleared rather than assumed to still be active.