DEA-C01 Data Security and Governance Practice Question

A data engineer manages an AWS Glue Data Catalog used by Amazon Athena analysts. The security team wants column-level restrictions so that analysts querying a specific table cannot view the values in a cardholder_name column, while still being able to query all other columns. The analysts connect through Athena using an IAM role. Which approach meets this requirement with the LEAST operational overhead?

⚠ Common exam trap

The trap here is assuming IAM policies can restrict access at the column level, when Glue Catalog column restrictions are enforced by Lake Formation data filters attached to grants.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create an AWS Lake Formation data filter that excludes the cardholder_name column, then grant the analysts' IAM role SELECT on the table with that data filter applied.

Column-level access control in the Glue Data Catalog is provided by Lake Formation data filters, which can include or exclude specific columns and are attached to grants. Granting the analysts' role SELECT with a filter that excludes cardholder_name lets all other columns remain queryable through Athena while the restricted column is inaccessible. IAM policies, views, and CloudTrail do not enforce column-level prevention centrally.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Enable AWS CloudTrail data events on the table and alert when cardholder_name is queried.
Why it's wrong here
CloudTrail data events record activity for auditing and detection; they do not prevent analysts from viewing the column. The requirement is to stop the values from being visible, which is preventive control, not detective control. Relying on alerts means sensitive values are already exposed before anyone reacts.
✗
Create a separate Athena view that omits cardholder_name and grant the analysts access only to that view.
Why it's wrong here
A view can hide the column, but it requires the analysts to change their queries to use the view instead of the base table, and it does not prevent them from reading the underlying table if they retain access. It shifts enforcement to query authorship, adding ongoing operational overhead and a bypass path.
✗
Define an IAM policy that denies the glue:GetTable action for the cardholder_name column and attach it to the analysts' role.
Why it's wrong here
IAM policies cannot scope permissions to individual columns of a Glue table. The glue:GetTable action returns table metadata as a whole, so a deny on it would block access to the entire table rather than only the cardholder_name column. This approach cannot express the required column-level restriction and breaks legitimate queries.
✓
Create an AWS Lake Formation data filter that excludes the cardholder_name column, then grant the analysts' IAM role SELECT on the table with that data filter applied.
Why this is correct
Lake Formation data filters restrict column visibility at the catalog level, so Athena queries referencing the excluded column fail while all other columns remain readable. Granting SELECT with the filter attached enforces the restriction centrally without duplicating tables or rewriting queries, which is the least-overhead method for column-level governance.

Go deeper

DEA-C01 Data Security and Governance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question