SAP-C02 Practice Question 45: Cross Account Data Lake Access
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 5 · question 5 of 10
A central data platform account holds a 900 TB data lake in Amazon S3, catalogued in the AWS Glue Data Catalog. Nine business-unit accounts in the same organization need to query it with Amazon Athena. Today the platform team copies the subsets each unit needs into that unit's own S3 bucket every night.
The copies have become the problem: storage costs have tripled, business units query yesterday's data, and nobody can say who holds a copy of the customer table. The replacement must let each unit query the authoritative data in place, must restrict some units to a subset of columns because the customer table contains national identifiers, must let the platform team grant and revoke access centrally without editing S3 bucket policies or IAM policies in nine accounts, and must keep the data physically in the platform account.
What should the solutions architect recommend?
Show answer and explanation
Answer:
Lake Formation's cross-account capability is built to share a data lake held in one account with many others while keeping fine-grained control in the hands of the owning account. AWS describes it directly: users and AWS Glue ETL jobs can query and join tables across multiple accounts and still take advantage of Lake Formation table-level and column-level data protections. When a permission is granted to another account or to an organization, Lake Formation uses AWS Resource Access Manager to share the resource, and because the grantee accounts are in the same organization the share is available immediately with no invitation to accept. Grants and revokes happen once, centrally, in the platform account rather than as edits to nine sets of IAM and bucket policies, the data never leaves the platform account, and Athena queries it in place, so the nightly copies and their staleness disappear. The consuming accounts create resource links so Athena can include the shared tables in queries.
Option A controls access at the prefix level only. S3 Access Points know nothing about tables or columns, so the national identifier column cannot be withheld while the rest of the customer table is shared, and each unit still needs its own Data Catalog arrangement.
Option B grants access at whole-object granularity for the same reason: an S3 bucket policy cannot express a column restriction, and the permissions end up spread across a bucket policy plus roles in nine accounts; the central-control requirement fails.
Option D is a migration, not an access model. Loading 900 TB into Amazon Redshift adds cost and an ETL pipeline, changes the query surface the analysts use, and does not by itself provide the column-level governance that Lake Formation gives over the lake as it stands.
Reference: Cross-account data sharing in Lake Formation