A municipal data lake on S3 serves many departments. Coarse IAM on whole buckets is too blunt for table- and column-level access. Which service should the architect use for fine-grained lake permissions?
Select an answer to reveal the explanation.
Short Explanation
Whole-bucket IAM is a sledgehammer when departments need table-level keys. Lake Formation adds that fine-grained governance on the lake. CloudFront cookies and security groups are not how you authorize Glue/Athena tables.
Full Explanation
A municipal data lake on S3 that serves many departments quickly outgrows coarse IAM on whole buckets when analysts need table- and column-level access. AWS Lake Formation supplies governed permissions for catalog tables and columns, letting the architect grant a parks GIS team access to specific datasets without opening an entire bucket of mixed civic data. That fine-grained model complements S3 IAM and Glue Data Catalog metadata rather than replacing encryption or network controls; it is the service purpose-built for lake authorization beyond blunt object prefixes.
Amazon CloudFront signed cookies authorize temporary access to distributed content; they are not a lake table/column authorization model for Athena or analytics consumers. Public S3 website hosting with directory listings expands exposure and provides no governed column security. Security group rules cannot attach to S3 objects—security groups are ENI/network constructs—so that option is conceptually invalid for object or table ACL.
Exam caveat: Lake Formation is the fine-grained lake governance answer; do not substitute only bucket policies when the stem demands column-level control. Operational check: register lake locations, define LF permissions for two department roles with different column sets, run Athena queries as each role to prove allow/deny, and audit permission changes through CloudTrail.