AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Delete retained data across every copy
Completed by the knowledge check
Learning objective
Enforce retention and deletion requirements with Amazon S3 Lifecycle policies and application-level deletion.
Core idea
For an architect managing a foundation model application, retention is a contract across copies. A source document can generate extracted text, chunks, embeddings, conversation history, caches, application traces, and invocation logs. Expiring one S3 object does not remove every representation of that document.
Use S3 Lifecycle for predictable age-based actions in S3. Use an application deletion workflow for subject- or document-specific requests and for derived stores that S3 does not control. Define what counts as inaccessible, what counts as permanently removed, and what evidence completes the request. These are distinct milestones, especially when versioning or asynchronous processing is involved.
See 3.2.8 for service-side model retention and 3.2.9 for minimizing sensitive log content. Customer-managed Lifecycle rules do not govern service-side retention required by a model.
How it works
Establish a copy inventory
Assign each retained representation a purpose, owner, lifetime, and deletion mechanism. Keep a stable application document identifier that maps the source object to its derived records. Include revisions and any object version IDs needed to remove earlier data. A source path alone is insufficient when the same path can hold several versions.
Separate time-based retention from an individual deletion request. A policy might expire ordinary records after a defined lifetime, while an authorized request requires removing one person’s eligible records sooner. Both need defined handling for records that must remain retained under an approved exception.
Keep the request’s evidence minimal. Record the requested scope, affected stores, completion states, and exceptions without copying the deleted personal content into a deletion audit trail. Otherwise the erasure process creates another retained copy of the information it removes.
Define S3 Lifecycle actions precisely
An S3 Lifecycle rule has a Status of Enabled or Disabled and a Filter that selects its scope, such as a key prefix or object tags. The rule’s actions determine whether selected objects transition to another storage class or expire. A transition changes storage placement; it is not a deletion mechanism.
Expiration applies to the current object version. In a nonversioned bucket, S3 queues the object for asynchronous permanent removal. In a versioning-enabled bucket, expiration usually inserts a delete marker and makes the previous current version noncurrent. The retained version still exists even though an ordinary request no longer returns it as the current object.
Use NoncurrentVersionExpiration to permanently delete noncurrent versions according to their noncurrent age. If you also configure a maximum number of newer noncurrent versions to retain, deletion depends on that additional condition. Do not assume a day count alone removes every old version when the rule also retains a version count.
Expired delete markers and unfinished uploads are separate surfaces. ExpiredObjectDeleteMarker can remove a marker when no noncurrent versions remain. AbortIncompleteMultipartUpload stops uploads left incomplete beyond the configured time. Ordinary object expiration does not remove incomplete multipart uploads.
AWS documents constraints for these cleanup rules: AbortIncompleteMultipartUpload and expired-delete-marker cleanup cannot use a filter based on object tags. Use an appropriate prefix-based cleanup rule rather than assuming one tag-filtered expiration rule covers everything.
Lifecycle also has retention and processing exceptions. S3 does not act on noncurrent versions with Object Lock applied, or on current or noncurrent versions with Pending or Failed replication status. Surface those cases in the retention inventory rather than promising unconditional removal at a configured age.
Rules apply to existing matching objects as well as later ones. Evaluate the selected scope before enabling expiration because an old object can already be eligible. AWS documents asynchronous removal and a possible delay after the expiration date; an age rule is not a synchronous deletion receipt.
Implement version-aware application deletion
For targeted S3 deletion, DeleteObject without a version ID permanently deletes an object only when versioning is not enabled. In a versioning-enabled bucket, the same operation inserts a delete marker. To permanently remove a particular version, include its versionId. In a versioned bucket, expiration hides a version; only a version-aware action removes it.
Use ListObjectVersions to inspect the versions and markers in the intended scope, then remove eligible versions with explicit version IDs. Verify the resulting state rather than equating a successful unversioned-looking delete request or a missing current object with removal of historical content. Permissions and retention controls can prevent parts of the request from completing; record the actual outcome per affected version.
The application workflow also needs a race boundary. Mark the document unavailable to normal retrieval before deleting its projections, and prevent ongoing ingestion or replay from recreating it. This is an application rule: S3 deletion does not coordinate every writer or cache on your behalf.
Track each store’s outcome independently and make retries safe. A retry should continue unfinished work, not republish deleted content or erase unrelated revisions. Distinguish the request being accepted, access being removed, and physical cleanup being confirmed. Those statuses are your application’s completion contract.
Remove indexed and logged representations
For a synchronized Bedrock Knowledge Bases data source, removing files from the source requires another synchronization. The documented resync behavior removes deleted documents from the vector store. StartIngestionJob starts synchronization. Track its returned ingestionJobId with GetIngestionJob, then inspect status: COMPLETE and statistics.numberOfDocumentsDeleted before counting the indexed copy as removed. Verify retrieval behavior as well. See 1.4.11 for document-level reconciliation and ingestion evidence.
Resource deletion has a separate control. A data source’s dataDeletionPolicy selects DELETE or RETAIN for data converted into vector embeddings when the knowledge base or data source resource is deleted. DELETE removes that converted data; RETAIN leaves it. The vector store itself is not deleted by either setting. Do not confuse deleting one source file, deleting the data-source resource, and deleting the storage resource.
Application histories, caches, and exports require their own store-specific deletion logic. Maintain their relationship to the source or subject so the workflow can find them. If a restore or replay can reintroduce deleted material, define how the deletion record is reapplied before the restored data becomes available.
CloudWatch Logs retention is another independent setting. PutRetentionPolicy sets retentionInDays for a log group. Expired events are marked for deletion, and AWS says physical deletion typically takes up to 72 hours afterward, with rare longer delays. Do not describe a log retention setting as an immediate per-person deletion API. Avoid storing prohibited personal content in the first place; see 3.2.9.
Key distinctions and trade-offs
Expiration versus permanent removal: In a versioned bucket, current-version expiration can hide the object while retaining its data as a noncurrent version. Permanent cleanup needs the correct noncurrent-version action or explicit version deletion.
Storage deletion versus retrieval exclusion: Preventing normal access can be an immediate application milestone. Removing every stored projection is a separate workflow with its own evidence and exceptions.
Resource policy versus document synchronization: dataDeletionPolicy governs converted data on resource deletion. Source-file changes use synchronization to update the index. Neither automatically manages unrelated histories, logs, or exports.
Architecture / decision scenario
A document assistant stores versioned source documents, derived retrieval content, and sanitized diagnostics. Its ordinary retention rule expires current source objects and separately expires noncurrent versions. Prefix-scoped rules clean unfinished uploads and expired delete markers. CloudWatch log groups have an approved retention setting independent of S3.
An authorized deletion request arrives before the ordinary retention age. The application blocks retrieval for the document, stops its ingestion route, and enumerates source versions. It deletes eligible versions with DeleteObject and explicit versionId values, recording any protected versions as exceptions.
The workflow then synchronizes the Knowledge Bases source and verifies removal from retrieval, deletes related application histories and caches, and checks export copies. It completes only when each required store reports its defined outcome. A source 404 is an access observation, not the workflow’s proof of complete deletion.
Common exam traps
- Choosing a storage-class transition to meet an erasure requirement.
- Treating a delete marker as permanent deletion of all versions.
- Assuming current-version expiration also removes noncurrent versions or unfinished uploads.
- Promising exact deletion time from an asynchronous Lifecycle action.
- Expecting a deleted source file to disappear from retrieval without synchronization.
- Assuming knowledge-base resource deletion also deletes the vector store and application copies.
What to remember
- Inventory every copy and assign a mechanism and completion signal.
- Match Lifecycle actions to current versions, noncurrent versions, markers, and unfinished uploads.
- Use explicit version IDs for permanent targeted deletion in versioned buckets.
- Coordinate index synchronization and application deletion, then verify each store separately.
Knowledge check
An authorized request requires permanently removing one source document from a versioning-enabled S3 bucket, including its earlier revisions. Which deletion meets it?
DeleteObject on the document’s key, then confirm a 404 on readListObjectVersions for the key, then DeleteObject with each eligible versionIdExpiration scoped to the document’s keyDeleteObject without a version ID inserts a delete marker, so the read fails while every version remains. Permanent removal of a version needs its versionId . A transition only moves storage, and current-version expiration also leaves noncurrent versions behind, asynchronously.A versioning-enabled bucket has a Lifecycle rule that expires current versions after 365 days. A year later, storage for expired documents has not dropped, and old content still exists. Which action removes it?
ExpiredObjectDeleteMarker in the same ruleAbortIncompleteMultipartUpload in the same ruleNoncurrentVersionExpiration with a reviewed noncurrent ageNoncurrentVersionExpiration permanently deletes those versions, subject to any newer-version count, Object Lock, or replication status. Delete-marker cleanup applies only once no noncurrent versions remain.A source file is deleted from the S3 data source of a Bedrock knowledge base, but its chunks are still retrieved. What should the deletion workflow do next?
dataDeletionPolicy set to DELETEStartIngestionJob , followed by GetIngestionJob showing COMPLETE and numberOfDocumentsDeleted , plus a retrieval check, is the evidence. Deleting the whole data source removes every document’s converted data to fix one.A team retires a knowledge base data source configured with dataDeletionPolicy: RETAIN and deletes the data-source resource. What happens to its vector embeddings?
RETAIN keeps the converted data when the knowledge base or data source resource is deleted; DELETE removes that data. Neither setting deletes the vector store itself, so retiring a source needs its own plan for the store and for application copies.A bucket’s only Lifecycle rule uses an object-tag filter to expire tagged documents. Abandoned multipart uploads of large documents keep accumulating. Which change addresses them?
AbortIncompleteMultipartUpload to the existing tag-filtered ruleExpiration so that uploads expire soonerAbortIncompleteMultipartUploadNoncurrentVersionExpiration to the existing tag-filtered ruleAbortIncompleteMultipartUpload does. That action cannot be specified in a rule whose filter uses object tags, so it belongs in a separate rule scoped by prefix.