Data Lifecycle, Migration and Lake Organization

Task 2.3, "Manage the lifecycle of data," is where a data engineer stops being a builder and becomes a steward. The task's knowledge list is deliberately unglamorous, hot and cold storage solutions, cost optimisation across the lifecycle, deletion driven by business and legal requirements, retention policies and archiving strategies, resiliency protection, and its skills are concrete: perform load and unload operations between Amazon S3 and Amazon Redshift, manage S3 Lifecycle policies to change the storage tier, expire data based on age, and manage S3 versioning and DynamoDB TTL. The exam therefore rewards one habit above all others: know exactly what happens to a specific object, on a specific day, at a specific price.

In this lesson you will:

• read an S3 Lifecycle rule as AWS defines it, ID, Status, Filter, and the five action types, including the evaluation quirks that decide which action actually runs;
• walk the one-way transition waterfall and separate the minimum transition age (removed for the IA classes on 16 July 2026) from the minimum storage duration (30 / 90 / 180 days, unchanged);
• apply the 128 KB default floor, the chained-transition arithmetic and the tag, prefix and size filters;
• compute lifecycle money: transition request fees, Standard versus IA break-even, the minimum-duration cliff, and a one-year class comparison (as of Oct 2026);
• separate expiration, noncurrent-version expiration, multipart-upload abort and delete-marker cleanup, and explain why Expiration alone never shrinks a versioned bucket;
• operate versioning, delete markers and MFA Delete, and name the replication prerequisites for CRR and SRR;
• apply S3 Object Lock modes (Compliance, Governance, legal hold) as a lifecycle constraint;
• configure DynamoDB TTL, epoch seconds, deletion lag, capacity behaviour, and build the TTL plus Streams archival pipeline;
• choose a Glacier class by retrieval SLA, not by price alone;
• pick the right migration tool: AWS DMS with schema conversion (homogeneous versus heterogeneous), Snow Family, AWS DataSync and AWS Transfer Family;
• perform Redshift load and unload operations the way Task 2.3's first skill demands;
• design medallion bronze, silver and gold zones, fix the small-files problem with compaction, and catalog each zone separately;
• study four AWS customer case studies (Nasdaq, EOS Group, FINRA and BMW Group) and a sourced October 2026 update box;
• practise with 14 exam-style questions plus four interactive checks.

---

1. S3 Lifecycle: how a rule is actually built

1.1 One configuration per bucket, 1,000 rules

Each S3 bucket carries one lifecycle configuration containing up to 1,000 rules (a fixed quota, as of Oct 2026). A rule is a small object:

1.2 The five action types

1.3 Filters: prefix, tags and size

A rule's Filter scopes which objects it may touch. Prefix narrows to a path, tags narrow to objects carrying a key/value pair (for example tier=hot), and size predicates narrow to objects above or below a byte threshold. Two rules for one bucket are common and legitimate, a broad transition rule plus a narrow tag-driven rule, but remember that filters are evaluated against the object at execution time: removing a tag from an object usually stops a tag-scoped action from applying to it, though AWS documents that this is not guaranteed, so a tag-driven lifecycle should never be your only safety control.

• 📚 Did you know? Two lifecycle actions are routinely confused because both "remove" things: AbortIncompleteMultipartUpload is the only mechanism that cleans up incomplete multipart uploads, plain object expiration does not touch them (AWS: "Object expiration lifecycle configurations don't remove incomplete multipart uploads"), while ExpiredObjectDeleteMarker does the opposite job: it deletes a marker that is hiding nothing, so the previous version becomes current again. One frees abandoned bytes, the other un-hides data you still own (AWS S3 Lifecycle documentation, accessed Oct 2026).

---

2. Transitions: the waterfall and the age gates

2.1 The one-way waterfall

Storage classes are a downhill slope. Objects may move to a class downhill of their current class, never back up the ladder in place:

Two structural rules follow from that diagram: Glacier Flexible Retrieval can only be re-classed to Deep Archive, and Deep Archive has no outbound transition at all: escaping it means restoring the object and copying it somewhere else, which is a restore operation plus new storage, not a transition. Pending or failed replication status also blocks transitions in versioned buckets, so a broken replication rule quietly freezes your tiering plan.

2.2 Transition age versus minimum storage duration: the 16 July 2026 change

These are two different numbers and the exam tests the difference:

The trap is that removing the eligibility gate did nothing to the billing floor. An object transitioned to Standard-IA on day 0 and deleted on day 7 still bills 30 days of Standard-IA, because the minimum storage duration is a charge, not a rule. A study note that still tells you "you must wait 30 days before transitioning to IA" is stale; a study note that tells you "leaving IA early is free" has always been wrong.

2.3 The 128 KB floor

Since September 2024, objects smaller than 128 KB are not transitioned by default: an object under 128 KB configured with a plain Days-based transition will simply stay in Standard unless you opt in with an ObjectSizeGreaterThan filter or the x-amz-transition-default-minimum-object-size bucket-level setting. Legacy configurations created before that change keep the old behaviour until they are edited. And the floor cuts twice: those small objects also bill at the 128 KB floor in the IA and Glacier Instant classes, so a bucket full of 20 KB JSON files pays more per object than its byte count suggests (AWS S3 Lifecycle transition considerations, accessed Oct 2026).

2.4 Chained transitions must respect the minimum durations: Worked example E5

A single rule that hops through two classes has to leave each class only after that class's minimum duration has run. AWS's own example states that you cannot specify a rule transitioning objects to Glacier Instant Retrieval after 4 days and then to Deep Archive after 20 days: the second hop must be after at least 94 days:

Two separate rules can express the same intent (S3 will not reject them), but you then pay each class's minimum-duration charge anyway: the constraint moves from "rejected at configuration time" to "charged at billing time".

---

3. Expiration: what "delete" means, by versioning state

3.1 The same action, three different outcomes

3.2 Noncurrent versions: NoncurrentDays plus NewerNoncurrentVersions

NoncurrentVersionExpiration fires only when both conditions are exceeded: the noncurrent version is older than NoncurrentDays and it is beyond the newest NewerNoncurrentVersions versions you choose to retain (1 to 100). This is the difference between a bucket with an audit trail and a bucket with an ever-growing bill: NewerNoncurrentVersions: 5 with NoncurrentDays: 30 means "keep the five most recent noncurrent versions for at least 30 days each, then purge them permanently".

3.3 The canonical rule pair

Reading it back is the skill being tested: tier=hot objects under events/ enter Standard-IA immediately (Days: 0, legal since 16 July 2026), Glacier Instant at day 90, Deep Archive at day 365, the current version expires at day 2555 (about seven years), noncurrent versions move to IA after 30 days and are purged once older than 30 days and beyond the newest five, and incomplete multipart uploads are aborted after seven days. The abort rule carries no tag filter; that is why it sits in its own rule with an empty prefix filter rather than inside tier-down.

---

4. Lifecycle cost math: four worked examples

All prices below are Amazon S3 list prices for us-east-1, as of Oct 2026: always re-check aws.amazon.com/s3/pricing/ for your Region before you rely on a figure.

4.1 The price table you build the answers from

Other request facts from the same page: PUT $0.005 per 1,000 (Standard tier), GET $0.0004 per 1,000, DELETE is free, Intelligent-Tiering monitoring is $0.0025 per 1,000 objects per month, archives carry a 40 KB per-object overhead (8 KB at the Standard rate plus 32 KB at the archive rate), and leaving a class before its minimum duration bills the normal charge plus the pro-rated remainder.

4.2 Worked example E1: transition request fees at scale

You tier 1,000,000 objects in one nightly run. At $0.01 per 1,000 requests the fee looks trivial until you multiply:

The lesson is not the dollars, it is the double hit on small objects: if those 1,000,000 objects are 20 KB each, the transition fee applies to all of them and each one then bills at the 128 KB floor in the destination class: 6.4x its real size, 20,000,000 KB billed instead of 3,125,000 KB.

4.3 Worked example E2: Standard versus Standard-IA break-even

At what age does living in Standard-IA cost the same as living in Standard? Set the two charges equal for one GB held for L days:

So an object expected to live longer than about 16 days is cheaper in Standard-IA before any retrieval is considered; shorter than about 16 days it should stay in Standard, or use Intelligent-Tiering, which has no minimum duration and charges no retrieval fee. Retrieval flips the arithmetic again: Standard-IA charges $0.01/GB to read, so an object read 20 times a month will never win on storage alone. (Derived arithmetic from AWS S3 list prices, us-east-1, as of Oct 2026.)

4.4 Worked example E3: the minimum-duration cliff

One terabyte (treated here as 100,000 GB for arithmetic) transitions to Standard-IA on day 0 and is deleted on day 7:

And the cliff does not soften with time: deleted on day 1 instead of day 7, the Standard-IA bill is identical ($1,250.00) while one day of Standard costs $76.67, a 16x difference. The minimum storage duration is a fixed floor, not a pro-rated subscription: the day you transition sets the bill, not the day you leave. (Arithmetic derived from AWS S3 list prices, us-east-1, as of Oct 2026, not published by AWS.)

4.5 Worked example E4: ten terabytes, one year, five classes

Scale the last line to 100 TB: Standard is $27,600 per year against Deep Archive's $1,188 per year: a 23x spread that is the entire economic argument for lifecycle policies. What the table hides is equally examinable: Flexible and Deep Archive add restore fees plus a temporary S3 Standard copy while you read, and every hop above adds a transition request charge.

Hover any bar to read the number from Worked example E4: the same 10 TB held twelve months costs $276.00 in Standard and $11.88 in Deep Archive: storage-only arithmetic that deliberately excludes restore fees, transition request charges and the minimum-duration cliffs, all of which the exam can add back on top.

• 📚 Did you know? AWS's own 20-year S3 retrospective (13 March 2026) reports that customers have saved more than $6 billion in storage costs by using S3 Intelligent-Tiering instead of S3 Standard, and puts the headline storage price at slightly over 2 cents per gigabyte, roughly 85% below the 2006 launch price of 15 cents (as of Oct 2026, verify current pricing before use). Intelligent-Tiering's own economics are subtle: it has no minimum duration and no retrieval fee, but it charges $0.0025 per 1,000 objects per month to monitor them, for 10 million small objects that monitoring line alone is $25 per month, which is why size filters and lifecycle rules still beat automatic tiering on object-heavy buckets.

---

5. Versioning, delete markers and MFA Delete

5.1 What actually happens on each API call

Every PUT assigns a unique version ID; the bucket holds one current version plus any number of noncurrent versions. A DELETE without a versionId inserts a delete marker, making the previous version noncurrent: GET returns 404 while the bytes are fully intact and still billed. Permanent removal requires DELETE ?versionId=..., and deleting the marker itself restores the prior version.

5.2 MFA Delete

The net effect is the point of the feature: with MFA Delete on, an attacker holding normal delete permissions can hide data but cannot destroy it, and only an MFA-authenticated root can purge versions or suspend versioning.

• 📚 Did you know? MFA Delete and versioning answer different questions and are often conflated: versioning is a storage behaviour (keep every version), MFA Delete is a destruction control (make destruction expensive). You can run versioning for years without MFA Delete, and enabling MFA Delete does not change what a DELETE does; it changes who may make that delete permanent (AWS S3 Versioning and MFA Delete documentation, accessed Oct 2026).

---

6. Replication: CRR and SRR prerequisites

Replication copies objects between buckets; lifecycle rules move objects inside one bucket. Keeping those two mechanisms apart is half of Domain 2's lifecycle questions.

S3 Replication Time Control (RTC) carries an SLA: 99.99% of new objects replicated within 15 minutes. Without RTC, replication is best-effort with no SLA (AWS documents 24 to 48 hours as the general expectation). RTC is the answer whenever a question names a replication deadline; "eventually" is not a service level.

---

7. S3 Object Lock: retention that lifecycle cannot override

Object Lock is a feature of the in-scope Amazon S3 service; it is not a separate entry on the DEA-C01 in-scope list, and no task statement names WORM explicitly, so treat it as fair game precisely because S3 itself is in scope. It must be enabled at bucket creation, and enabling it implies versioning.

Retention attaches to object versions; delete markers are never WORM-protected; a bucket policy can raise the maximum retention to 100 years; and a lifecycle Expiration cannot delete a version under retention or legal hold; which is exactly why regulated archives combine Object Lock with lifecycle tiering rather than choosing one. The named regulatory hooks are SEC 17a-4, FINRA 4511 and CFTC 1.31.

---

8. DynamoDB TTL: epoch seconds, deletion lag, and the archival pipeline

8.1 The attribute contract

TTL is enabled per table and reads one attribute, its name is case-sensitive, whose value must be a Number holding Unix time in seconds:

8.2 Deletion lag: "within two days"

AWS's API reference states that DynamoDB "typically deletes expired items within two days", and warns that "items that have expired and not been deleted will still show up in reads, queries, and scans" (as of Oct 2026). Three consequences follow:

1. TTL is not a compliance delete. If a regulation demands instant erasure, TTL alone does not satisfy it.
2. Reads must filter. Add FilterExpression: "ttl > :now" or guard writes with a ConditionExpression until the deletion lands.
3. Storage keeps billing for up to 48 hours after nominal expiry.

8.3 Worked example E6: turning a retention policy into an epoch

A device registers at 1770000000 (epoch seconds) and the policy says "delete 90 days after creation":

The exam's classic distractor is a millisecond timestamp: it parses as a Number, so nothing errors: the item is simply never deleted, silently. The same silent failure applies to a mistyped attribute name, because the lookup is case-sensitive.

8.4 TTL plus Streams: the archival pipeline

TTL deletions are observable before they are complete, which is what makes the archive pattern work:

Because TTL deletions are performed by the service, the stream records carry userIdentity.type = "Service" and principalId = "dynamodb.amazonaws.com"; an event-source filter on that identity drops everything else. AWS's guidance shows the practical effect: filtering can cut Lambda invocations from roughly 2 million modifications per hour to 100,000 per hour, and Lambda processing a DynamoDB stream is not charged for GetRecords. Two constraints matter for exams: TTL deletions are identifiable only in the Region where they occurred, and Streams retain 24 hours, so a broken consumer must be repaired inside a day, not a week. Dashboards built on this pattern must tolerate up to 48 hours of post-expiry visibility.

• 📚 Did you know? The archive pattern exists because TTL gives you cheap deletion but no durable copy: the item leaves DynamoDB for free, but if nobody captured the stream record first, seven years of history are simply gone. Capturing the deletion event (or the item's final image) into S3 before the two-day window closes, then applying an S3 lifecycle rule to tier it, turns a purge into an archive, and the Lambda invocation cost is the only new line on the bill (AWS DynamoDB TTL with DynamoDB Streams guidance, accessed Oct 2026).

---

9. Archive selection: choose by retrieval SLA, not by price

Restoring costs the archive retrieval rate plus a temporary S3 Standard copy while the restored copy exists: an archive is cheap to hold and deliberately expensive to read. AWS documents restore throughput of roughly 1 to 2 PB per day per account. S3 Intelligent-Tiering offers an adjacent path: Standard and Bulk retrievals from its Archive Access tier (after 90 days without access) and Deep Archive Access tier (after 180 days) are free.

9.1 Worked example E7: minimum durations when you leave early

Early deletion (and early overwrite) before the minimum duration bills the normal charge plus the pro-rated remainder: the same clause that makes the Standard-IA cliff in Example E3 work. And remember the escape hatch: Deep Archive is one-way inside the lifecycle waterfall; getting an object back to Standard requires RestoreObject and then CopyObject.

---

10. Migration tooling I: AWS DMS and schema conversion

10.1 Homogeneous versus heterogeneous

AWS Database Migration Service moves databases, nothing else. Its two shapes are the exam's first fork:

Two DMS features decide whether conversion is even needed: change data capture (CDC) reads the source's native transaction logs (so no application changes are required for ongoing sync), and schema conversion rewrites DDL, stored procedures, functions and embedded SQL for the target engine.

10.2 Task types and the operational caveats

Caveats worth memorising: DMS runs on a replication instance (Multi-AZ optional) or as DMS Serverless; AWS states plainly that "AWS DMS CDC does not provide real-time replication … There are no SLAs for CDC latency", so a question promising "instant, guaranteed replication" via CDC is wrong.

10.3 The heterogeneous flow

10.4 The SCT status question (exam guide v1.1)

The downloadable AWS Schema Conversion Tool scanned application code for embedded SQL and supported more engines than its managed successor. As of exam guide v1.1 (12 December 2025), however, AWS SCT was removed from the DEA-C01 in-scope service list: the managed DMS Schema Conversion (web-based, built on the SCT engine) is what the guide now points at. Practical rule for exam day: "SCT" may still appear as legacy vocabulary inside a conversion narrative, but it can no longer be the named in-scope service you are asked to select; prefer AWS DMS and DMS Schema Conversion (exam guide revisions page, accessed Oct 2026).

• 📚 Did you know? A multi-month DMS CDC window is a compute bill, not just an architecture choice: since 2 December 2025, AWS Database Savings Plans cover Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream and AWS DMS at discounts of up to 35% (AWS Database Savings Plans announcement, 2 Dec 2025; accessed Oct 2026). So when a case study like EOS Group's reports a 50% infrastructure reduction, part of that story is the migration mechanism (DMS → S3 → Redshift) and part is the commercial lever on the databases that remain: a Domain 2 question about "minimising the cost of a long-running replication" can legitimately be answered with a commitment discount rather than an architecture change.

---

11. Migration tooling II: Snow Family, DataSync and Transfer Family

11.1 The three non-database movers

11.2 Worked example E8: the one-week rule, calculated

Moving 600 TB over a 1 Gbps link, ignoring protocol overhead:

Anything that will take more than about a week of sustained online transfer belongs in the offline conversation: for AWS customers who can still order devices that is the Snow Family, and the Snowball documentation banner directs new customers to AWS DataSync, AWS Data Transfer Terminal or AWS Partner solutions instead. For recurring movement (a nightly 2 TB NFS-to-S3 job over Direct Connect) the answer is always DataSync, and for supplier file drops over SFTP it is always Transfer Family.

---

12. Redshift load and unload: Task 2.3's first skill

Task 2.3's skill list opens with "Performing load and unload operations between Amazon S3 and Amazon Redshift", and AWS is blunt about which direction is correct: "We strongly recommend using the COPY command to load large amounts of data. Using individual INSERT statements … might be prohibitively slow."

AWS's own guidance for UNLOAD reports Parquet as "up to 2x faster … 6x less storage" than text: the same argument as the lake's format choice, arriving from the warehouse side. The pairing to remember: COPY in, UNLOAD out, both through S3, both Region-aware.

---

13. Data-lake organization: medallion zones, small files and cataloging

13.1 The three zones

A medallion layout gives each zone a different contract, and therefore a different lifecycle, storage class and catalog entry:

13.2 Catalog each zone separately

MSCK REPAIR TABLE scans an entire prefix tree, so registering bronze, silver and gold under one root with one repair statement risks mixing unrelated tables into a single catalog object. Catalog each zone in its own Glue database (or its own S3 Tables / Iceberg namespace) with its own Location, and prefer ALTER TABLE ADD PARTITION when you already know which partitions changed: the full-path scan is the expensive default, not the safe default.

13.3 Small files and the compaction loop

AWS's Athena guidance states the problem without hedging: "datasets that consist of many small files result in poor overall query performance", and the target is at most 1,000 files per partition. An hourly Glue job writing 3 MB files produces 720 files per day per partition: past the threshold before lunch.

Fix order (do them in sequence, not in parallel):

1. Make the source write bigger files (coalesce toward 256 to 512 MB).
2. Combine with Glue ETL (coalesce or repartition).
3. Reduce the number of partition keys: over-partitioning fragments data just as effectively as small writes do.

Managed compaction (the Glue optimizer for Iceberg/Parquet) fires when a table has more than 100 files with each file below 75% of the target size, where write.target-file-size-bytes defaults to 512 MB; the same optimizer family also offers snapshot-retention and orphan-file optimizers. Layouts that are not Iceberg need a Glue/Spark rewrite (bin-packing or repartition). For formats, aim at Parquet blocks around 128 MB or ORC stripes around 64 MB, and push high-cardinality keys into bucketing rather than more partition levels.

13.4 Worked example E9: what a bronze zone's lifecycle actually earns

A bronze zone holds 10 TB of event data with this rule set (all prices us-east-1, as of Oct 2026): Standard for the first 30 days, Standard-IA for days 31 to 180, Glacier Instant for days 181 to 365, expiry at day 365. Approximating each window as a fraction of a year:

The transition fees are $1.20 against a $185 saving: the whole argument for lifecycle policies in one line: on object stores, storage class dominates, request fees are rounding errors, and early-deletion minimums are the only real trap (derived arithmetic from AWS S3 list prices, as of Oct 2026).

• 📚 Did you know? Partitioning, bucketing and file size are three different eliminations and the exam keeps them apart: partitions prune directories (Hive-style year=2026/month=10/), bucketing prunes hash buckets inside a partition (the right home for high-cardinality keys), and file size fixes the listing tax: over-partitioning fragments data just as badly as writing tiny files, which is why AWS's guidance says to partition on low-cardinality columns that queries actually filter, usually time (AWS Athena partitioning and performance guidance, accessed Oct 2026).

2026 Updates (as of October 2026)

---

Real-World Case Studies

Every figure below is customer- or AWS-claimed and unaudited, with the source named so you can check it. The examinable point is the pattern, which lifecycle mechanism, retention control or migration tool did the work, not the marketing.

Case A, Nasdaq: an S3 lake with Glacier and Object Lock

"We were able to easily support the jump from 30 billion records to 70 billion records a day because of the flexibility and scalability of Amazon S3 and Amazon Redshift.": Robert Hunt, VP Software Engineering, Nasdaq

Read it as a lifecycle stack, not a scale boast: S3 as the write path, Glacier for the archive, Object Lock for retention, Redshift and Spectrum for the read path. That is exactly why "copy the data into the warehouse and delete the lake" is a distractor: the lake stays authoritative, and retention is enforced by a bucket-level WORM policy rather than by a person remembering to keep the backups.

Case B, EOS Group: DMS-led warehouse migration

"By removing the need for on-premises infrastructure, EOS Group achieved a 50 percent reduction in infrastructure costs …"

The examinable detail is the sequence: DMS lands the database, S3 is the staging layer, Redshift loads from S3: the same shape as Case A's write path, arrived at from the migration side. "DMS writes directly into the warehouse and that is the whole migration" is the distractor; staging through S3 is what makes the load repeatable and lets lifecycle rules manage the landing data afterwards.

Case C, FINRA: a regulated S3 lake at surveillance scale

"FINRA processes approximately 6 terabytes of data and 37 billion records on an average day … On busy days, the stock markets can generate 75 billion+ records.": John Brady, VP Cyber Security/CISO, FINRA

Read FINRA as the cost-separation and retention case: S3 holds the durable, lifecycle-managed copy (hundreds of millions of objects that must age into cheaper classes and stay defensible for regulators), while EMR and Redshift are rented compute that can be re-sized or retired without touching the archive. The distractor to reject is "buy a bigger warehouse up front": FINRA's published outcome is the opposite, and the pattern is identical to Nasdaq's, just with a regulator rather than an exchange deadline as the forcing function.

Case D, BMW Group: an on-premises lake replaced by S3 zones and the Glue catalog

The examinable detail is the catalog posture: each layer's data lives in S3, but the schemas are registered per zone in the Glue Data Catalog: exactly the "catalog each zone separately" rule from Section 13 of this lesson. When a question describes producers writing through Firehose into S3 zones that consumers query with Athena, it is describing BMW's published architecture; the wrong option is always the one that skips the catalog or merges every zone into one unmanaged prefix tree.

• 📚 Did you know? FINRA's published volumes make a nice derived-arithmetic drill you can do in your head: 37 billion records ÷ 86,400 seconds ≈ 428,000 records/second on a typical day, and 75 billion ≈ 868,000 records/second on a busy one (derived from AWS-published totals: label it as your own arithmetic, never quote it as an AWS figure). That sustained rate is why FINRA's answer was never a bigger single warehouse: at that scale you need a storage layer (S3) whose lifecycle and cost curves are independent of whatever query engine you rent this quarter (AWS case material, accessed Oct 2026).

• 📚 Did you know? Both case studies converge on Amazon S3 as the pivot of the lifecycle: Nasdaq writes there and archives from there, EOS stages there before Redshift reads from it. That repetition is the exam hint: when a Domain 2 question needs a place where retention, tiering, replication and cataloging can all be applied to the same bytes, the answer is almost always S3 plus a lifecycle rule, with DynamoDB TTL as the parallel answer for item-level expiry in a NoSQL store (AWS case studies, accessed Oct 2026).

---

Practice Questions

Comparative Verdict: how this topic compares on exam day

• Versus other clouds: the DEA-C01 guide tests AWS services only: Amazon S3 and S3 Glacier, Amazon DynamoDB, AWS DMS, AWS DataSync, AWS Snow Family, AWS Transfer Family, Amazon Redshift, AWS Glue. Nothing in the guide compares AWS with another provider, so any option pivoting to a competitor's tiering, archive or migration offering is out of scope by construction; answer with an in-scope AWS service or an AWS-published rule (minimum durations, retrieval SLAs, deletion lag).
• Versus self-managed / on-premises: you can build lifecycle automation yourself with cron jobs and scripts, but then you own retries, partial failures, audit evidence and the retention guarantee. The exam's preference is the declarative, managed control: lifecycle rules for storage classes, TTL for item expiry, Object Lock for WORM, DMS for database movement. Choose the option with the least undifferentiated operational work, and note that on-premises is still the correct answer whenever the scenario explicitly requires staying on premises (a disconnected site, a legal data-residency bar).
• Versus another AWS service doing a neighbouring job: lifecycle moves objects inside a bucket; replication copies objects between buckets; Object Lock blocks deletion; TTL expires DynamoDB items; DataSync syncs files; Transfer Family exposes a protocol; DMS moves databases; Glue compacts lake files. A question asking "how do I stop paying for last year's data" never answers "replication", and one asking "how do I guarantee a 15-minute copy to another Region" never answers "lifecycle"; those are RTC and tiering respectively.
• Versus a manual, human process: Nasdaq's WORM retention and EOS's staged DMS migration are outcomes of mechanisms (Object Lock, lifecycle rules, DMS to S3 to Redshift), not of an engineer remembering to delete or archive. On the exam, prefer the option that codifies the policy over the option that depends on someone remembering it, and treat every published percentage as "the customer achieved", never as "AWS guarantees".