Workspace roles and item-level access in Fabric
Access in Fabric works in layers: the workspace role, permissions on a single item, and then data-level rules inside the warehouse or SQL endpoint. The exam mostly asks you to choose the smallest layer that does the job.
Workspace roles
Roles apply to every item in the workspace.
| Role | Can do |
|---|---|
| Viewer | View and read data through SQL endpoints; cannot create or edit |
| Contributor | Create, edit and delete items; cannot share or manage people |
| Member | Everything Contributor does, plus add people with lower roles and share items |
| Admin | Everything, including delete the workspace and add Admins |
“Create items, least privilege” is almost always Contributor. A role is inherited by all items, so it is too broad when the user should reach only one item.
Item-level sharing
You can share a single item without giving any workspace role. For a lakehouse, the share dialog offers extra permissions:
- Read all SQL endpoint data: query tables with T-SQL only.
- Read all Apache Spark: read the files and tables through Spark and OneLake.
- Build reports on the default semantic model.
Pick the SQL option when the requirement says “must not use Spark to read the files”.
Data-level security in a warehouse
These features are T-SQL based and work in the warehouse and the SQL analytics endpoint.
- Row-level security (RLS): create an inline table-valued function that returns the rows a user may see, then a security policy with a filter predicate on the table.
- Column-level security: GRANT SELECT on specific columns only.
- Dynamic data masking (DDM): hides values at query time. Functions are default(), email(), random() and partial().
- Object-level permissions: GRANT, DENY and REVOKE on tables, views and schemas.
ALTER TABLE dbo.DimCustomer
ALTER COLUMN EmailAddress
ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXX",5)');
GRANT UNMASK TO [Group2];Users with the UNMASK permission see real values. Workspace Admin, Member and Contributor roles also bypass masking, so mask for Viewers or item-shared users.
OneLake data access roles
In a lakehouse you can also define folder-level roles on files and tables (OneLake security). Use them when different users need different folders of the same lakehouse.
Exam traps
- Viewer is not “no access”: Viewers can read data through the SQL endpoint, so do not assume it blocks queries.
- Giving a user the Member role to reach one lakehouse breaks least privilege; share the item instead.
- Masking is not encryption and does not stop a user inferring values with filters.
- RLS needs both the function and the security policy; the function alone does nothing.
- Contributor, Member and Admin see unmasked data.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. A user must be able to create and edit items in a workspace but must not manage access for others. Following least privilege, which role do you assign?
Show answer
Answer: B.Contributor can create and edit items but cannot share items or manage users. Member and Admin can add people.
2. An analyst needs to query the tables of one lakehouse through the SQL analytics endpoint only, with no access to other items and no Spark access to files. What do you do?
Show answer
Answer: C.Sharing the single item with the SQL read permission limits the user to the SQL analytics endpoint. The Spark permission would expose the underlying files.
3. Each sales representative must see only their own rows in a warehouse table. Which objects do you create?
Show answer
Answer: B.Row-level security in a warehouse uses an inline table-valued function as the predicate and a security policy that binds it to the table.
4. The EmailAddress column must show only the first character and the last five characters to most users. Which masking function fits?
Show answer
Answer: D.partial(prefix, padding, suffix) keeps a custom number of leading and trailing characters, for example partial(1,"XXXX",5).