Lesson 2: Workspace-Level Access Controls

Why workspace roles come first

A reminder before we start: this course follows Microsoft's free Study guide for Exam DP-600 on Microsoft Learn. We don't reproduce the guide here, the course is independent of Microsoft and not endorsed by it, and no course can promise you a pass.

The first bullet under Implement security and governance is Implement workspace-level access controls. In Fabric, the workspace is the outer security boundary. It is a container that sits on top of OneLake, and a role you assign there applies to every item inside it: lakehouses, warehouses, notebooks, semantic models, reports. If you build Power BI models, you already know the four roles. Fabric keeps the same four and adds data engineering and data access rights to each one.

An analogy: think of the workspace as an office building. Admin owns the building. Member can hand out keys, but never a master key. Contributor can work in every room and rearrange it, but can't give out keys. Viewer can walk through and look at things, but doesn't get into the stockroom where the raw data files are kept.

What each role can do

Two details people often miss:

• Members can't change an existing user's role and can't remove anyone. A Member can only add people as Member, Contributor or Viewer. To upgrade a Viewer to Contributor, an Admin has to do it.
• On a Warehouse or SQL analytics endpoint, Admin, Member and Contributor all get CONTROL. Viewer gets only CONNECT and ReadData, which works like a read-only database role.

Walkthrough 1: assign roles in the portal

You need Admin or Member on the workspace to do this.

1. Open the workspace → select "Manage access" on the command bar
   (sometimes it's under More options "...")
2. Select "Add people or groups"
3. Type a name or email: a user, security group, mail-enabled security
   group, distribution list, Microsoft 365 group, or service principal
4. Pick a role (Admin / Member / Contributor / Viewer) → "Add"
5. To change a role later, use Search in the panel and open the role dropdown

Gotcha: a change to workspace access only takes effect the next time the user signs in to Fabric. If a user says "I still can't see it", ask them to sign out and back in before you start debugging.

Walkthrough 2: assign a service principal with the REST API

In CI/CD you'll often grant a Microsoft Entra service principal (an app registration) a role. Service principals get the same permissions as users for API operations.

# Caller needs Member or higher on the workspace
# Delegated scope: Workspace.ReadWrite.All
POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/roleAssignments

{
  "principal": {
    "id": "<object-id-of-the-service-principal>",
    "type": "ServicePrincipal"   // also: User, Group
  },
  "role": "Contributor"           // Admin | Member | Contributor | Viewer
}

# → 201 Created, with the new role assignment in the body

A deployment principal usually needs Contributor so it can create and update items. Admin is rarely justified.

Groups, not people

Assign roles to security groups, not to individuals. Everyone in the group gets the role, nested groups pass the role down to their members, and a person who belongs to several groups gets the highest of their roles. A workspace can hold at most 1,000 users or groups in its roles, but a single group can contain as many people as you like. That limit is another reason to use groups.

Pitfall: if Ana is in Sales-Readers (Viewer) and Sales-Authors (Contributor), she is a Contributor. When someone can do more than you expected, look at their group memberships first.

Picking the least-privileged role

There's one more reason to make readers Viewers. Row-level security on Power BI items is enforced for Viewers. Roles that can edit the model see all its rows. You'll configure RLS in a later level. For now, remember that giving a reader Contributor quietly turns RLS off for them.

Why Viewer doesn't mean "can read the lake"

This is the subtle part. A lakehouse holds its data as Delta files in OneLake and exposes it in two ways:

-- As a Viewer, connected to the lakehouse's SQL analytics endpoint:
SELECT TOP 5 CustomerKey, Region FROM dbo.DimCustomer;
-- ✅ Works: Viewer has CONNECT + ReadData (T-SQL over the TDS endpoint)

# Same Viewer, in a Spark notebook or through OneLake APIs:
df = spark.read.format("delta").load("Tables/DimCustomer")
# ❌ Fails: reading the files needs ReadAll, which Viewer doesn't have.
# The Lakehouse explorer won't show the table data either.

So a Viewer gets read access only through the SQL engine, never to the files behind it. That's deliberate. The SQL endpoint can apply SQL-level permissions, but anyone reading the raw files skips those controls. To let a Viewer read files you have to grant something extra, such as item permissions or OneLake security roles. Those come in later levels.

What the exam asks about this

Expect short scenarios like "a user must create notebooks but must not manage access: which role?" (Contributor), "who can connect the workspace to Git?" (Admin only), and "a Viewer can query the SQL analytics endpoint but a Spark notebook fails: why?" (no ReadAll). The exam rewards least privilege, so pick the lowest role that meets the requirement.

Key takeaways

• The four roles are Admin, Member, Contributor and Viewer, and they apply to every item in the workspace.
• Only Admin can delete the workspace, connect it to Git or add Admins. Members can add people at Member level or below, but can't change existing roles.
• Contributor creates, edits and runs items. Choose it for authors and engineers.
• Assign roles to security groups. When someone is in several groups, the highest role wins. Access changes apply at the next sign-in.
• Viewer gets T-SQL ReadData on SQL analytics endpoints and warehouses, but no ReadAll: no Spark, no OneLake APIs, no Lakehouse explorer data.