Protected version retention and recovery

Skill and boundary

S3 Object Lock protects a specific object version from deletion or overwrite during retention or a legal hold, and it works with Versioning. An object key alone is not a proof unit: a new version can be written under the same key and a delete marker can appear above a protected version. Thus 'does an ordinary GetObject by current key return data?' differs from 'does the protected versionId remain recoverable?'. Record the version identifier, retain-until date, encryption key, and access policy in the recovery evidence. A retention flag by itself does not prove that the team can decrypt the object or that a copy exists in the required recovery Region.

Decision model

Distinguish a retention period, which expires according to its date, from a legal hold, which remains until an authorized party removes it. Do not invent a regulatory number of years; the duration comes from the organization's actual requirements. When Object Lock is combined with replication, prepare a destination that also supports Object Lock and consider permissions for copying retention and hold metadata. Replication is asynchronous, so a replication rule alone does not prove that the last source version arrived before failure. Check the exact version's replication status, time gap, and destination decryption rights. Protection from accidental deletion and recovery from a regional failure are related goals with different tests.

Worked case

The solution first isolates the faulty writer so that more misleading versions are not created. Record `versionId`, why it was chosen, and its retention state. Recover its content to a new working key after rights review; do not try to rewrite the protected version. Validate the data hash or the organization's approved integrity check, verify that the consumer can read the restored file, and keep an audit record. If the destination is the recovery target, repeat the test against the version that actually arrived there rather than inferring from the source. Review the key policy in that Region: encrypted bytes without decryption rights do not meet the recovery objective. Keep a negative test showing that deletion of the protected original is refused during retention.

The counterfactual changes the answer. If `v17` has not reached the destination when the source Region fails, an enabled replication rule is not evidence of zero RPO. Find the latest verified destination version, calculate the data-time gap, and compare it with the agreed target. If the destination key is unavailable or its use is denied, KMS authorization becomes part of recovery; adding only S3 grants cannot help. If Versioning was not active when an earlier object was written, do not invent a protected versionId. The answer must be bounded by the observed version listing, replication evidence, and actual key state rather than a generic backup claim. A restore receipt should connect object and version IDs, why the content is trusted, retention or hold state, reader identity, actual encryption key, and data comparison after copying to a working path. Restoring an old version under the original key can affect consumers and the newest version, so a new review path may be safer. Test ordinary authorized reader access, not only an administrator with broader rights. Removing a delete marker in production needs the data owner's decision.

Exercise and product

Solution review