DEA-C01 Practice Question 9: Lake Formation LF Tags Scale
AWS Certified Data Engineer – Associate (DEA-C01) · Test 1 · question 9 of 10
A data lake has grown to 40 AWS Glue databases and about 900 tables, organized informally into raw, curated, and restricted zones and into business domains such as sales and finance. Twenty-five teams request access, and roughly a dozen new tables are cataloged every week. Today the data lake administrator issues a Lake Formation named-resource grant for each team on each table, and the grant backlog keeps growing; teams routinely wait days for access to tables that were created in a database they are already entitled to.
Which approach reduces the ongoing administrative effort the most while keeping table- and column-level control?
Show answer and explanation
Answer:
Lake Formation tag-based access control (LF-TBAC) exists for exactly this scale problem, and the documentation names it "the recommended method to use to grant Lake Formation permissions when there is a large number of Data Catalog objects". The arithmetic is the point: with named resources the number of grants is n(P) × n(R), 25 teams times 900 tables, whereas with LF-TBAC the total of grants to principals plus tag assignments to resources is n(P) + n(R). Just as important for the stated symptom, "tables inherit LF-Tags from databases and columns inherit LF-Tags from tables", so a table created next week inside an already-tagged database is covered the moment it is cataloged, with no new grant at all. Because the grants still flow through Lake Formation, table- and column-level enforcement is preserved, and LF-Tags also carry across accounts for sharing.
Option A gives up the control the question requires. Handing teams direct s3:GetObject on the data bypasses Lake Formation entirely: column-level filtering, row filtering, and audited access all disappear, and a principal with prefix access can read every column in every file there.
Option B automates the symptom, not the cause. Each new table still needs a grant per entitled team, so the number of permission records still grows as n(P) × n(R), along with the associated service quotas, audit noise, and the risk that the automation silently mis-grants. It also does nothing for the 900 tables that already exist.
Option D misuses the feature. Data filters express row-level and column-level restrictions that refine a grant; they are not a grant mechanism, and each one must still be granted per table per principal. Attaching a filter to every table is more work than the named-resource process it replaces.
Reference: Lake Formation tag-based access control