Eligibility, execution, and protected retention are separate states
Reason about asynchronous lifecycle actions and version-scoped Object Lock while distinguishing technical storage controls from a complete retention policy.
On this page
The question for today
What you’ll understand
- Distinguish lifecycle eligibility from observed action completion.
- Explain version-scoped fixed retention and independent legal-hold state.
- Verify current visibility and protected-version retention separately.
A lifecycle rule describes when objects or versions become eligible for managed actions, not a synchronous function call that completes at one exact instant. Retention controls describe which operations are permitted on a protected version, not necessarily whether the current name remains visible. Confusing these states produces failed cleanup assumptions and misleading restore tests. The examples use documented S3 general purpose bucket behavior with versioning enabled and explicitly fixed retention periods; other bucket types and retention features require their own contracts.
Lifecycle is an asynchronous managed workflow
A rule can select objects by supported filters and configure actions such as storage-class transition or expiration. Eligibility calculations, version state, supported transitions, and minimum-duration considerations depend on the exact action. S3 performs lifecycle actions asynchronously, and some conditions are reevaluated during processing. Do not promise that an object disappears at the instant a dashboard's day counter reaches a threshold. Observe the actual resulting state through the appropriate API and keep rule evaluation distinct from completed action.
Versioning changes expiration semantics. Expiring a current data version can add a delete marker while noncurrent payload remains, and noncurrent-version expiration requires the corresponding rule. Incomplete multipart cleanup is another distinct action. A storage-class transition can also change retrieval behavior and latency without changing the logical key's identity. Test the combinations your application uses, including restore procedures, rather than assuming one broad lifecycle label means all obsolete bytes are permanently and immediately removed.
Object Lock protects a version under its configured mode
S3 Object Lock operates on versions in a versioning-enabled bucket. For the fixed-retention examples, a retain-until time and mode govern protected-version operations. Governance mode permits specified bypass behavior only for appropriately authorized requests; compliance mode has stronger documented restrictions against shortening or deleting the protected version during its period. These are technical API controls, not a conclusion that a particular organization's legal or business retention requirements are satisfied. Keep the exact mode, permissions, and version in the policy record.
A legal hold is independent state without a fixed automatic expiry; authorized removal of the hold does not remove an unexpired retention period, and expiry of the period does not remove an active hold. The protection is version-scoped. New data versions and delete markers can still be created above a protected version under the documented rules. Thus a successful current-name delete can coexist with retained protected data. Verify prohibited permanent deletion and intended current visibility as separate test cases.
Verify technical outcomes before reclaiming capacity
Inventory should distinguish current objects, noncurrent versions, markers, incomplete uploads, and protected versions. A cleanup plan that treats every absent current key as reclaimed capacity can underestimate retained data. Conversely, an eligibility date does not by itself tell the exact billing or physical reclamation time. Review those provider contracts independently and avoid using payload-day arithmetic as an invoice estimate. The operational question is whether the intended versions changed state and whether recovery still meets the declared objective.
The Markov lab illustrates a fictional asynchronous action, not S3 timing. Interpret state 0 as eligible pending work and state 1 as completed work. Reset, set both p=0.5 and q=0, predict that after four transitions the pending probability is 0.5⁴, then press Step four times. Each Step advances one transition; q=0 makes completed state 1 absorbing in this fictional rule. Results are exact probabilities, not sampled objects. The model starts entirely pending and contains no calendar, filters, Object Lock, or billing. It demonstrates why eligibility and completion are distinct while supplying no production completion deadline.
Work it through
Count a modeled action delay without inventing a bill
Assume a fictional rule has already determined that 100 objects of 10 MB each are eligible at day 30. Observation shows all remain until an action completes at day 32. Ignore version changes and use decimal MB.
The selected logical payload is 100 × 10 MB = 1,000 MB, or 1 GB. This identifies the payload population, not backend encoded capacity or invoice treatment.
The observed delay after assumed eligibility is two days. Under the stipulated all-retained-until-completion model, that is 1 GB × 2 days = 2 GB-days of continued payload presence.
Do not equate those two GB-days with billable storage. Provider billing rules can use eligibility differently from action timing, and protected versions or current/noncurrent rules would require a different state analysis.
The example separates one GB of selected payload, a two-day observed action delay, and two modeled GB-days of presence. None alone establishes pricing, legal retention, or permanent deletion of every version.
The living notebook
Explore the model
Interactive lab · markov
Eligible is not the same state as completed
Reset, set both p=0.5,q=0, predict pending-state probability after four transitions, then Step four times. State 0 starts pending and state 1 is completed. This exact chain has no lifecycle clock, Object Lock, storage-class behavior, or provider timing guarantee.
- P(state 1) at step 0
- 0%
- Stationary P(state 1)
- 60%
- Chain behavior
- Monotone convergence
Exact finite-step probabilities for a two-state chain starting in state 0, not sampled trajectories. Playback advances two transitions per second. When p = q = 0 every distribution is stationary; when p = q = 1 the chain alternates forever. A single zero transition creates an absorbing state. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forLifecycle eligibility needs observed action evidence, and retention permission is a separate version-scoped condition.
Pause & reason
Check your understanding
Your turn
Try it yourself
A simple DELETE makes a key appear absent, yet an older version has an unexpired protected retention period. Why is that compatible with version-scoped protection, and what should a permanent-deletion test target?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Distinguish adding a new current marker from removing the protected historical entry itself.
Compare with the solution
The simple DELETE can add a delete marker above the protected version without erasing that version's payload. The protected entry remains retained even though ordinary current GET treats the name as deleted. A permanent-deletion test must explicitly target the protected version ID with controlled permissions and verify the required denial under its mode and hold state. Current-name absence is a different observable outcome and cannot stand in for that test.
Keep the idea
Take it with you
- Lifecycle eligibility and observed completion are distinct asynchronous states.
- Retention mode and legal hold apply to specified versions with separate permissions.
- Visible deletion, permanent payload removal, billing, and policy sufficiency need distinct evidence.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.