Articles

AWS Lake Formation Interview Questions: IAM, Lake Permissions, and Hybrid Access Failures

Prepare for AWS Lake Formation interview questions with IAM vs lake permissions, hybrid opt-ins, Athena failures, and a two-role troubleshooting case.

Two roles query the same Athena table. The legacy reporting job succeeds; the newly onboarded analyst gets an access error. Both roles appear to have IAM permissions, and a Lake Formation grant is already present. What would you check before changing another policy?

A strong AWS Lake Formation interview answer identifies the actual caller, operation, resource, and authorization route. A grant screenshot cannot establish that the failing request used that grant. The same table can follow different permission paths for different principals, and successfully finding its schema does not prove that a query can read its rows.

This guide uses current AWS documentation for official behavior and clearly labeled original interview exercises for debugging decisions. It does not use candidate reports to claim that an employer asks these exact questions. The examples cover same-account, S3-backed Glue tables queried through Athena; cross-account sharing, transaction writes, and other query engines need their own checks.

For a related exercise, start with the AWS access-control portion of Explain AWS access control and frontend typing. The frontend typing portion is outside this article's scope.

Why can two roles follow different paths to one table?

Official fact: AWS describes hybrid access mode as two permission pathways for the same Data Catalog objects. Opted-in principals require Lake Formation and IAM authorization; other principals retain the IAM route for S3 and Glue. Opt-in applies to principals and catalog resources associated with the hybrid location. See the hybrid access mode documentation.

Original exercise: retail.orders points to s3://interview-lake/orders/, registered in hybrid mode. The table retains the compatibility permission for IAMAllowedPrincipals. LegacyReport has the necessary Glue and source-S3 IAM access and is not opted in. Analyst is opted in for this table. Assume both can submit the same Athena query and access its result location, and no explicit deny or encryption failure applies.

The important comparison is a role-table pair, not whether someone enabled a global “Lake Formation on” switch. The names below represent IAM roles, not human users sharing an administrator's browser session.

Role and change	Route for this table	Expected exercise outcome
LegacyReport, no opt-in	Existing IAM route	Reads with the assumed Glue and source-S3 permissions
Analyst, opted in, no SELECT	Lake Formation plus IAM	Cannot read through the governed query path
Analyst, SELECT added, GetDataAccess missing	Lake Formation plus IAM	Still fails at the required IAM API permission
Analyst, SELECT and required IAM restored	Lake Formation plus IAM	Reads if the remaining storage and result conditions hold

The first two rows are deliberately asymmetric. A successful legacy job does not demonstrate that the analyst's Lake Formation grants are correct. Conversely, adding SELECT to the analyst does not explain why the legacy job succeeds without that grant.

A useful answer begins: “I will compare the role-table opt-ins and the query identities before comparing permission lists.” It leaves room for the observed configuration to contradict the exercise assumptions. If the table no longer has the compatibility permission, the first row needs reevaluation.

Does a Lake Formation grant replace IAM permissions?

Official fact: Athena users querying Lake Formation-governed data need IAM permission for lakeformation:GetDataAccess. Athena API authorization and access to the query result location remain separate requirements. Lake Formation does not govern Athena result-bucket permissions. AWS documents these boundaries in Manage Lake Formation and Athena user permissions.

Original exercise follow-up: After SELECT is granted, the analyst still fails. The proposed fix is “grant SELECT again with grant option.” That changes delegation authority without addressing the missing API permission in the third matrix row. The narrower hypothesis is that the caller cannot request data access through the required IAM action.

Do not collapse every remaining condition into “add S3 permissions to the analyst.” First identify which identity accesses the source through the selected route. A governed Athena read and a direct S3 request are different operations. An error on the output bucket also refers to a different resource from the source table.

Suppose the analyst can now read the governed source but cannot write results to s3://interview-results/team-a/. Regranting table SELECT will not repair that output authorization. In an interview, explicitly name the failing stage, output prefix, and caller. A successful query with another workgroup may narrow the problem, but changes multiple conditions unless you hold the result configuration constant.

Is seeing a table enough to read its data?

Official fact: Lake Formation DESCRIBE provides metadata visibility without granting data access. SELECT concerns querying table data; DATA_LOCATION_ACCESS concerns creating catalog resources that point to registered locations. For CreateTable, the registered-location requirement also depends on whether the database has a registered location that covers the table path. See the Lake Formation permissions reference.

Original exercise: The analyst can inspect orders columns but cannot run SELECT order_id FROM retail.orders. Treat schema visibility as evidence for a metadata operation only. It is not an end-to-end read test. Ask whether the query targets columns permitted by the actual SELECT grant and whether the opted-in pair matches the table being queried.

Now introduce a different operation. Loader creates retail.orders_stage at a registered prefix. It has IAM glue:CreateTable and Lake Formation CREATE_TABLE, but the database has no location property and Loader lacks data-location permission for the target. Under these stated conditions, the missing location permission explains a failure even if Loader can query an existing table.

Changing the assumption changes the answer: if the database's registered location covers the new table's location, the reference documents a CreateTable exception. “Every registered table creation always needs a separate DATA_LOCATION_ACCESS grant” is too broad.

The counterexample is the point of this question. Reading existing rows and authoring metadata for a new registered path should appear as separate entries in your permission investigation. Do not treat a successful SELECT as proof that Loader may create arbitrary catalog pointers.

What does the registered S3 location actually change?

Official fact: In the hybrid query workflow, an integrated engine obtains catalog information, Lake Formation checks its applicable permissions, and a registered S3 location enables credential vending. AWS notes that vending is unavailable for unregistered locations even if a principal-resource pair is opted in. See How hybrid access mode works.

Official fact: Lake Formation assumes the role used to register the location. That role must have the required permissions for the location and an appropriate trust relationship. The registration-role documentation describes this separate identity.

Original diagnostic reasoning: Draw the assumed role alongside the query role. If you put every permission on a box labeled “user,” you hide the principal that actually needs source access in the governed path. Registration is more than a catalog label; inspect the registered prefix and role when credential vending or source reads fail.

Consider a table accidentally moved from orders/ to orders-v2/, outside the intended registered prefix. Yesterday's successful query tested yesterday's location. Compare the current table location with registration before explaining the new failure as a mysterious grant propagation delay.

Also distinguish a direct S3 read from an Athena query. Under the exercise's independent source-S3 IAM authorization, a direct read may use that separate path. A Lake Formation column restriction alone is not evidence that every possible raw-object route is blocked. Test the access routes your design intends to permit, including the ones that bypass your chosen query interface.

How would you debug an access error without widening everything?

The following is an original evidence sequence, not a promise that AWS emits one universal error message. Stop at the first unsupported assumption and gather evidence there.

Pin the request. Record the query execution identifier, Region, catalog, database, table, workgroup, result location, and observed caller. Compare the assumed role with the grant recipient, rather than using the console user's name as a substitute.
Establish the route. Inspect the S3 registration and the exact principal-resource opt-in. A grant list shows permissions; the opt-in list establishes whether this principal-resource pair uses them.
Match the operation. Separate metadata inspection, SELECT, CreateTable, and changing a table location. Use the permission relevant to that operation.
Check the remaining identities. Identify the required query API permissions, registration role, source location, result bucket, and any relevant encryption key. Follow the failed request instead of granting all permissions at every layer.
Retest the same retail.orders query or the same orders_stage metadata operation. Change one justified condition, preserve the others, and compare both roles. Include a denied query outside the intended scope so the repair has a boundary.

Official inspection option: AWS documents list-lake-formation-opt-ins for viewing opted-in principals and resources in Viewing principals and resources in hybrid access mode. Use an authorized administrative read; do not infer absence from an incomplete page of results or from a different account.

aws lakeformation list-lake-formation-opt-ins

In the exercise, check whether the returned entries include Analyst and the intended catalog/database/table. This is an inspection command, not a grant or a repair script. Access to the inspection itself is a separate requirement.

A concise incident note should connect observation to hypothesis: “The failing query used Analyst in catalog X; its table pair is opted in; SELECT exists; GetDataAccess is absent.” That is more reviewable than “Lake Formation seems broken.”

How should you discuss a hybrid migration?

Official fact: AWS's setup documentation treats location registration, permission grants, and principal-resource opt-in as distinct steps. Its limitations also distinguish table creation from an UpdateTable that changes the location. See Converting a Glue resource to hybrid access and hybrid considerations and limitations.

Official fact: When converting an existing Lake Formation resource to hybrid access, AWS describes opting in existing principals before updating the registration to prevent interruption. Read the direction-specific existing-resource migration instructions.

Original preparation recommendation: Describe the migration direction before its steps. For the exercise's IAM-to-hybrid introduction, select one canary role-table pair, record its current successful and forbidden queries, establish the required grants and opt-in, and repeat those checks while keeping the legacy role on its intended route.

Do not remove IAMAllowedPrincipals across the whole database as an unexplained troubleshooting shortcut. That can interrupt LegacyReport by removing the compatibility condition its successful query depended on. Likewise, opt-out is not automatically a security-preserving rollback: returning a role to broader IAM source access could change what it can read. Compare the resulting allowed and denied operations before calling the rollback safe.

An interview answer can propose these checks without claiming to have executed an AWS migration. The saved pure-Python fixture passed 11 local checks of this decision matrix and the CreateTable counterexample. Those checks test the stated assumptions; they do not simulate AWS's full policy evaluator or verify a cloud deployment.