Open-data park assets need simple server-side encryption, while regulated PHI attachments need customer managed keys with CloudTrail-visible key use. How should developers choose?
Select an answer to reveal the explanation.
Short Explanation
SSE-S3 is the simple city lockbox for open-data photos; SSE-KMS with a CMK is the sealed vault with a badge reader that CloudTrail can see. PHI wants the auditable CMK path. Turning encryption off to quiet logs is not a security strategy.
Full Explanation
Open-data park assets that need simple server-side encryption can use SSE-S3. Regulated PHI attachments that need customer managed keys with CloudTrail-visible key use should use SSE-KMS with CMKs so Decrypt/GenerateDataKey style events are attributable. Matching encryption mechanism to data classification keeps ordinary public assets simple while elevating controls where auditors require key-policy ownership and key-usage evidence.
Using SSE-S3 for PHI because “CMKs cannot encrypt S3 objects” is false and under-controls regulated data. Disabling encryption on both open data and PHI to avoid CloudTrail noise rejects security for convenience. Claiming developers must always use only client-side encryption and that SSE-S3/SSE-KMS are never appropriate ignores standard server-side patterns for municipal buckets.
Exam caveat: SSE-KMS with CMKs incurs KMS API costs and requires key-policy design; SSE-S3 is simpler when customer key control is not required—choose deliberately per dataset. Operational check: upload a park asset and confirm SSE-S3; upload a PHI attachment with SSE-KMS CMK and find corresponding KMS events in CloudTrail; attempt GetObject without kms:Decrypt and confirm denial for the PHI object.