Governance, Lake Formation and PII Protection

Domain 4 is worth 18% of scored content, and its last task, Understand data privacy and governance, is where the DEA-C01 exam stops asking "can you move the data?" and starts asking "who may see which row, in which Region, and how would you prove it a year later?" Two services carry almost all of that weight: AWS Lake Formation, which decides what a principal can see inside the lake, and Amazon Macie, which finds the sensitive data you are supposed to be protecting. Both are routinely miscast on practice tests, Lake Formation as an IAM replacement, Macie as a blocking tool, and both miscasts cost marks.

In this lesson you will:

• separate IAM from Lake Formation and defend the "two doors, both must open" rule that decides most lake-access questions;
• read the permission anatomy at catalog, database, table, S3-location, LF-Tag and resource-link level;
• build column-level, row-level and cell-level controls with Lake Formation data filters, including their PartiQL limits;
• apply LF-Tags (attribute-based access control): predefine, assign, inherit, cascade, and the AND/OR grant semantics;
• share data cross-account and cross-Region with AWS RAM, resource links and separate target grants;
• reason about governed tables, their December 31, 2024 end of support, and the blue/green catalog release pattern;
• place Glue, Athena, Spectrum, QuickSight, EMR and Redshift against Lake Formation enforcement, engine by engine;
• operate Amazon Macie: automated discovery, discovery jobs, managed vs custom identifiers, findings, severity and EventBridge automation, and never call it prevention;
• grant Redshift data sharing through datashares and reconstruct data lineage with SageMaker ML Lineage Tracking and Glue catalog versioning;
• execute privacy at exam depth: PII tagging, data residency, erasure, CloudTrail audit and shared responsibility;
• study four AWS customer case studies, a sourced October 2026 update box and 14 exam-style questions plus three interactive checks.

---

1. Domain 4's governance map: the eight skills this lesson answers

1.1 The task statements, verbatim

Two neighbouring skills are deliberately routed to other lessons: 4.5.4 (AWS Config for configuration changes) appears here only where it is contrasted with CloudTrail, and 4.5.6 (Amazon SageMaker Catalog projects) is named by the guide but is not a Lake Formation construct.

1.2 The personas; who may grant what

The IAM-administrator row is the single most examined persona fact in this section: identity expertise does not confer data-lake authority. An engineer who can edit any IAM policy in the account still cannot grant SELECT on a Lake Formation table until they are a data-lake administrator.

• 📚 Did you know? Lake Formation's own permission checks are free; you are billed for the integrated services you run (Athena, Spectrum, Glue) and for the Lake Formation Storage API, which bills bytes scanned rounded up to the next megabyte with a 10 MB minimum per request (Lake Formation pricing page, accessed Oct 2026). So the governance layer is cheap to over-grant financially and expensive to over-grant politically; which is exactly why the exam tests it on correctness, not cost.

1.3 The division of labour in one table

---

2. THE exam distinction: Lake Formation vs IAM for S3 lake access

2.1 Two doors, both must open

AWS states the rule in one sentence, and every lake-access question is a variation of it:

"When a principal makes a request to access Data Catalog resources or underlying data, for the request to succeed, it must pass permission checks by both IAM and Lake Formation.": Lake Formation permissions overview (accessed Oct 2026)

Three corollaries fall straight out of that picture, and each one is a question:

1. A Lake Formation grant without IAM fails. The principal still needs glue:* on the catalog APIs, lakeformation:GetDataAccess for vended credentials, and the engine's own permissions.
2. IAM alone cannot express fine grain. No identity policy can say "only rows where region = 'EU'" or "all columns except ssn"; those live exclusively in Lake Formation data filters.
3. Not registered means not governed. Athena result buckets, unregistered prefixes and anything outside the catalog are decided by IAM and S3 alone, and Lake Formation does not apply when writing objects (Athena security documentation, accessed Oct 2026).

2.2 IAM versus Lake Formation, side by side

2.3 The default that makes grants look broken

"Lake Formation sets Super permission on all databases and tables in the Data Catalog to a group called IAMAllowedPrincipals by default … all principals in your account will have access … through the IAM principal policies for AWS Glue.": Lake Formation permissions reference (accessed Oct 2026)

Until you revoke that group (or switch on hybrid access mode), the catalog behaves as though Lake Formation were not there: every IAM-principal in the account reads every table, and your carefully written grants appear to change nothing. Hybrid access mode splits the account in two: opted-in principals must pass both Lake Formation and IAM, while principals that have not opted in remain governed by IAM alone.

2.4 Worked example E1: "my grants do nothing" in four checks

An analyst reports that a revocation had no effect. Work the list in this order:

---

3. The permission model: database, table, column, row

3.1 Permission sets by resource layer

Two structural rules matter more than the list itself:

• ALL-tables implies database DESCRIBE: granting on "all tables" necessarily reveals that the database exists, and this implication does not hold under attribute-based (LF-Tag) grants.
• Revoking Super does not revoke everything. A principal can be left holding plain SELECT and INSERT after Super is removed: "revoke Super" is not synonymous with "revoke access".

3.2 Data filters: the column/row/cell combinatorics

One data filter per table combines a column specification (include list, exclude list, or the all-columns wildcard) with a optional row predicate in a PartiQL subset, or with AllRowsWildcard. AWS states the combination rule directly:

"'all columns' wildcard + row filter = row-level security only. Include/exclude specific columns + 'all rows' = column-level security only. Specific columns and a row filter = cell-level security.": Data filtering (accessed Oct 2026)

Constraints you must be able to quote:

3.3 Predicate algebra: when two rules meet

• A principal and their own IAM group: the row filters are unioned: the user sees the wider of the two.
• A grant to an external account intersected with a direct grant: intersection: the narrower result wins.
• Two concurrent all-rows wildcards: the all-rows prevails.
• Across engines: enforcement happens at query time, so a filter that Athena honours still has to be re-implemented anywhere the data is read without Lake Formation enforcement (Section 6).

3.4 Worked example E2: designing cell-level protection for ssn

Requirement: UK analysts see customer rows only for the United Kingdom, and nobody in the analyst role ever sees the ssn column.

Read the arithmetic of the rule: excluded column plus row predicate = cell-level; had we used the all-columns wildcard with the same predicate we would have shipped row-level protection only and leaked ssn to every UK row.

3.5 Worked example E3: the four-grant ladder on one table

Reading: protection is a property of the filter attached to the grant, not of the table. Two analysts querying the same customers table can legitimately see different column sets and different row sets; which is precisely what "cell-level security" means on this exam.

---

4. LF-Tags: attribute-based access control and the cascade

4.1 The six rules of tag-based grants (LF-TBAC)

1. Predefine first. A key/value pair cannot be invented at assignment time; it must already exist as an LF-Tag.
2. One value per key per resource. A table cannot be both classification=public and classification=restricted on the same key.
3. Values are stored lower-case.
4. Inheritance is directional: "Tables inherit LF-Tags from databases and columns inherit LF-Tags from tables. Inherited values can be overridden."
5. Grant on the tag, not the object: GRANT SELECT ON TAGS module=Sales TO analyst_role: every table carrying that tag is covered, including tables the crawler creates tomorrow.
6. LF-Tags are not IAM tags. AWS's wording is absolute: "IAM tags are not the same as LF-Tags. These tags are not interchangeable." They compose: both checks must allow the request.

4.2 The cascade, drawn

4.3 Grant semantics: AND across keys, OR within a key

4.4 Worked example E4: named grants versus tag grants

Setup: 3 analyst principals, each needing the same access to 3 databases and 7 tables, plus a plan to add 50 more tables next quarter. (Derived arithmetic; this is not an AWS-published figure; the structure follows the Lake Formation TBAC documentation, accessed Oct 2026.)

Reading: the tag route collapses 180 operations into 7 because the grant attaches to an attribute that new objects inherit automatically. That is why skill 4.2.5 names tag-based and attribute-based authorization as a business-need answer: at scale, the difference is not convenience, it is whether permissions stay correct as the catalog grows.

• 📚 Did you know? AWS publishes a customer result for exactly this arithmetic: Integral Ad Science "reduced hundreds of permission rules down to precisely two rules" using Lake Formation tag-based access control (AWS Big Data Blog, 2021-09-23, accessed Oct 2026). Two rules is not a typo; it is what happens when the number of objects stops being the number of grants.

4.5 Worked example E5: a tag-based multi-tenant grant

---

5. Data sharing: cross-account, cross-Region, governed tables, blue/green

5.1 The producer/consumer sequence

Facts encoded in that diagram:

• Sharing stacks are either Lake Formation (RAM + resource links) or the legacy IAM-only catalog sharing; hybrid access mode lets both coexist while an account migrates.
• Cross-Region sharing works through resource links created in the consumer Region: Lake Formation permissions themselves never travel.
• A direct grant to a principal (rather than a share) is unioned with any account-cascaded grant, and only the recipient sees it; they cannot re-share it.
• Cross-account crawling has its own four-step order: register the location in the producer account → grant DATA_LOCATION_ACCESS to the consumer's crawler role (plus GetDataAccess) → accept the RAM share → create the link and tick "Use Lake Formation credentials".

5.2 Governed tables, and the date you must quote

AWS built governed tables as an Amazon S3 table type with ACID guarantees across tables and automatic compaction, so that analytics could share consistent snapshots. AWS then announced:

"end support for Governed Tables, effective December 31, 2024, to focus on open source transactional table formats such as Apache Iceberg, Apache Hudi, and Linux Foundation Delta Lake.": AWS Big Data Blog, 2024-10-02

Exam handling: state the deprecation with its date, and answer open-table-format questions with Iceberg, Hudi or Delta Lake. Lake Formation grants, including row and cell filters, apply to cataloged Iceberg/Hudi/Delta tables, and Lake Formation manages compaction, snapshot retention and orphan-file deletion for Iceberg, while the engine keeps ownership of write DDL (VACUUM, MERGE, OPTIMIZE).

5.3 Blue/green catalog releases: a pattern, not a service

"Blue/green catalog deployment" is not an AWS feature name: nothing in the Lake Formation or Glue documentation describes a service by that name (checked Oct 2026). What the exam is really testing is whether you can assemble the pattern from verified building blocks:

5.4 Worked example E6: share versus copy for a 20 TB dataset

Reading: the exam's phrase "share access to live data … without manually moving or copying the data" is the tell. When an option's first step is COPY, UNLOAD, rsync or "replicate the bucket", it is describing a copy, not a share.

---

6. Engine integration: Glue, Athena, Spectrum, QuickSight, EMR, Redshift

6.1 The enforcement matrix

6.2 Worked example E7: what a Lake Formation-governed query actually reads

A 1 TB Parquet table is partitioned into 12 monthly partitions; the analyst's predicate prunes to a single month:

Reading: Lake Formation decides whether the query may run and which rows/columns come back; partitioning and file format decide how many bytes the engine reads; the Storage API's rounding rule decides the Lake Formation line item. Three different bills, one query: a classic multi-option distractor.

6.3 Worked example E8: the same table through two engines

---

7. Amazon Macie: discovery, not prevention

7.1 What it is, and the boundary it will not cross

Amazon Macie is "a data security service that discovers sensitive data by using machine learning and pattern matching.": What is Amazon Macie (accessed Oct 2026)

7.2 The two detection engines and the allow list

7.3 Jobs, schedules and findings

7.4 The finding flow, and where your code takes over

7.5 Worked example E9: a Macie job specification

7.6 Worked example E10: Macie monthly cost (us-east-1 example rates)

Unit prices are AWS's published us-east-1 examples (Macie pricing page, accessed Oct 2026: verify current pricing before use): $0.10 per bucket per month, $0.01 per 100,000 objects per month, plus tiered charges for inspected data volume.

Reading: object count is a rounding error, bucket count is small, and inspected data volume dominates. That is why the exam loves the "scan everything, every hour" option: it is technically correct and economically indefensible.

7.7 Worked example E11: routing findings with EventBridge

• 📚 Did you know? Macie's custom data identifiers are immutable after creation: AWS frames that as "immutable history … for data privacy and protection audits" (Macie custom data identifier options, accessed Oct 2026). You cannot quietly edit a regex that produced last quarter's findings; you create a new identifier and retire the old one, which is exactly the audit property a compliance question is probing.

---

8. Data sharing in Amazon Redshift

8.1 The datashare model

Redshift lets you "share access to live data across Amazon Redshift clusters, workgroups, AWS accounts, and AWS Regions without manually moving or copying the data", and "datashare objects are read-only for data consumers" in the basic model.: Redshift data sharing overview (accessed Oct 2026)

8.2 Worked example E12: the sharing lifecycle, end to end

Reading: three authorizations are involved and candidates routinely collapse them into one: the share authorization, the CREATE DATABASE, and the object-level GRANT. Skip any one and the analyst gets an empty schema, an empty database, or a permission error respectively.

---

9. Lineage: SageMaker ML Lineage Tracking and catalog versioning

9.1 What the exam guide means by lineage

The guide's lineage answer set is narrow and worth memorising: SageMaker ML Lineage Tracking, Glue Data Catalog versioning, and CloudTrail. Third-party lineage frameworks and Amazon DataZone are not on the DEA-C01 in-scope list (as of Oct 2026), so an option built around them cannot be the best answer.

SageMaker ML Lineage Tracking records an ML workflow "from data preparation to model deployment" so that you can reproduce runs and support model governance and audit. The hierarchy runs Experiment → Trial → Trial Component, and jobs create trial entities automatically.

9.2 The four entities and their associations

Association types: ContributedTo, Produced, SameAs, AssociatedWith, DerivedFrom: where SameAs is the cross-account link. Automatic entities are not quota-limited; manual ones are, and an Association cannot link two experiment entities.

9.3 Worked example E13: the manual lineage budget and the audit query

9.4 Glue catalog versioning as a metadata lineage signal

Row-level lineage is out of reach of the catalog, but schema-level lineage is not:

• 📚 Did you know? The distinction the exam exploits: CloudTrail answers "who granted SELECT at 14:02", AWS Config answers "did the bucket policy or encryption setting change". Both are governance evidence, but they are different questions: one is an API action, the other is configuration state over time. A stem that quotes a timestamp of a permission change is pointing at CloudTrail; a stem that quotes a compliance rule evaluating resource configuration is pointing at Config.

---

10. Privacy at exam depth: PII, residency, erasure, audit, compliance

10.1 The PII pipeline: discovery, classification, enforcement

The three-service split is the whole skill: Macie discovers, Lake Formation enforces, KMS encrypts. Any option that moves a verb between them is testing whether you noticed.

• 📚 Did you know? Masking is not exclusively a Lake Formation skill. EOS Group masked PII with Amazon Redshift dynamic data masking after moving its warehouse through AWS DMS → Amazon S3 → Amazon Redshift, and AWS reports a 50 percent reduction in infrastructure costs with zero data loss (AWS case study, accessed Oct 2026). The verb stays the same, mask the sensitive value for this role, but the service follows the engine: Lake Formation data filters for the lake, Redshift dynamic data masking for the warehouse, and neither is a job Amazon Macie will ever do.

10.2 Data residency and sovereignty (skills 4.5.3 and 4.5.5)

10.3 Erasure patterns (right to be forgotten)

• 📚 Did you know? Immutability and erasure pull in opposite directions. Nasdaq's S3-backed data lake pairs Amazon Redshift and Spectrum with Amazon S3 Object Lock and Glacier archive so that regulated market records cannot be rewritten or deleted while retention runs (AWS Nasdaq case study, accessed Oct 2026). An erasure request against a locked object is refused until the retention period expires or the legal hold is released; which is exactly why Object Lock appears as the BLOCKER row in the erasure pattern above, and why a compliance answer that promises both "instant right to be forgotten" and "WORM retention on the same objects" is self-contradictory.

10.4 Audit and compliance under shared responsibility

That last row is the shared responsibility model applied to privacy: AWS supplies certifications and controls; the customer supplies classification, access decisions, retention rules and residency choices. An option claiming an AWS certification makes a customer compliant has inverted the model.

10.5 Worked example E14: a residency guardrail for an analytics OU

2026 Updates (as of October 2026)

---

Real-World Case Studies

Every figure below is customer- or AWS-claimed and unaudited, copied from an AWS-owned property and dated so you can check it. The examinable point is the pattern, which control was applied, which service did the work, never the marketing number.

Case A, Integral Ad Science (IAS): hundreds of rules collapsed to two

Read IAS as Section 4's arithmetic made real: the "two rules" are tag-based grants, and the inheritance database → table → column is what stopped the rule count from tracking the object count.

Case B, Oportun: PII discovery that leadership could act on

The examinable point is the shape of the answer: discovery accuracy improved because identifiers were tuned (custom identifiers + allow lists), and the output still had to be routed through EventBridge into a customer-built remediation: Macie reported, it never prevented.

Case C, GoDaddy: a central governance account feeding a data mesh

Read GoDaddy as Section 5's producer/consumer sequence running at mesh scale: producer grant → RAM share → accept → resource link → separate grant on the linked target, repeated thousands of times and automated with Service Catalog and Lambda so that link creation never becomes a hand-typed step. The governance lesson is that ownership decentralised while permission semantics stayed central: the mesh publishes, Lake Formation decides.

Case D, EOS Group: PII masking after a DMS → S3 → Redshift migration

Read EOS as the masking verb living in a different service: Lake Formation data filters mask in the lake, Redshift dynamic data masking masks in the warehouse, and Macie does neither; it only finds the PII that both masking controls exist to protect. On exam day the engine named in the stem picks the masking mechanism.

• 📚 Did you know? AWS's neighbouring governance case study, GoDaddy, reports a Lake Formation data mesh with over 2,000 data products across "multiple petabytes of data across hundreds of accounts" (AWS Big Data Blog, 2022-11-21, accessed Oct 2026). The number matters less than the topology: a central governance account publishing shares through AWS RAM, with consumers holding resource links: the exact Section 5 sequence at mesh scale.

---

Practice Questions

Comparative Verdict: how this topic compares on exam day

• Versus other clouds: DEA-C01 tests AWS services only. Amazon Macie against a competitor's DLP product, or Lake Formation against an external catalog, never appears as a fair comparison: third-party DLP/catalog tools, Azure Purview, Google Data Catalog and OpenLineage are out of scope by construction. Answer with an in-scope AWS service (Lake Formation, Macie, CloudTrail, Config, Control Tower, KMS, IAM/RAM) or an AWS-documented behaviour.
• Versus self-managed / on-premises: the exam's preference is managed, declarative and auditable over bespoke and manual: LF-Tag grants beat hand-maintained per-table ACLs (IAS's "hundreds of rules → two"), Macie jobs beat a custom scanning script, CloudTrail beats a home-grown audit log. An option describing hand-rolled permission code is the distractor, not the bonus; the DIY answer must also re-implement what Lake Formation gives free (Region scoping, inheritance, temporary credential vending).
• Versus another AWS service: choose by verb, not proximity: discover (Macie) · allow/deny visibility (Lake Formation, with IAM as Door 1) · encrypt (KMS) · prove an API call happened (CloudTrail) · prove configuration state (AWS Config) · prevent a Region (Control Tower SCP) · share warehouse data live (Redshift datashare) · trace model provenance (SageMaker ML Lineage Tracking). Wrong answers almost always swap two adjacent verbs.
• Versus a manual, human process: IAS's two-rule governance and Oportun's +95% / −80% discovery results (both AWS-published customer claims, accessed Oct 2026) show the shape of the target architecture, tag-based grants plus identifier-tuned discovery, but every published percentage is "the customer achieved", never "AWS guarantees". On exam day, prefer the option that is automated, inherited and evidence-producing over the one that depends on a human remembering to re-grant.