Isolating PII Tables in a Fabric Lakehouse

DP-700 By islever Editorial Last updated

Configure security and governance Configure Microsoft Fabric workspace settings

Short answer

DEF Create Workspace2 with Lakehouse2, move the Employee PII table there, and give the engineer Contributor on Workspace1 to write Customer.

Question

You have a Fabric workspace named Workspace1 that contains a lakehouse named Lakehouse1. Lakehouse1 contains the following tables:
Orders
Customer
Employee
The Employee table contains Personally Identifiable Information (PII).
A data engineer is building a workflow that requires writing data to the Customer table, however, the user does NOT have the elevated permissions required to view the contents of the Employee table.
You need to ensure that the data engineer can write data to the Customer table without reading data from the Employee table.
Which three actions should you perform? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
  1. Share Lakehouse1 with the data engineer.
  2. Assign the data engineer the Contributor role for Workspace2.
  3. Assign the data engineer the Viewer role for Workspace2.
  4. Assign the data engineer the Contributor role for Workspace1. Correct Answer
  5. Migrate the Employee table from Lakehouse1 to Lakehouse2. Correct Answer
  6. Create a new workspace named Workspace2 that contains a new lakehouse named Lakehouse2. Correct Answer
  7. Assign the data engineer the Viewer role for Workspace1.

Key Takeaways

The question tests whether you understand that Contributor on a workspace grants read access to everything in it, so the only way to allow writes to Customer while blocking reads of Employee is to relocate the PII table to a different workspace.

In Microsoft Fabric, workspace-level roles are the granularity boundary for lakehouse access, so protecting the Employee table's PII means physically separating it from the tables the data engineer must write to. The correct solution combines three moves: create Workspace2 with Lakehouse2, migrate the Employee table there, and grant the engineer Contributor rights on Workspace1 only.

Common mistake: The most common wrong pick is choosing A (share Lakehouse1) plus a role assignment — lakehouse sharing is read-oriented and still exposes every table in that lakehouse, including Employee, so it cannot satisfy the restriction. Learners also mistakenly grant Contributor or Viewer on Workspace2, which would either expose the PII data or be pointless.

Expert Analysis

Why the Answer Is Correct

Option F creates Workspace2 containing a new Lakehouse2, establishing a separate permission boundary; in Fabric, workspace roles are the coarsest access-control unit, so anything in a workspace is visible to anyone with a role there. Option E migrates the Employee table out of Lakehouse1 into that new lakehouse, removing the PII from the environment the engineer touches. Option D then grants Contributor on Workspace1, which is the role that permits writing (adding, editing, and saving) tables such as Customer. Together, F + E + D let the engineer write to Customer while the Employee data is unreachable, exactly matching the stated requirement.

Why the Other Options Are Wrong

Option A, sharing Lakehouse1, is a read-oriented sharing mechanism that exposes the whole lakehouse contents, so the engineer would still see the Employee PII — commenters such as IshtarSQL note that "Sharing Lakehouse1 directly grants access to all its contents, including the Employee table". Options B and C are wrong twice over: they target Workspace2, which after migration holds the sensitive Employee table, and Viewer (C) grants no write capability at all. Option G, Viewer on Workspace1, gives read access but no ability to write to the Customer table, failing the workflow requirement.

Community Comment Notes

The community is essentially unanimous on DEF, with nine of ten voters selecting that combination. robertlavigne's highly rated explanation states "First we need to do F and E to separate the Employee table from the other tables. Then they need contributor access to be able to write to the Customer table". Wipag adds the useful detail that "Contributor role is required to write data to tables in the workspace, including Customer." Only one outlier voted ADE, citing an AI-generated answer, and henryphchan simply confirms "The steps are F, E, D" — the same verdict reached independently.

Official Reference

https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-sharing

This link opens the official vendor documentation in a new tab.

Exam Strategy

On Fabric permission questions, map each required capability to the narrowest role that grants it: Viewer is read-only, Contributor can modify content, and only workspace admins manage access. When a requirement says a user must NOT see specific data, look for an answer that physically separates that data into a different workspace or lakehouse, since in-workspace roles cannot restrict individual tables.

Frequently Asked Questions

Why can't we just share Lakehouse1 with the data engineer instead of moving the Employee table?

Lakehouse sharing in Fabric grants read access to the lakehouse's contents, so the engineer would still be able to read the Employee table and its PII. Sharing cannot hide individual tables.

Why is Contributor on Workspace2 wrong rather than helpful?

After the migration, Workspace2 holds the Lakehouse2 that contains the PII-bearing Employee table. Granting the engineer any role there would expose exactly the data you are trying to protect.

More DP-700 FAQ →

Discussion 26 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 26

  1. robertlavigne 👍 20
    First we need to do F and E to separate the Employee table from the other tables. Then they need contributor access to be able to write to the Customer table which is in Workspace1 A is incorrect as sharing only gives read access. https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-sharing B is incorrect as Workspace2 has the Employee table which the data engineer shouldn’t access. C is incorrect as viewer won’t allow them to write and the Customer table isn’t even in that workspace E is incorrect as viewer won’t allow them to write
  2. fassil 👍 11
    Assign the data engineer the Contributor role for Workspace1 ( D) - This will provide the necessary permissions to write to the Customer table. Migrate the Employee table from Lakehouse1 to Lakehouse2 (E) - This will isolate the table with PII in a different lakehouse. Create a new workspace named Workspace2 that contains a new lakehouse named Lakehouse2 (Option F) - This is necessary to separate the Employee table into a different workspace to restrict access.
  3. alirana3 👍 4
    The three correct actions to take are: E. Migrate the Employee table from Lakehouse1 to Lakehouse2 — This isolates sensitive data (Employee table) from the data engineer’s access. D. Assign the data engineer the Contributor role for Workspace1 — This allows the data engineer to write to the Customer table in Lakehouse1. F. Create a new workspace named Workspace2 that contains a new lakehouse named Lakehouse2 — This action is a result of migrating the Employee table to Lakehouse2 in a separate workspace (Workspace2) to ensure restricted access to sensitive data (PII). Why Option A is Incorrect: A. Share Lakehouse1 with the data engineer: Sharing only gives read access to the lakehouse, which is not sufficient for the data engineer to write data to the Customer table in Lakehouse1. They need write permissions to modify the table, so Contributor role for Workspace1 is the correct option.
  4. VenkataPhaniPavanKumar 👍 4
    Solution Steps: Isolate sensitive data: Create a new workspace (Workspace2) with a new lakehouse (Lakehouse2) to host the PII data separately. → F. Create a new workspace named Workspace2 that contains a new lakehouse named Lakehouse2. Move PII data: Migrate the Employee table (PII) from Lakehouse1 to Lakehouse2 to remove it from the original environment. → E. Migrate the Employee table from Lakehouse1 to Lakehouse2. Grant minimal write permissions: Assign the Contributor role for Workspace1 to the data engineer. This role allows writing to objects (like the Customer table) but does not grant access to Workspace2 (where PII resides). → D. Assign the data engineer the Contributor role for Workspace1.
  5. IshtarSQL 👍 4
    Why A is incorrect: A. Share Lakehouse1 with the data engineer. Sharing Lakehouse1 directly grants access to all its contents, including the Employee table, which violates the requirement.
Show 21 more comments
  1. Tuki93 👍 4
    I think D, E, and F are the working solution.
  2. Wipag 👍 3
    ✅ D. Assign the data engineer the Contributor role for Workspace1 Contributor role is required to write data to tables in the workspace, including Customer. This role allows adding or editing content but not managing access or seeing hidden data like Employee if it’s secured separately. ✅ E. Migrate the Employee table from Lakehouse1 to Lakehouse2 Since the Employee table contains PII, and the engineer should not have access to it, moving it to a separate lakehouse ensures isolation of sensitive data, while still allowing access to Customer in Lakehouse1. F. Create a new workspace named Workspace2 that contains a new lakehouse named Lakehouse2
  3. Bin_Hashim 👍 3
    Separate the PII table from the lakehouse the engineer will use. F. Create a new workspace named Workspace2 that contains a new lakehouse named Lakehouse2. E. Migrate the Employee table from Lakehouse1 to Lakehouse2. Only users who need PII access are given permissions to Workspace2/Lakehouse2. Give the engineer write access only where Customer lives. D. Assign the data engineer the Contributor role for Workspace1. This lets them write to the Customer table (and Orders) in Lakehouse1, while they have no access to Workspace2/Lakehouse2 and therefore cannot read Employee. So the correct actions are: D, E, and F.
  4. henryphchan 👍 3
    The steps are F, E, D
  5. MohanNaidu08 👍 2
    A. Share Lakehouse1 with the data engineer This gives the data engineer access to the lakehouse so they can interact with its tables. Sharing is required before any role-based permissions can be applied. D. Assign the data engineer the Contributor role for Workspace1 The Contributor role allows users to read and write data to lakehouse tables. However, table-level security can still restrict access to specific tables like Employee. E. Migrate the Employee table from Lakehouse1 to Lakehouse2 This isolates the PII data in a separate lakehouse. Since the data engineer won’t have access to Lakehouse2, they won’t be able to read the Employee table, even if they have Contributor access to Lakehouse1.
  6. MultiCloudIronMan 👍 2
    So, in this case, your answer DEF makes sense as it covers the necessary steps: Create a new workspace and lakehouse (Workspace2 and Lakehouse2). Migrate the Employee table to the new lakehouse. Assign the data engineer the Contributor role in the original workspace.
  7. AbhirupAz900 👍 2
    Since only 3 answers needed to be selected ADE
  8. 92ef42d 👍 2
    I wouldn't rely on that... It is 50/50...
  9. SaswataNad 👍 2
    As per chatGPT
  10. ChenFu 👍 1
    C. Assign the Viewer role for Workspace2: This ensures the data engineer can see the structure and metadata of the workspace without accessing sensitive Employee table data. They can still write to the Customer table without elevated permissions. E. Migrate the Employee table from Lakehouse1 to Lakehouse2: This separates Personally Identifiable Information (PII) from the original lakehouse, ensuring the data engineer does not have access to sensitive data while working with non-PII data. F. Create Workspace2 with Lakehouse2: This creates an isolated environment specifically for sensitive data like the Employee table. It ensures workspace-level access control and adheres to privacy and security best practices.
  11. DarioReymago 👍 1
    FED: Create a new workspace and lakehouse (Workspace2 and Lakehouse2). Migrate the Employee table to the new lakehouse. Assign the data engineer the Contributor role in the original workspace. con esto los ingenieros no pueden ver ni escribir los datos PII
  12. alqazqzy.asseel 👍 1
    D, E, F, create new workspace2 , and new lakehouse2. Then migrate the employee table to the new workflow. Finally assign the data engineer the Contributor role for Workspace1 so they can write and do their job.
  13. Mustafa_Shazly 👍 1
    the order F >> E >> D - A and G not true because sharing and viewer not give writing permssion - B and C not true because user mustn't see Emp table where we will migrate it to WS2
  14. i_have_a_name 👍 1
    If we are migrating the Employee table to Lakehouse 2 in the workspace 2 , what is wrong in sharing the Lakehouse 1 with the data engineer ? My answer would be A, E, F
  15. dcprice 👍 1
    Currently uou can't give write access via Lakehouse sharing. https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-sharing. So it is DEF
  16. prabhjot 👍 1
    but then you ultimately would have to give the data engineer a contributor access to workspace 1 for him to work on the lakehouse as far as i think.
  17. devpool 👍 1
    data engineer can write data to the Customer table : B data engineer does not perform migration.
  18. Josekonoor 👍 1
    basically you have to move the high security item to another workspace
  19. NNPRN 👍 1
    The order is F---E---D.
  20. smanzana 👍 1
    Correct DEF
  21. Etensel 👍 1
    belive me..

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

A 500-million-row fact table exceeds the F32 Direct Lake guardrail, so increase the capacity to F64

S-grade

Shortcut caching supports only S3/GCS shortcuts and excludes files larger than 1 GB

S-grade

Updating warehouse tables requires at least the Contributor workspace role because Write is not shareable to a Viewer

S-grade

Run T-SQL in a KQL database only by prefixing the query with a -- comment line

S-grade

← Back to DP-700 Study Guide