Maintain a data analytics solution Study Guide — DP-600

Maintain a Data Analytics Solution

This domain covers the operational and governance layer of Microsoft Fabric: how you secure data at every granularity, govern content through endorsement and sensitivity labels, manage the analytics development lifecycle with version control and deployment pipelines, and handle downstream impact. It accounts for 27% of the exam — the largest single domain — making it the highest-leverage area to master. Expect scenario-based questions that require you to choose the correct combination of controls, not just recognize that a control exists.

Workspace-Level and Item-Level Access Controls

Workspace Roles

Every Fabric workspace uses a role-based access control (RBAC) model with four fixed roles. Permissions are cumulative from lowest to highest.

Key details:

• Members can add other Members and below, but cannot add Admins.
• Contributors can create, edit, and delete items, but cannot manage workspace membership.
• Workspace roles grant broad access to all items in the workspace; use item-level permissions to restrict further.

Item-Level Permissions

Individual Fabric items (semantic models, reports, lakehouses, warehouses, dataflows) can have permissions granted independently of workspace role.

• Build permission on a semantic model lets a user create new reports on top of it without being a workspace Contributor.
• ReadAll on a lakehouse grants access to underlying OneLake files (bypasses SQL-level controls); use it deliberately.
• Sharing a report does not automatically grant access to the underlying semantic model — the model must be shared separately or the user must have Build permission.

Common Traps

• Confusing Member and Admin: only Admin can remove workspace Admins or delete the workspace.
• Assuming workspace Viewer can create reports — they cannot; they need Build permission on the semantic model.
• Thinking item sharing propagates up to workspace membership — it does not.
• ReadAll vs Read on a lakehouse: Read grants SQL endpoint access only; ReadAll grants OneLake file access.

Worked Scenario

Requirement: A data analyst needs to build new Power BI reports on a shared semantic model but must not be able to edit any other workspace items.

Reasoning: Grant the analyst Build permission on the semantic model directly (item-level). Do not add them as a workspace Contributor — that would grant edit access to all items. Workspace Viewer alone is insufficient because Viewer cannot create reports.

Row-Level, Column-Level, Object-Level, and File-Level Access Control

Bold Decision Flow — choosing the right granularity control:

Diagram 1: Choosing the correct data access control granularity

Row-Level Security (RLS)

• Defined in Power BI Desktop or via XMLA endpoint using DAX filter expressions on tables.
• Applied to semantic models; roles are enforced whenever the model is queried.
• Static RLS: filter expression hardcodes values (e.g., [Region] = "East").
• Dynamic RLS: uses USERPRINCIPALNAME() or USERNAME() DAX functions to filter based on the logged-in user.
• RLS does not apply to workspace Admins, Members, or Contributors — those roles see all data (they are considered "model owners").
• RLS does apply to Viewers and users with Build/Read item permissions.
• In a Warehouse, RLS is enforced at the SQL analytics endpoint using T-SQL CREATE SECURITY POLICY.

Column-Level Security (CLS) and Object-Level Security (OLS)

• OLS is configured in Tabular Editor or via XMLA; it cannot be set in Power BI Desktop UI natively.
• OLS makes a column invisible — a report referencing a hidden column breaks at runtime for restricted users.
• OLS roles stack with RLS roles; a user can be in multiple roles simultaneously.

File-Level Security in OneLake

• OneLake uses Azure Data Lake Storage Gen2 (ADLS Gen2) ACL-style permissions underneath.
• Access to files can be granted via:
  1. Workspace roles (broadest)
  2. ReadAll item permission on a lakehouse
  3. OneLake data access roles (preview as of exam scope) — more granular folder-level access
• Shortcuts from external sources respect the source system's permissions at read time.

Common Traps

• RLS does not protect data queried directly via XMLA endpoint by workspace Admins/Members/Contributors.
• OLS and RLS are separate role sets — creating an OLS role does not automatically create an RLS role.
• CLS in the warehouse is enforced at T-SQL layer only; it does not affect Power BI visuals if the underlying lakehouse table is accessed directly.
• Applying RLS in Power BI Desktop to a DirectQuery model does not add overhead at model level — the filter is pushed to source, but RLS still depends on the model role membership.