Secure Cross-Account S3 Access for GenAI with Lake Formation

AIP-C01 By islever Editorial Last updated

Implement data security and privacy controls. Design and implement enterprise integration architectures.

Short answer

C Lake Formation in each source account grants the Account C SageMaker FM role column-level, tag-based access to only permitted S3 fields.

Question

A financial services company is developing a GenAI application that needs to analyze data across multiple AWS accounts by using a foundation model (FM). The data and application are in Amazon S3 buckets in three separate accounts. Account A contains transaction data. Account B contains customer profiles, including personally identifiable information (PII). Account C hosts the GenAI application. The company plans to add data sources from seven more business units within the next few months.
The company must have strict control over PII data. The company must ensure that the FM accesses only necessary data fields.
The company needs a solution to establish secure cross-account access for the GenAI application.
Which solution will meet these requirements?
  1. Use AWS Identity Center to create a permission set for the FM service account. Configure resource-based policies on each S3 bucket to allow specific access to Account C. Deploy a custom AWS Lambda authorizer to filter PII data before passing it to the FM.
  2. Configure Amazon Bedrock cross-account IAM roles. Create role-based access policies in each source account that allow access only for specific S3 bucket paths. Apply tagbased access controls on S3 objects to classify and control access to PII data.
  3. Set up AWS Lake Formation in each source account. Register the S3 buckets with Lake Formation. Create IAM roles in each source account that have permissions to access specific S3 bucket paths. Configure Lake Formation permissions to allow access only to specific data columns by using Lake Formation tag-based access controls. Use Amazon SageMaker AI to deploy the FM with an execution role in Account C that can assume the cross-account IAM roles to access the data through Lake Formation. Correct Answer
  4. Configure resource-based policies on S3 buckets in each source account to allow access from the GenAI application in Account C. Configure identity-based policies for the FM's service role that allow access only to specific data columns by using AWS Lake Formation tag-based access controls. Set up a VPC endpoint in each account to provide secure cross-account access.

Key Takeaways

The question tests column-level, cross-account data governance for PII, and the trap is choosing IAM/S3 policy approaches that can only scope paths or buckets—not individual data columns.

This AIP-C01 scenario asks how a GenAI application in Account C can read transaction and PII data from S3 buckets in two other accounts while restricting the foundation model to only necessary fields. The correct design registers each source bucket with AWS Lake Formation, uses cross-account IAM roles, and applies Lake Formation column-level/tag-based permissions deployed through Amazon SageMaker AI.

Common mistake: Option B is the most tempting wrong pick because cross-account Bedrock roles plus S3 path and tag restrictions sound secure, but S3 object tags and bucket paths cannot enforce field-level (column) access, which the requirements explicitly demand for PII.

Expert Analysis

Why the Answer Is Correct

Option C is the only design that delivers true column-level enforcement: Lake Formation is registered against the S3 buckets in Accounts A and B, and its permissions (driven by tag-based access controls) restrict the consumer to specific columns such as non-PII transaction fields. Cross-account IAM roles in each source account scope access to specific bucket paths, while the SageMaker AI execution role in Account C assumes those roles, giving a single, auditable identity chain to the FM. This architecture also scales, because adding the seven future business units simply means registering new buckets and granting the same governed permissions rather than rewriting application policy. The column-level granularity directly satisfies the stated requirement that the FM accesses only necessary data fields and that strict PII control be maintained.

Why the Other Options Are Wrong

Option A relies on resource-based S3 policies plus a custom Lambda authorizer, which places the PII filtering logic in application code rather than in a governance layer, making it fragile, hard to audit, and impossible to express as reusable column grants as accounts multiply. Option B uses legitimate cross-account Bedrock roles, but S3 bucket paths and S3 object tags classify whole objects, not fields inside them, so PII columns in a mixed object would still reach the FM. Option D mixes bucket resource policies with identity-based policies and asserts that Lake Formation tag-based column controls can be attached to an IAM service role policy on S3; S3 does not interpret Lake Formation column grants, so without registering the data in Lake Formation no column-level restriction is actually enforced, and VPC endpoints only address network isolation, not data-field access.

Community Comment Notes

The lone community comment, from TNT87, concurs with this verdict, stating "Set up AWS Lake Formation in each source account" and quoting the full option C wording as the correct solution. With no vote distribution recorded, there is no competing learner majority to weigh, so the decision rests entirely on the requirement that the FM be limited to specific data columns.

Exam Strategy

Read which requirement the option actually satisfies: whenever the prompt says the model must see only certain fields or PII must be controlled, look for column-level controls—Lake Formation is the only AWS service in these choices that grants per-column permissions across accounts.

Frequently Asked Questions

Why can't S3 bucket policies or object tags enforce column-level PII filtering?

S3 policies and object tags apply to whole objects and paths, not to fields within a row or file. Only Lake Formation permission grants can restrict access to individual data columns.

Why use Amazon SageMaker AI instead of Amazon Bedrock for the cross-account role assumption?

Option C deploys the FM on SageMaker AI so the execution role in Account C can assume the source-account roles and read through Lake Formation. Bedrock's cross-account roles alone would not deliver column-level grants.

More AIP-C01 FAQ →

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

  1. TNT87 👍 1 Answered C
    Set up AWS Lake Formation in each source account. Register the S3 buckets with Lake Formation. Create IAM roles in each source account that have permissions to access specific S3 bucket paths. Configure Lake Formation permissions to allow access only to specific data columns by using Lake Formation tag-based access controls. Use Amazon SageMaker AI to deploy the FM with an execution role in Account C that can assume the cross-account IAM roles to access the data through Lake Formatio

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How Can AgentCore Query Cross-Account DynamoDB While Preserving User Identity?

S-grade

Which API Gateway setup streams Bedrock responses with least operational overhead?

S-grade

Resilient Retry and Streaming Strategies for Amazon Bedrock

S-grade

Bedrock Prompt Management & Guardrails Detection

S-grade

Practice All AIP-C01 Questions

Access 110 questions with complete answers and detailed explanations.

View Full AIP-C01 Practice Test →

← Back to AIP-C01 Study Guide