SAA-C03 Practice Question 89: Lifecycle Abort Incomplete Uploads

After a multipart upload is initiated, S3 retains every uploaded part until the upload is completed or stopped, and you are billed for that storage the whole time. Those parts belong to an in-progress upload rather than to an object, so ListObjectsV2 does not return them, which produces exactly the symptom here, a billed figure far larger than the sum of the visible objects. Frequently interrupted transfers of very large objects is the classic way to accumulate them. AWS recommends as a best practice a lifecycle rule using the AbortIncompleteMultipartUpload action, with a DaysAfterInitiation value such as 7, which stops stale uploads and deletes their parts, for existing uploads as well as future ones.

Option A is a reasonable instinct but does not fit the evidence. Pagination limited to 1,000 keys would make the listing far smaller than the true size, not 40 TB out of 90 TB, and it would not explain a bill that keeps climbing.

Option B is factually wrong about the storage classes. Objects in Glacier Flexible Retrieval are billed at that class's rate; only the in-progress parts of a multipart upload to it are staged at S3 Standard rates. Deep Archive would not address invisible storage either.

Option D describes a real cause of hidden storage in other buckets, but the question states that versioning is not enabled, so there are no noncurrent versions and no delete markers to expire. A delete marker holds no object data in any case.

Reference: Configuring a bucket lifecycle configuration to delete incomplete multipart uploads