DEA-C01 Practice Question 39: Lake Formation Row Column Filter

"Lake Formation uses data filtering to achieve column-level security, row-level security, and cell-level security." A data filter carries a column specification ("a list of columns and nested columns to include or exclude in query results"), and a row filter expression with WHERE-clause syntax. The documentation spells out the combinations: an all-columns wildcard plus a row expression gives row-level security; included or excluded columns plus the all-rows wildcard gives column-level security; and both together gives cell-level security. So the EU filter excludes customer_email with the expression region='EU', the US filter excludes customer_email with the all-rows wildcard, and compliance is granted SELECT with no filter. You select the filter when you grant SELECT, every group keeps querying orders, and there is exactly one copy of the data.

Option A creates the copies the requirement forbids, along with three jobs to schedule, three freshness windows to worry about, and three tables to keep in sync as the schema changes.

Option C changes the object each group queries, which breaks the "query orders by name" requirement, and creates three view definitions to maintain as entitlements change.

Option D is the strongest distractor because LF-Tags are genuinely the scalable way to grant Lake Formation permissions, and tags can be attached at column granularity. But tag-based access control grants permissions on catalog *resources*; it has no row filter expression, so there is no way to express "only rows where region = 'EU'". Row-level security requires a data filter.

Reference: Data filtering and cell-level security in Lake Formation