advanced26 min studyLesson 319 in Engineering

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

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.

Tobserved=Teligibility+Δscheduling+ΔexecutionT_{\rm observed}=T_{\rm eligibility}+\Delta_{\rm scheduling}+\Delta_{\rm execution}
This illustrative serial timing model uses one time unit and nonnegative delays for an action that actually executes. It is not an S3 maximum-delay guarantee; filters, protection, or changed eligibility can prevent an action. Billing treatment also need not equal observed physical-action timing.↔ Scroll wide equations horizontally.

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.

deletable⁡(v)=authorized⁡(v)∧retentionAllows⁡(v)∧¬hold⁡(v)\operatorname{deletable}(v)=\operatorname{authorized}(v)\land\operatorname{retentionAllows}(v)\land\neg\operatorname{hold}(v)
This is a simplified technical-policy checklist for permanently deleting one version v in the stated scenario. retentionAllows includes the configured mode and any valid permitted bypass, where applicable. It is not a complete authorization algorithm or a legal conclusion.↔ Scroll wide equations horizontally.

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.

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.

  1. 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.

  2. 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.

  3. 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 result

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.

Explore the model

Interactive lab

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.

Eligible is not the same state as completedExact 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. Current readings: P(state 1) at step 0: 0%; Stationary P(state 1): 60%; Chain behavior: Monotone convergence. All parameters are adjustable with the labeled controls below.Two-state Markov distribution after 0 steps: state zero probability 1, state one probability 0.Initial distribution (1, 0) · step 0p = 0.3q = 0.201100%0%1−p1−qP(0)P(1)Monotone convergence
P(state 0)P(state 1)Stationary distribution
P(state 1) at step 0
0%
Stationary P(state 1)
60%
Chain behavior
Monotone convergence
t = 0 s

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.

Check your understanding

A version's fixed retention period expires while its independent legal hold remains active. Under the stated S3 Object Lock model, what follows?

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.

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.