A city open-data portal stores non-sensitive public datasets beside confidential case files in separate S3 buckets. Security wants default encryption that matches classification. Which approach is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Not every box in the warehouse needs the same padlock. Open data can use SSE-S3; confidential buckets deserve SSE-KMS so you control and audit the keys. Turning encryption off or public-reading everything ignores classification.
Full Explanation
Classification-aware default encryption is the right pattern for a city open-data portal that coexists with confidential case files in separate S3 buckets. Non-sensitive open datasets can use SSE-S3 default encryption—Amazon S3 manages the keys while objects remain encrypted at rest with minimal operational overhead. Confidential case-file buckets should use SSE-KMS so the city controls key policies, can separate duties via grants, and gains clearer CloudTrail visibility into key usage. Matching encryption controls to sensitivity avoids both under-protecting restricted data and over-complicating public datasets.
Disabling default encryption on all buckets to avoid key management overhead abandons a baseline control and invites accidental plaintext storage. Applying the same public-read ACL to every object regardless of sensitivity erases classification boundaries and can publish confidential case material. Client-side XOR obfuscation without S3 server-side encryption is not cryptography; it fails modern security reviews and provides no durable AWS-managed protection or audit trail.
Exam caveat: SSE-S3 vs SSE-KMS is a frequent comparison—pick KMS when key policy, CMK audit, or cross-account key control matters. Operational check: set bucket default encryption per classification, block public access on confidential buckets, verify PutObject rejects unencrypted uploads if you enforce via bucket policy, and sample CloudTrail for KMS events on the sensitive bucket.