5.3 - Data lifecycle (Macie, Object Lock, backups, retention)
AWS Certified Security Specialty objective 5.3 covers what happens to data between the day it is written and the day it must disappear. Amazon Macie discovers sensitive data in S3 and a custom data identifier catches an internal identifier format that no managed pattern knows, with findings routed to EventBridge for an immediate automated reaction. Retention is enforced with S3 Object Lock, which requires versioning on the bucket, uses compliance mode when nobody including the root user may shorten the period, and uses a legal hold when an investigation must freeze versions for an unknown duration with no fixed end date. Lifecycle rules move objects to cheaper classes and expire them, but a transition that never fires usually breaks a minimum age rule, and storage that keeps growing in a versioned bucket points at noncurrent versions and incomplete multipart uploads that no rule cleans up. Backups resist a compromised administrator when the copy lands in a separate account with AWS Backup Vault Lock, RDS automated backups stop at their maximum window so long retention needs copied snapshots, a public manual snapshot must be made private at once, DynamoDB TTL expires records cheaply, S3 Inventory reports encryption status at scale, and deleting the KMS key crypto-shreds millions of objects. Expect retention and disposal scenarios.
Freeze object versions for an unknown duration with no end date = S3 Object Lock legal hold, not a retention period. Backups an attacker with production admin cannot delete = separate account plus AWS Backup Vault Lock in compliance mode. Make millions of objects unreadable in minutes = delete the KMS key, crypto-shredding.
Practice questions
1. What distinguishes an AWS managed KMS key from a customer managed KMS key?
- An AWS managed key can be deleted immediately, whereas a customer managed key must wait for a mandatory pending window
- An AWS managed key encrypts only metadata, whereas a customer managed key is required to encrypt the payload of any object
- You cannot edit the key policy or the rotation schedule of an AWS managed key (correct answer)
- An AWS managed key lives outside your account and is billed to the service team that created it on your behalf
An AWS managed key is created for a service in your account, but its policy and its yearly rotation are fixed by AWS and cannot be changed, which is the reason to prefer a customer managed key when you need control. You cannot delete an AWS managed key at all, both kinds encrypt real payloads, and the key does live in your account and appears in your CloudTrail.
2. What happens to data encrypted under a KMS key when automatic key rotation occurs?
- Nothing: old backing keys are retained so existing ciphertext still decrypts (correct answer)
- Every ciphertext is re encrypted in the background by KMS and the applications must refresh their cached data keys
- The key identifier changes, so applications have to be updated with the new ARN before their next decryption call
- Older ciphertext becomes unreadable, which is why AWS recommends re encrypting data before each rotation date
Rotation creates new backing key material for future encryption while keeping every previous version, so decryption of old ciphertext keeps working transparently. KMS never re encrypts your data, the key ID and ARN stay identical, and nothing becomes unreadable.
3. A KMS key was created with imported key material. Which statement about it is correct?
- It supports automatic annual rotation on the same schedule as a key whose material was generated inside KMS by the service itself
- Its material is copied into every region where a multi region replica of the key is created for you automatically
- It can be converted back to KMS generated material later with the update-key-material operation, without downtime
- You are responsible for keeping a copy of the material, and the key becomes unusable if the material expires or is deleted (correct answer)
With imported material AWS holds no copy you can fall back on, so losing your source means losing the data, and an expiration date or a manual delete makes the key unusable until you re import the same bytes. Imported material does not support automatic rotation, it is not replicated for you, and no operation converts the key back to KMS generated material.
4. What is the minimum waiting period before a scheduled KMS key deletion takes effect?
- Seven days (correct answer)
- Twenty four hours, after which the key material is destroyed and the key identifier is released for reuse
- Thirty days in every case, with no possibility of choosing a shorter or a longer waiting period at deletion time
- There is no waiting period, because deletion is immediate as soon as the confirmation dialog has been accepted
KMS enforces a pending window that you set between seven and thirty days, during which the key is unusable but can still be cancelled, precisely because deleting a key destroys every ciphertext under it. Deletion is never immediate, thirty days is the default rather than a fixed value, and a key identifier is never recycled.
5. Which element ultimately decides whether a principal may use a customer managed KMS key?
- The IAM identity policy alone, because KMS defers all authorisation decisions to the identity side of the evaluation
- The key policy, possibly combined with IAM policies and grants (correct answer)
- The tag set applied to the key, since KMS evaluates attribute based access control before any policy document is read
- The order in which permissions were granted, the most recent statement overriding the earlier ones for that principal
A KMS key is one of the resources whose resource policy is mandatory: if the key policy does not allow access, directly or by delegating to IAM, nothing else can. Identity policies alone are insufficient without that delegation, tags refine conditions but never replace the policy, and grant order is irrelevant.
6. A Lambda function in account B must decrypt objects encrypted with a KMS key owned by account A. What is required?
- Nothing beyond the execution role policy, because KMS grants cross account access implicitly to any principal inside the same organization
- A copy of the key material exported from account A and imported into an identically named key created in account B
- The key policy in A must allow account B, and the execution role in B must allow kms:Decrypt (correct answer)
- A VPC peering connection between the two accounts so that the KMS API call can reach the key from the other side
Cross account KMS access needs both halves: the resource side must allow the external account and the identity side must grant the action. There is no implicit organization wide access, KMS key material can never be exported, and KMS is a regional API endpoint that requires no network peering.