A Fabric tenant has a workspace named Workspace1 containing a lakehouse, a data pipeline, a notebook, and several Microsoft Power BI reports. A user named User1 plans to use SQL to access the lakehouse to analyze data. User1 must have read-only access to the lakehouse, must NOT be able to access the rest of the items in Workspace1, and must NOT be able to use Spark to query the underlying files. How should you configure access for User1?

A Fabric tenant has a workspace named Workspace1 containing a lakehouse, a data pipeline, a notebook, and several Microsoft Power BI reports. A user named User1 plans to use SQL to access the lakehouse to analyze data. User1 must have read-only access to the lakehouse, must NOT be able to access the rest of the items in Workspace1, and must NOT be able to use Spark to query the underlying files. How should you configure access for User1?

• A. Grant Read to the lakehouse via workspace role
• B. Share the lakehouse with User1 directly and select Read all SQL Endpoint data.
• C. Allow read-only via inherited permissions from the workspace
• D. Add Spark access to the lakehouse

Answer: (B)

Controlling access with direct resource-based sharing and a specific SQL-read permission keeps access scoped exactly to what’s needed. By sharing the lakehouse directly with User1 and granting Read all SQL Endpoint data, User1 can connect via the lakehouse’s SQL endpoint and run read-only queries, while nothing about the rest of Workspace1 is exposed and Spark access isn’t granted. Relying on workspace-wide permissions would inherit access to other items in the workspace, which violates the requirement to restrict access to the lakehouse only. Allowing Spark would enable queries through Spark, which also isn’t allowed. This direct, limited sharing aligns with giving User1 only what’s necessary for SQL analysis.

Controlling access with direct resource-based sharing and a specific SQL-read permission keeps access scoped exactly to what’s needed. By sharing the lakehouse directly with User1 and granting Read all SQL Endpoint data, User1 can connect via the lakehouse’s SQL endpoint and run read-only queries, while nothing about the rest of Workspace1 is exposed and Spark access isn’t granted.

Relying on workspace-wide permissions would inherit access to other items in the workspace, which violates the requirement to restrict access to the lakehouse only. Allowing Spark would enable queries through Spark, which also isn’t allowed. This direct, limited sharing aligns with giving User1 only what’s necessary for SQL analysis.