An outside conservation scientist needs to run queries against one specific Lakehouse holding gallery humidity and vibration telemetry, but the archives network does not want to make her a member of the workspace or expose any other item in it. What should the data engineering team do?
Select an answer to reveal the explanation.
Short Explanation
Sharing a single item is like handing someone a key to one vault instead of the master key to the whole building. Item-level sharing grants access to just that Lakehouse — nothing else in the workspace lights up for her, and she never becomes a workspace member.
Full Explanation
Fabric separates workspace-level access from item-level access precisely for cases like this: a person outside the team who needs exactly one artifact. Sharing the Lakehouse item directly grants a scoped permission (such as Read or ReadAll) on that item alone, without adding the recipient to the workspace's member list and without exposing sibling items — other lakehouses, warehouses, pipelines — that happen to live in the same workspace. Adding her as a Viewer fails the requirement outright: workspace roles are workspace-wide, so she would see every item the role permits, not just the one telemetry Lakehouse. A OneLake data access role is the right category of tool for fine-grained data access but is defined and assigned per item, not tenant-wide, so 'scoped to the whole tenant' misdescribes how it works and would be far broader than needed. Moving the item to its own capacity changes performance isolation, not who can see the data, so it doesn't address the access question at all. Operationally, the engineer should verify the share by opening the Lakehouse's access list and confirming the scientist's account appears there alone, with no corresponding entry in the workspace's member list.