A company is designing a data lake on Amazon S3. Data is ingested from multiple sources and stored as Parquet files partitioned by date. The company needs to ensure that only authorized users can access the data, and that the data is encrypted at rest. Which TWO actions should the company take to meet these requirements? (Choose TWO.)
Trap 1: Use client-side encryption before uploading to S3.
Client-side encryption protects data before upload but places key management entirely on the company, and it does nothing to enforce which users may access objects. It is tempting because it satisfies encryption at rest, yet SSE-KMS with bucket policies and IAM handles both authorisation and encryption natively.
Trap 2: Enable S3 server access logging.
Server access logging records requests made to the bucket for auditing purposes; it neither restricts access to authorised users nor encrypts stored objects. It is tempting because logging sounds security-related, but the requirement is authorisation and encryption at rest, which logging cannot deliver.
Trap 3: Use a bucket ACL to grant access to the data lake.
Bucket ACLs grant coarse read/write permissions to predefined grantee groups and cannot express the fine-grained, identity-based authorisation the scenario needs. They are tempting as a legacy S3 access mechanism, but IAM policies with bucket policies provide the required least-privilege control.
- A
Enable default encryption with SSE-KMS on the S3 bucket.
SSE-KMS default encryption ensures every object written to the bucket is encrypted at rest using AWS KMS keys, satisfying the encryption requirement. It also enables granular key policies and audit trails via CloudTrail, supporting control over who can decrypt the data lake contents.
- B
Use client-side encryption before uploading to S3.
Why it fails: Client-side encryption protects data before upload but places key management entirely on the company, and it does nothing to enforce which users may access objects. It is tempting because it satisfies encryption at rest, yet SSE-KMS with bucket policies and IAM handles both authorisation and encryption natively.
- C
Enable S3 server access logging.
Why it fails: Server access logging records requests made to the bucket for auditing purposes; it neither restricts access to authorised users nor encrypts stored objects. It is tempting because logging sounds security-related, but the requirement is authorisation and encryption at rest, which logging cannot deliver.
- D
Use a bucket ACL to grant access to the data lake.
Why it fails: Bucket ACLs grant coarse read/write permissions to predefined grantee groups and cannot express the fine-grained, identity-based authorisation the scenario needs. They are tempting as a legacy S3 access mechanism, but IAM policies with bucket policies provide the required least-privilege control.
- E
Configure an S3 bucket policy that allows access only from specific IAM roles.
An S3 bucket policy restricting access to specific IAM roles enforces least-privilege authorisation at the bucket level, ensuring only approved identities can read or write the Parquet data. This directly satisfies the requirement that only authorised users access the data lake.