Encryption, keys, and data restore

Protection decision

SAA-C03 task 1.3 tests selection of data controls, not the phrase “encrypt it.” Classify the data first: who reads it, where it moves, how long it remains, and what loss is tolerable if it is deleted or corrupted. Separate four decisions: access authorization, transport protection, encryption at rest and key control, and backup with a tested restore. Encryption cannot stop an incorrectly authorized identity from deleting records. Replication alone cannot promise recovery from a logical mistake that propagates to both destinations. Retention periods must come from case requirements, not an invented legal rule.

Keys, transport and copies

For a client-to-application path, use TLS valid for the hostname and identify where that TLS session ends. Determine whether a new protected session to the backend is required by the design. A TLS certificate does not grant the application identity data-read permission. In S3, distinguish `s3:GetObject` from use of a KMS key when an object is encrypted with a customer managed key. Downloading an SSE-KMS object may require `kms:Decrypt` and a key policy that allows appropriate use. Adding `kms:Decrypt` to IAM alone cannot help if the key policy does not permit that access. Cross-account KMS access requires a compatible design in the key policy and the other account's IAM delegation. Sharing a bucket does not automatically share its encryption key.

Classification also limits exposure through monitoring. Request logs help trace failures, but do not place access tokens or sensitive report contents in general logs. Scope the runtime role to the object prefixes it needs, and inspect resource and endpoint policies when present. A backup account separated from production can reduce the chance that one compromised identity deletes both production and recovery data, but separation needs working policies and restoration, not just two account names.

Keep copies or object versions when a deletion or incorrect update must be reversible, and then test restoring a chosen point in time. S3 Versioning retains multiple object versions, but versioning alone is not an independent backup plan. S3 Replication requires versioning on source and destination; copy timing depends on its configuration and conditions, so do not promise an unmeasured recovery window. Object Lock can protect a specified object version under a suitable retention setting, but it does not prevent a newer version or delete marker from appearing above it. When selecting AWS Backup or a service-specific mechanism, record the intended recovery point, its location, who can initiate restoration, and a test result. RPO and RTO are examined more deeply in the resilience module; here the control must produce readable data after an incident.

Worked case: sensitive reports

Start with the evidence: S3 object authorization is supplied as allowed, but encryption adds a separate decision. Confirm which key encrypted the object instead of assuming a default key, then inspect CloudTrail or the error detail for the denied operation. Change the key policy in A to permit the named B role to perform the necessary decrypt operation, and give the role corresponding IAM permission on the key ARN under the cross-account access model. Keep `s3:GetObject` scoped to the report prefix; do not grant `kms:*` or the whole B account when one role suffices. Test an approved report download, denial of an out-of-prefix report, and denial of key use by a different B role. If a conditional bucket-policy Deny exists or the object uses a different key, diagnose that fact rather than claiming this change is guaranteed to work.

After fixing the read path, set a hypothetical training retention design: a daily independent backup is kept for 30 days while production object versions follow the organization's documented policy. Thirty days is an input for this exercise, not a legal period or a general AWS requirement. Delete a test report, restore an earlier version into an isolated location, and inspect its contents and the ability to decrypt it after restoration. The decision is to separate object-read authorization from key use and prove the restore path. Its limit is that daily backups may lose changes since the last backup, while one sample restoration does not measure every production recovery time.

Separate creation, transfer, and actual restore of protected data. A copied encrypted object proves only that ciphertext exists, not that the recovery principal can use its KMS key or retrieve a valid version. Record the asset, encryption mode, key owner, reading principal, key policy, and a real decrypt outcome. Cross-account access requires both the caller side and the key policy to be checked. Restore a selected version, verify its contents, and measure recovery-point age against RPO. Replication of a logical deletion or corrupt object does not replace protected historical versions or an independent recovery point.

Exercise and product