An external auditor needs to query a single Microsoft Fabric Lakehouse through its SQL analytics endpoint for a two-week engagement. The auditor must be able to run SELECT statements over the Lakehouse tables but must not be able to browse files in the Lakehouse explorer, edit any notebooks, or appear in the workspace membership list. The data engineer wants to grant the narrowest access that still lets the auditor query the endpoint. What should the data engineer do?
- AAdd the auditor to the workspace with the Viewer role, because Viewer is read-only and so naturally limits the auditor to querying the SQL analytics endpoint without edit rights.
- BShare the Lakehouse with the auditor and grant the full Read permission, since Read is required for any access and it confines the auditor to reading rather than editing.
- CShare the Lakehouse with the auditor and grant ReadData on the SQL analytics endpoint, which lets the auditor run SELECT queries through the endpoint without workspace membership or file access. Correct
- DCreate a separate Microsoft Fabric Warehouse, copy the tables into it, and grant the auditor access there so the original Lakehouse is never exposed to the auditor at all.
Why A is wrong: Viewer puts the auditor in the workspace membership list and grants read access to all items, which violates both the non-member and the files-not-browsable constraints.
Why B is wrong: The Read permission on a Lakehouse exposes file browsing in the explorer and OneLake, which the requirement forbids, so it grants more surface than the auditor should have.
Why C is correct: Sharing the item with the ReadData permission grants endpoint query rights to a non-member while withholding the Read permission that would expose Lakehouse files, giving the narrowest qualifying access.
Why D is wrong: Copying data into a new Warehouse duplicates storage and adds maintenance overhead, and item-level sharing already meets the need, so this is not the narrowest or simplest approach.