2.1 Workspace & Item Security
Key Takeaways
- Fabric has exactly four workspace roles — Admin, Member, Contributor, Viewer — and the exam expects you to grant the least privilege that meets the stated need.
- Contributor can create, edit, and publish items but cannot manage workspace membership or settings; only Member and Admin can manage access, and only Admin controls capacity and deletion.
- Item-level sharing (Read, Read+Reshare, Read+Build) exposes a single asset such as one semantic model without granting any workspace role.
- OneLake data access roles layer path-level (folder/table) read control on top of workspace roles for lakehouse data.
- Workspace roles are assigned to security groups or Microsoft 365 groups in production — never one-off individual users — for maintainable governance.
Why Security Layering Matters
Quick Answer: Grant the lowest workspace role that accomplishes the task. Use item-level sharing when only one asset must be exposed. Add OneLake data access roles when you need folder/table-level control over lakehouse data. Broadening a workspace role to solve a single-asset problem is the classic wrong answer the DP-600 exam baits you with.
This topic sits in the Plan, implement, and manage a solution for data analytics domain. Microsoft phrases these as scenario questions: a named persona, a specific need, and a constraint such as "must not manage access" or "must not see other items." The disciplined approach is to read the constraint last and let it eliminate the over-privileged options.
The Four Workspace Roles
A Microsoft Fabric workspace supports four built-in roles. They are strictly ordered in privilege, and each higher role is a superset of the one below it.
| Role | Can Do | Cannot Do |
|---|---|---|
| Admin | Everything: update workspace settings, assign capacity, manage all roles, delete the workspace, configure OneLake data access | Nothing within the workspace is denied |
| Member | Add or remove users up to the Member level, share items and reshare, edit all content, publish | Change Admin-only settings, assign capacity, delete workspace |
| Contributor | Create and edit items, publish reports, write data, run notebooks and pipelines, schedule refresh | Manage workspace membership or settings, share with others by default |
| Viewer | Read and consume content (view reports, read paginated reports, query allowed models) | Create, edit, publish, or write any item |
A frequent trap: a developer who must build semantic models and reports but must not decide who else has access needs Contributor, not Member. Member is over-privileged because it can add and remove users. Conversely, a Viewer who needs to build a personal report on an existing model cannot — Viewer is read-only, so the answer is either item-level Build permission or Contributor.
Item-Level Permissions
Sometimes only one asset should be shared. Consider an executive who needs a single certified semantic model but should never see the dozens of other items in the workspace. The correct approach is item-level sharing, not adding them as a Viewer of the whole workspace.
Item sharing grants one of these permission bundles:
- Read — open and view the item only.
- Read + Reshare — view and pass the same access to others.
- Read + Build — view and create new content (Power BI reports, Excel PivotTables, paginated reports) on top of a shared semantic model, without any workspace role.
Build is the key exam concept: it lets a consumer author their own reports against a shared model while seeing nothing else in the workspace. That is the precise answer to "explore one model and build her own reports, but see no other item."
OneLake Data Access Roles
Workspace and item permissions are broad-grained. For lakehouse data, OneLake data access roles (OneLake security roles) add path-level read control: you define a role granting read access only to specific folders or tables under /Tables or /Files, then assign users or security groups. This scoping cannot be expressed by a workspace role alone, and it governs the physical data, not just the model view.
Decision Order for Sharing
- Does the user need only one asset? → Item-level share (least exposure); add Build if they must author on it.
- Do they need to build/edit broadly across the workspace? → Contributor.
- Do they need to manage other users' access? → Member (or Admin for settings/capacity).
- Do they need only certain lakehouse folders/tables? → OneLake data access role.
In enterprise deployments, always assign roles to Microsoft Entra security groups, not individuals — it keeps access auditable and survives staff changes.
App Audiences vs Workspace Roles
When content is distributed widely to read-only consumers, the best practice is not to add hundreds of people as Viewers. Instead, publish a Power BI app from the workspace and assign consumers to app audiences. Audiences scope which items each group sees inside the app, and the app is the read-only distribution surface, while workspace roles stay reserved for the small team that builds the content.
A typical exam scenario — "500 business users must consume three dashboards but never enter the development workspace" — resolves to a published app with an audience, leaving the workspace to Admin/Member/Contributor builders only.
Common Traps Summarized
| Tempting wrong answer | Why it fails | Correct choice |
|---|---|---|
| Add a single-asset consumer as Viewer of the workspace | Exposes every item | Item share (Read/Read+Build) |
| Make a report builder a Member | Lets them manage users | Contributor |
| Add 500 consumers as Viewers | Unmaintainable, exposes workspace | App with audiences |
| Use a workspace role to limit one lakehouse folder | Roles are workspace-wide | OneLake data access role |
Reading the constraint first — what must the user NOT be able to do — almost always eliminates the over-privileged distractors before you weigh the remaining options.
A finance director must explore one certified semantic model and build her own Power BI reports from it, but must not see any other item in the workspace and must not manage access for others. What is the best way to grant this?
A data engineer needs to create and edit pipelines, lakehouses, and notebooks across a development workspace, but the team lead insists the engineer must not be able to add or remove other users. Which single workspace role fits exactly?