Isolating PII Tables in a Fabric Lakehouse
Answer
Correct answer: D, E, F — Create Workspace2 with Lakehouse2, move the Employee PII table there, and give the engineer Contributor on Workspace1 to write Customer.
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.
Community Insight
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.
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.
Community Discussion (26 comments)
alqazqzy.asseel
👍 1
Selected: DEF
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.
devpool
👍 1
Selected: BEF
data engineer can write data to the Customer table : B data engineer does not perform migration.
Josekonoor
👍 1
Selected: DEF
basically you have to move the high security item to another workspace
Mustafa_Shazly
👍 1
Selected: DEF
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
Bin_Hashim
👍 3
Selected: DEF
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.
SaswataNad
👍 2
Selected: ADE
As per chatGPT
92ef42d
👍 2
I wouldn't rely on that... It is 50/50...
VenkataPhaniPavanKumar
👍 4
Selected: DEF
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.
Wipag
👍 3
Selected: DEF
✅ 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
smanzana
👍 1
Selected: DEF
Correct DEF
DarioReymago
👍 1
Selected: DEF
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
NNPRN
👍 1
Selected: DEF
The order is F---E---D.
MohanNaidu08
👍 2
Selected: ADE
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.
alirana3
👍 4
Selected: DEF
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.
AbhirupAz900
👍 2
Selected: ADE
Since only 3 answers needed to be selected ADE
Etensel
👍 1
Selected: ADE
belive me..
fassil
👍 11
Selected: DEF
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.
ChenFu
👍 1
Selected: CEF
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.
henryphchan
👍 3
Selected: DEF
The steps are F, E, D
MultiCloudIronMan
👍 2
Selected: DEF
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.
robertlavigne
👍 20
Selected: DEF
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
i_have_a_name
👍 1
Selected: AEF
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
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
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.
Tuki93
👍 4
Selected: DEF
I think D, E, and F are the working solution.
IshtarSQL
👍 4
Selected: DEF
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.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.