What's changed: In-scope coverage: added network boundary/defense (VPC/PrivateLink/WAF/Shield)
4.2Governance and Compliance (Lake Formation)
Understand data governance: fine-grained (column/row-level) access management with AWS Lake Formation, auditing with CloudTrail, and classification/data lineage with tags.
A data lake needs fine-grained control over who can access which columns/rows. AWS Lake Formation centralizes this.
4.2.1Lake Formation and auditing
- Lake Formation: centrally grant column/row/cell-level permissions on Glue Data Catalog tables.
- CloudTrail: records who accessed/changed which data and when, for auditing.
- Tags/lineage: classify data (e.g., sensitivity) and track origin/flow (data lineage).
Common on DEA: column/row-level fine-grained access = Lake Formation, audit who accessed data = CloudTrail, classification = tags. Lake Formation centralizes permissions over the Glue catalog.
Data-lake governance combines "fine-grained access + audit + classification/lineage." AWS Lake Formation centrally grants column/row/cell-level permissions on Glue Data Catalog tables, applying consistently to access from Athena, Redshift Spectrum, and EMR. LF-Tags (tag-based access control) bundle permissions by attributes like column sensitivity for governance at scale (manage across tables by tag rather than per table). Audit with CloudTrail (who accessed/changed which data and when), and support compliance with data lineage (origin and flow) and tag-based classification (sensitivity, owning team). Org-wide data discovery/sharing uses Amazon DataZone, and fine row/column protection can also come from Redshift dynamic data masking/RLS. The axes: "column/row-level fine access = Lake Formation," "audit = CloudTrail," "classification = tags/LF-Tags." Lake Formation exists because IAM alone struggles with column/row-level control.
| Governance need | Use |
|---|---|
| Column/row/cell-level access | Lake Formation |
| Permissions at scale by attribute | LF-Tags (tag-based) |
| Audit who accessed | CloudTrail |
| Classification/lineage | Tags / data lineage |
Scenario: hide PII columns from analysts while letting them use the rest. Grant via Lake Formation column-level permissions excluding PII columns (applied consistently through Athena/Spectrum). Bundle sensitivity with LF-Tags for at-scale management. Audit who queried which tables with CloudTrail, and prepare compliance reports with classification tags and lineage.
Q. Column/row-level access? Lake Formation. Q. Permissions at scale by attribute? LF-Tags. Q. Audit who accessed? CloudTrail. Q. Why not IAM alone? IAM struggles with column/row granularity. Q. Classification? Tags / data lineage.
Watch the mix-ups: (1) Lake Formation = fine-grained access / CloudTrail = audit—don’t swap. (2) Lake Formation governs catalog-mediated access (Athena/Spectrum/EMR), but direct S3 access still needs IAM/bucket policies. (3) Tags classify but don’t themselves deny access (combine with LF-Tags or IAM conditions).
Requirements like hiding specific columns (e.g., PII) from certain roles are met with Lake Formation column-level permissions.
4.2.2Section summary
- Lake Formation = column/row-level fine-grained access
- Audit = CloudTrail, classify = tags, flow = data lineage
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want column/row-level fine-grained access (e.g., show certain columns only to certain roles) in a data lake. What do you use?
Q2. You want to audit who accessed/changed which data and when. Which fits best?
Q3. You want to classify data (e.g., by sensitivity) to aid downstream governance/cost attribution. What fits best?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.