Lesson 111 · AWS Learning Path

AWS 111: S3 versioning and lifecycle rules

Anil Jalela · Published Oct 14, 2025 · 14 min read

The real problem

A team recognizes the name S3 versioning and lifecycle rules but has not connected the feature to a real requirement, identity boundary, network or data path, failure mode, price dimension, and cleanup owner. A plausible configuration could still fail the workload.

Final outcome

The learner will produce a requirement-led artifact for S3 versioning and lifecycle rules, inspect the matching AWS control plane in the Management Console, run a matching CloudShell or AWS CLI query, interpret the output, diagnose one failure, defend one architecture choice, and prove cleanup or approved retained state.

The practical outcome is not a command transcript. It must show what was expected, what happened, what the result proves, what it does not prove, and which evidence would change the decision.

Learning objectives

By the end of this lesson, the learner can:

• explain versioning states;
• explain overwrite protection;
• explain delete markers;
• explain lifecycle scope;
• explain asynchronous behavior;
• connect control-plane state to the real data, network, identity, or application behavior;
• identify cost and cleanup ownership before any optional mutation;
• troubleshoot from evidence without opening broad access or adding broad permissions.

Relationship model

Requirement
   |
   v
Identity and policy -> AWS configuration -> network or data path -> workload behavior
        |                    |                      |                    |
        +--------------------+----------------------+--------------------+
                                      |
                                      v
                         monitoring, cost, recovery, cleanup

Use this model to separate an AWS object that exists from a result that actually works. Every arrow is a verification boundary.

Prerequisites, permissions, Region, and safety

• Learning baseline: This sequence assumes practical Linux knowledge but no prior cloud-computing or AWS knowledge. Cloud, networking, security, data, automation, and architecture concepts must come from completed earlier lessons. If a prerequisite checkpoint is incomplete, return to its linked lesson before continuing.
• Confirm a non-root caller with aws sts get-caller-identity and keep the account number private.
• Use ap-south-1 unless this lesson explicitly names a second Region.
• Confirm the intended profile and Region with aws configure list before interpreting an empty result.
• Use read-only List, Get, and Describe permissions for the named services. Design exercises run locally and require no resource-creation permission.
• This is a no-create lesson. Console and CLI work is read-only, and every design artifact is created locally.
• Never publish account IDs, public addresses, ARNs containing private account data, session IDs, presigned URLs, object data, credentials, or KMS material.
• Do not use root, world-open SSH or RDP, disabled TLS verification, unowned resources, or irreversible retention controls in a training exercise.

Core model

How it works

Model every key as a sequence of versions plus optional current delete marker. Cleanup must delete every version ID and delete marker, not only issue an ordinary recursive delete.

Read the result in layers:

1. Scope: account, Region, VPC, bucket, AZ, endpoint, principal, object version, or resource ARN.
2. Control plane: the requested configuration exists and reached an expected state.
3. Behavior: the request, connection, health check, replication, restore, or application result meets the requirement.
4. Operations: monitoring, failure owner, cost, retention, rollback, and cleanup are known.

Control-plane success is necessary but not sufficient. A resource can be available while policy, routing, DNS, health, data, or application behavior remains wrong.

Architecture decision table

Professional questions normally contain several valid services. State the requirement that selects one option, why the nearest alternative fails it, and what changed requirement would reverse the choice.

Versioning state machine and the special null version

new bucket: Unversioned
       |
       | enable
       v
    Enabled  <--------------------+
       |                           |
       | suspend                   | enable again
       v                           |
    Suspended ---------------------+

There is no API transition from Enabled or Suspended back to the original never-versioned state. Objects written before versioning use the special null version ID. When versioning is first enabled, those existing objects are not copied; they remain null versions. In a suspended bucket, new writes use/replace a null current version while older uniquely identified versions remain. This behavior makes suspended buckets easy to misunderstand and is why learners must inspect actual version IDs.

Versioning configuration propagation can take time after first enablement; applications should follow current AWS guidance before immediately depending on versioned behavior at scale.

Operation-by-operation behavior

Recovery by copying an old version to the same key creates a new current version and preserves history. Deleting the current delete marker can instead reveal the previous version. Choose deliberately: copying gives a clear restoration event; marker deletion changes which existing version is current.

MFA Delete adds MFA protection to permanent version deletion and versioning-state changes, but only the bucket owner's root user can enable it and it is not managed through the normal console workflow. That root dependency and automation limitation mean Object Lock, account isolation, least privilege, and backup may be more operationally suitable controls. Do not teach MFA Delete as a universal one-click ransomware solution.

Lifecycle rule anatomy

A bucket lifecycle configuration contains ordered-looking JSON/XML rules, but learners must reason from filters, status, and action eligibility - not assume “first matching rule wins.” A rule includes:

• a stable rule ID and enabled/disabled status;
• a filter: empty/all objects, prefix, one tag, an And combination, and optionally object-size bounds;
• current-version transitions and/or current expiration;
• noncurrent-version transitions and/or expiration, optionally retaining a number of newer noncurrent versions when configured correctly;
• expired-object-delete-marker removal;
• abort of incomplete multipart uploads after a specified age.

Lifecycle does not act on Object Lock-protected versions in violation of retention/legal hold. Replication status can delay some lifecycle actions. Current and noncurrent versions need separate policies; expiring current objects in a versioned bucket commonly creates delete markers while old versions continue consuming storage.

When actions conflict on the same date, S3 applies documented precedence - for example permanent deletion takes priority over transition, and transition choices have precedence rules. Do not rely on visual rule order. Use current documentation and an explicit object timeline.

Timeline method: predict before deploying

For every rule, draw one row per version:

day 0: v1 PUT (current, Standard)
day 10: v2 PUT (v2 current; v1 noncurrent age starts)
day 20: simple DELETE (delete marker current; v2 noncurrent age starts)
day 40: remove delete marker (v2 becomes current again)

Then evaluate separately:

1. current-version age/action;
2. when each data version became noncurrent and its noncurrent age;
3. delete-marker state and whether it is an expired object delete marker;
4. Object Lock/replication constraints;
5. minimum storage-duration and request costs.

An expired object delete marker is not merely “an old marker.” It is generally a marker for which no data versions remain. A rule that removes expired markers does not promise to remove a marker that still covers recoverable versions.

Worked examples

Example 1: accidental overwrite

policy.json has v1 and v2. The application accidentally uploads v3. Retrieve v2 by version ID, validate its checksum/content, then copy v2 to the same key to create v4 as the new current version. Preserve v3 for investigation until approved lifecycle/removal. Evidence includes before/after list-object-versions, the restored response, and checksum - not only a successful copy status.

Example 2: simple delete appears to erase an object

A normal GET returns not found after a simple delete, but list-object-versions shows a current delete marker and two data versions. Delete only the marker's version ID or copy the approved old version. If list versions itself is denied, do not conclude the bytes are gone.

Example 3: cost keeps growing after “30-day expiration”

The rule expires current versions after 30 days but has no NoncurrentVersionExpiration. Daily overwrites create 365 retained versions. Add a reviewed noncurrent policy that matches recovery requirements, and forecast storage/minimum-duration effects before deployment. Never delete history merely to make a graph look better.

Example 4: multipart uploads never completed

Failed clients initiated uploads and left parts. The keys do not appear in normal object listings, yet parts are billed. Inventory multipart uploads, verify ownership and age, add AbortIncompleteMultipartUpload lifecycle automation, and explicitly abort owned test uploads during cleanup.

Lifecycle verification and automation

Configuration acceptance is not behavioral proof. Verify with:

• get-bucket-lifecycle-configuration for exact deployed JSON;
• object/version inventory including key, version ID, latest/marker status, last modified, size, and storage class;
• S3 Inventory for scalable periodic evidence;
• Storage Lens/metrics and billing trends for aggregate behavior;
• CloudTrail management events for rule changes and data events where access/deletion audit is enabled;
• EventBridge or supported event signals where appropriate, without assuming every lifecycle transition is immediate;
• a scheduled later observation because a 20-minute lab cannot prove a 30-day policy.

Deploy lifecycle as reviewed IaC or version-controlled configuration. Before replacing a bucket lifecycle configuration, retrieve and save the full existing document: put-bucket-lifecycle-configuration replaces the configuration, so an incomplete payload can silently remove unrelated rules. Rollback is restoration of the reviewed prior document, followed by a new read and object-impact assessment; it cannot undo versions already permanently expired.

Required positive, negative, and dependency tests

1. Create two versions, retrieve each exact version, create a delete marker, prove ordinary GET fails, remove only the marker, and prove recovery.
2. Attempt permanent deletion with a role intentionally lacking s3:DeleteObjectVersion; preserve AccessDenied as protection evidence.
3. Supply a lifecycle timeline containing current/noncurrent versions, a marker, a locked version, and a small object; predict every action and charge boundary before comparing with the instructor result.
4. During cleanup, repeatedly inventory and delete every owned version and marker, then prove both list-object-versions and multipart-upload inventory are empty before bucket deletion.

AWS Management Console guided practice

Before opening a service page, write the expected account, Region, starting state, and evidence. Do not choose Create, Save, Purchase, Lock, or Delete unless the lesson explicitly authorizes the live track.

1. Open an approved bucket, Properties, Bucket Versioning and Lifecycle rules; inspect status and filters without saving changes.
2. Open Objects, enable Show versions, and arrange the supplied two data versions and delete marker in chronological order.
3. Open Management, create-rule review only, and model noncurrent transition, noncurrent expiration, and incomplete multipart cleanup with current cost constraints.

For each step, capture the field name and value in text. A screenshot may support the record but does not replace the explanation. Console labels can evolve, so use the service search and current documentation if a navigation label differs.

CloudShell and AWS CLI practice

CloudShell is the default browser-based command environment taught in AWS 028. AWS 029 and AWS 030 cover local CLI installation and authentication. This lesson therefore does not assume that an unconfigured local shell is ready.

Start every session with:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account portion of the ARN before sharing. Then perform the topic query:

Inspect versioning, lifecycle configuration, versions, and delete markers for an approved bucket.

NW_BUCKET="replace-with-owned-bucket-name"
aws s3api get-bucket-versioning --bucket "$NW_BUCKET"
aws s3api get-bucket-lifecycle-configuration --bucket "$NW_BUCKET"
aws s3api list-object-versions --bucket "$NW_BUCKET" --output json

Expected interpretation:

Enabled or Suspended describes current versioning behavior. Lifecycle configuration does not prove that an object has reached eligibility or that an asynchronous action already occurred.

Replace every replace-with-... sample value before running its command, and use only an explicitly owned resource. Explain each option first. These queries are read-only; a successful response does not authorize a later create or delete operation.

Practical work

Create p06-version-lifecycle-plan.md for AWS 120: versioning enabled on both buckets; one rule aborts incomplete multipart uploads after 7 days; noncurrent versions become eligible for an approved transition after 30 days and expiration after 90 days; expired delete-marker behavior is documented. State that the lab validates configuration and performs explicit immediate cleanup rather than waiting for lifecycle execution.

The evidence package must contain:

• the problem and final requirement in the learner's own words;
• caller type and Region with private identifiers redacted;
• exact planned values, ownership, and cost class;
• one Console observation and matching CLI or API evidence;
• one behavior result or supplied data-plane record;
• one denied, failed, or counterexample result and evidence-led diagnosis;
• one architecture choice plus the rejected alternative;
• cleanup proof or explicit retained-state owner, expiry, and next lesson.

Verification standard

Use expected state before observed state. Record timestamps in UTC and preserve the original failure before changing anything. A passing submission answers all four questions:

1. What exact requirement was tested?
2. Which evidence proves the AWS configuration?
3. Which evidence proves the workload behavior?
4. What remains unproven or requires later monitoring?

If AWS returns no rows, verify account, Region, permission, filters, pagination, resource type, and deletion state before concluding that nothing exists.

Common failures and troubleshooting

Do not troubleshoot by attaching administrator access, opening administration ports to the internet, disabling encryption, retrying uncontrolled creation, deleting unknown resources, or weakening retention.

Cost, cleanup, and retained state

No AWS resource is created. Close CloudShell and remove or redact downloaded evidence.

Cleanup evidence requires terminal state and an after-inventory. Search related ENIs, public IPv4 addresses, EBS volumes and snapshots, load balancers, target groups, Auto Scaling instances, endpoints, logs, S3 versions and delete markers, backup recovery points, and global IAM roles when they apply. Billing data can lag, so schedule a later review.

Architecture and certification decisions

• Certification coverage: SAA-C03; SOA-C03; SAP-C02; DOP-C02.
• Exam mapping: SAA D1-D4.
• Explain service scope, failure boundary, consistency, recovery, security, operations, and price rather than matching a keyword.
• Treat availability and durability, encryption and authorization, routing and filtering, health and lifecycle, backup and replication, and discount and capacity as separate concepts.
• Do not reproduce protected certification questions.

Knowledge check

1. Can an enabled bucket return to unversioned?

Expected direction: No. Versioning can be suspended, not reset to the original state.

1. What does simple DELETE create in an enabled bucket?

Expected direction: A delete marker.

1. Does deleting a key name remove all versions?

Expected direction: No. Each version and delete marker needs version-aware cleanup.

1. Does a lifecycle rule act immediately?

Expected direction: No. Verify configuration now and observe asynchronous actions later.

Completion gate and assessment

Pass at 80 out of 100 with no critical safety failure. A missing practical artifact, unexplained output, unsafe access, destructive action outside the owned scope, unplanned billed resource, or false cleanup claim requires remediation and a changed retest.

Official sources

• Using S3 Versioning
• Versioning-enabled bucket behavior
• Versioning-suspended bucket behavior
• Delete markers
• MFA Delete
• S3 lifecycle management
• Lifecycle configuration elements and filters
• Lifecycle action precedence
• Lifecycle configuration examples