AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Constrain lake queries before assembling context
Completed by the knowledge check
Learning objective
Apply fine-grained data entitlements with AWS Lake Formation and monitor relevant access events.
Core idea
AWS Lake Formation can restrict the rows and columns returned through integrated query engines. Place that boundary before query results become model context. A model instruction to ignore sensitive columns cannot substitute for a query path that never returns those columns.
Fine-grained entitlements also need evidence. Record who changed permissions, which principal requested data access, and which storage reads followed. A permission grant, temporary credential issuance, and an S3 object read are different events. Correlate them instead of treating any one event as proof that a particular person saw a particular answer.
How it works
Establish the governed query path
Lake Formation works with Data Catalog tables and underlying registered S3 locations. Register the relevant bucket or prefix and specify a registration IAM role. When an integrated AWS service requests access, Lake Formation assumes that role and supplies temporary credentials for the data location. In addition to Lake Formation grants, the accessing principal needs the IAM permission lakeformation:GetDataAccess; Athena requires it on the user, while other integrated services require it on their execution role.
This is a service integration boundary, not a universal interceptor for every object read. If your agent’s custom retrieval code can read the S3 objects directly through independent IAM grants, do not assume the Data Catalog filter constrains that request. Review direct storage permissions alongside the Lake Formation query path. Registration does not turn arbitrary SDK reads into filtered table queries.
Distinguish data permissions from data location permissions. SELECT grants query access to a table’s underlying S3 data and can restrict visible columns. DATA_LOCATION_ACCESS controls the ability to create Data Catalog resources pointing to a registered location; it is not the permission needed to query the underlying data. DESCRIBE exposes metadata without granting query access by itself.
Review Super grants as part of entitlement design. When Super is granted to IAMAllowedPrincipals on a Data Catalog resource, access is effectively controlled solely by IAM policies. A restrictive data filter is not evidence of a restrictive effective permission set if broader grants preserve an alternate access path. Make the chosen permissions model explicit before evaluating the fine-grained rule.
Express the entitlement as a data filter
Lake Formation data filters implement column-level, row-level, and cell-level security. Filters apply only to read operations, so the filtered Lake Formation permission is SELECT. They are not row-specific write authorization rules.
A column filter includes approved columns or excludes restricted ones. A row filter includes records matching a predicate. Combining the two defines cell-level access: the principal receives selected columns for selected rows. For a support assistant, that might mean claim status and approved summaries only for one regional team, without claimant contact details.
CreateDataCellsFilter defines the filter for a table. The object identifies Name, TableCatalogId, DatabaseName, and TableName. RowFilter.FilterExpression contains a supported PartiQL-style predicate. ColumnNames defines included columns; ColumnWildcard.ExcludedColumnNames defines exclusions. RowFilter.AllRowsWildcard means all rows, so it is appropriate for a column-only restriction rather than a regional row boundary.
Creation and application are different decisions. Select the data filter when granting SELECT to the intended principal through Lake Formation permissions. Keep the target table, principal, and filter under review together. A correctly written predicate attached to the wrong principal or left unapplied does not enforce the intended entitlement.
Inspect the effective set of grants, not only one filter. AWS documents that row permissions granted to a principal and its group combine as a union. An all-rows expression applied concurrently with narrower predicates prevails over those predicates. A narrow regional filter cannot undo a separate grant that already admits all rows.
Check the engine and schema constraints
Confirm that the chosen query engine supports the filtering level and schema you need. AWS documents cell-level security in all Regions for Athena engine version 3 and Amazon Redshift Spectrum; other services have documented Region constraints. Do not generalize a capability from one integrated engine to every compute path that can read a Data Catalog table.
Column filtering cannot restrict partition keys. Row expressions do not support array and map data types, while struct is supported. There is a limit of 100 data filters for a single principal on a table, even though the number defined for a table has no such limit. These constraints can change the schema or entitlement design; adding another filter is not always the answer.
Validate the engine-specific behavior with representative allowed and denied queries. Include a principal carrying overlapping grants and records outside the intended predicate. Inspect the actual returned columns and rows before introducing generation, so a model’s answer wording does not mask a failed data boundary.
Monitor grant changes and data access
Lake Formation integrates with CloudTrail. PutDataLakeSettings, GrantPermissions, and RevokePermissions produce events that help explain configuration and entitlement changes. Inspect eventName, userIdentity, requestParameters, and failure information. The documented GrantPermissions example includes a failed request, so the presence of a grant event alone does not establish that the permission change succeeded.
GetDataAccess is logged when a principal or integrated service requests temporary credentials for a registered location. Principals do not directly call this API. Use the event to identify the access principal and requesting service; do not describe it as a list of every row returned or proof of a completed model response.
For underlying S3 reads, enable the relevant CloudTrail S3 data events. To add source identity tracking, set Parameters.SET_SOURCE_IDENTITY to "TRUE" through the data lake settings and permit sts:SetSourceIdentity in the registration role’s trust policy. Preserve the other reviewed settings when updating that configuration.
AWS documents correlation between lakeformation:GetDataAccess and s3:GetObject using the initiating role identifier. The S3 event’s sessionContext.sourceIdentity carries source identity when configured. This traces a workload role through the credential-vending path. If many people share that role, retain a separate application correlation record for the authenticated person, query, and context assembly; the role identifier alone does not establish end-user identity. A governed query requests temporary credentials before it reads S3, and each step leaves its own event.
There is a documented monitoring exception: Amazon Redshift federated catalogs in the Glue Data Catalog do not generate Lake Formation GetDataAccess events. Monitor GetTable and BatchGetTable for their metadata-access patterns. Choose the event set from the integration rather than assuming one event name covers every governed source.
Key distinctions and trade-offs
Data location versus data read permission: DATA_LOCATION_ACCESS controls catalog resource creation at a location. SELECT controls table reads.
Filter definition versus effective entitlement: A filter specifies an allowed subset; overlapping grants can broaden the result. Review all grants that apply to the principal.
Credential event versus object read: GetDataAccess records temporary credential requests. S3 data events record object operations. Neither records every business interpretation in the generated answer.
Architecture / decision scenario
A regional claims assistant uses Athena engine version 3 to query an S3-backed Data Catalog table. The application must retrieve only regional claims and omit contact fields.
The team registers the location, reviews the registration role, and removes unintended broad access paths. It creates a table data filter with the regional RowFilter.FilterExpression and an approved ColumnNames list, then grants filtered SELECT to the query principal. It checks for IAMAllowedPrincipals and overlapping all-row grants before testing out-of-region queries.
For monitoring, the team reviews successful GrantPermissions changes, enables S3 data events, and configures source identity tracking. It correlates GetDataAccess with s3:GetObject and an application query record. Only the filtered result reaches the model; a persuasive prompt cannot expand that result set.
Common exam traps
- Assuming a Data Catalog filter constrains every direct S3 read.
- Using
DATA_LOCATION_ACCESSas the query permission. - Treating filtered
SELECTas a write-control mechanism. - Ignoring overlapping grants or
IAMAllowedPrincipals. - Treating credential issuance as proof of a completed data read.
- Assuming role-level source identity identifies a person behind a shared role.
What to remember
- Govern the query path before data becomes model context.
- Bind filters, principals, and effective grants together.
- Verify engine and schema support.
- Monitor permission changes, credential issuance, and storage reads separately.
- Preserve application identity correlation alongside AWS events.
Knowledge check
A claims assistant queries a Data Catalog table through Athena engine version 3. Its query role must see only claims from its region and never the claimant contact columns. Which Lake Formation grant fits?
DATA_LOCATION_ACCESS on the registered S3 prefix that holds the tableSELECT with a data filter that combines a regional row expression and approved columnsSELECT with a data filter that uses AllRowsWildcard and excludes the contact columnsDESCRIBE on the table, with the regional predicate added by the application promptSELECT . AllRowsWildcard makes the filter column-only, so other regions’ rows still arrive. DATA_LOCATION_ACCESS governs creating catalog resources at a location, and DESCRIBE exposes metadata without query access.A user’s query role holds SELECT through a regional row filter, yet test queries return claims from every region. What should the review look for first?
RowFilter.FilterExpressionThe assistant’s tables are protected with Lake Formation data filters, but its custom retrieval code also holds IAM permissions to call s3:GetObject on the registered prefix. What does that mean for the entitlement?
lakeformation:GetDataAccessMany support agents share one Lake Formation query role. An auditor must link an S3 object read to the person whose question caused it. Which evidence makes that link?
GetDataAccess event’s userIdentity for the query roleGrantPermissions events that created the data filter grantGetDataAccess records a credential request, S3 data events record object operations, and source identity traces the workload role through credential vending. With a shared role, none of them names the person; the application must keep its own record of the authenticated user, query, and context and correlate it with those events.