Implementing Security and Governance in Fabric

Introduction

This lesson opens the domain Maintain a data analytics solution, which carries 25–30% of the DP-600 skills measured. This course targets the English skills-measured syllabus effective October 19, 2026; localized exams usually follow about eight weeks later. Microsoft publishes the weight ranges, the 700/1000 scaled passing score and the 100-minute exam time, but it does not publish the question count or the mix of question types. OnLevelUp mock exams therefore use a 50-question practice length and an 80% practice target, and neither figure is official or a conversion of 700/1000.

Security questions on DP-600 rarely ask you to recite a definition. They describe a team, a data set and a requirement ("analysts must see only their region", "contractors must read one report but not the lakehouse") and ask for the least-privilege, lowest-effort control. The skill is to pick the right layer of control. After this lesson you will be able to choose between workspace roles, item permissions, OneLake security, SQL-level security and semantic-model security; apply sensitivity labels; and use endorsement to signal trust.

Learning objectives

• Distinguish workspace-level access from item-level access and pick the narrowest one that works.
• Implement row-level, column-level, object-level and file-level access control in warehouses, lakehouses and semantic models.
• Explain how OneLake security, SQL analytics endpoint security and semantic-model security interact.
• Apply and reason about sensitivity labels and their inheritance.
• Choose between the Promoted, Certified and Master data endorsement states.

1. The layered security model

Fabric security is a stack of independent layers. A request is allowed only if every layer on its path allows it, and each layer answers a different question:

1. Entra ID authentication and tenant settings – who are you, and are you allowed to use Fabric features at all? Tenant admin settings (for example who may create workspaces or share externally) can be limited to security groups.
2. Workspace roles – what can you do to everything inside this workspace?
3. Item permissions – what can you do to this one item (a lakehouse, a report, a semantic model)?
4. Data-level security – which rows, columns, tables or files within the item can you see?
5. Information protection – sensitivity labels that follow the data and can restrict export and sharing.
6. Governance signals – endorsement, which does not restrict anyone but tells users what to trust.

Exam tip: when a question says "grant access to a single report or table", the answer is almost never a workspace role. When it says "everything in the workspace", it almost never is item sharing.

2. Workspace-level access controls

A workspace is the main container and security boundary. Four roles exist, from most to least privileged:

Key facts the exam relies on:

• Admin, Member and Contributor can write data and are treated as trusted, so OneLake data-access roles, row-level security and column-level security defined on lakehouses and warehouses mainly apply to Viewers and to people who have only item-level Read access. Giving someone Contributor to "let them read one table" silently bypasses your fine-grained rules.
• Assign roles to Microsoft Entra security groups, not to individuals. A group per role per workspace keeps audits simple.
• Workspace roles flow down to all items. You cannot hide one item from a Contributor.
• A workspace must be assigned to a capacity (Fabric F SKU, Power BI Premium or trial) for Fabric items; the capacity is a compute boundary, not a security boundary.

Example. Contoso has a workspace Sales-Prod with a lakehouse, a warehouse, a semantic model and three reports. The data engineering group needs to run pipelines and edit notebooks (Contributor). The BI developers who author models are Members of a separate dev workspace but only Viewers in production. The business users do not get a workspace role at all; they receive an app or report access through item permissions (section 3). This separation of dev and production workspaces is also the basis of deployment pipelines (lesson 2).

3. Item-level access controls

Item permissions let you grant access to one item without touching the rest of the workspace. You set them by sharing the item or from its Manage permissions page. The main permissions are:

Practical rules:

• A report consumer needs Read on the report and access to the underlying data. If the report uses a semantic model in another workspace, the consumer also needs Read (and Build only if they author) on that semantic model, unless the report is delivered through a workspace app that grants access to its content.
• Sharing a lakehouse with Read only lets a user query the SQL analytics endpoint within the SQL permissions you configure; ReadAll lets them read all files and tables through Spark, which is an escalation. Choose deliberately.
• Use sharing links of type "specific people" for external or sensitive items, and restrict who can create "organization-wide" links through tenant settings.

Worked example 1: choosing the access layer. Scenario. A contractor, Maya, must open the Q3 Pipeline report in the Sales-Prod workspace and nothing else. The report is built on a semantic model in the same workspace. What is the least-privilege approach?

Reasoning, step by step.

1. A workspace Viewer role would expose every report and the lakehouse. Too broad.
2. Sharing only the report gives Read on the report, but a report that uses a semantic model in the same workspace needs the viewer to be able to use that model. Fabric grants the necessary access to the model when the report is shared, as long as the report is not using a model that requires separate Build permission for the viewer.
3. Add Maya (through a security group named Contractors-Pipeline) as a recipient of the report share, without Reshare.
4. If the model has row-level security roles, check that the group is assigned to a role; otherwise the contractor may see no data.

Solution. Share the report with the group at item level, no Reshare, and assign the group to the model's RLS role if one exists.

Why the others are worse. Viewer on the workspace exposes unrelated items. Contributor is a write role and bypasses RLS. Sending a PBIX or Excel export copies data outside governance.

4. Data-level access: row, column, object and file

The syllabus names four fine-grained controls. Each lives in a different place, and the exam asks you to pick the right place.

4.1 Row-level security (RLS)

RLS filters which rows a user can see.

• Warehouse and SQL analytics endpoint (T-SQL). You create an inline table-valued function as a predicate and bind it with a security policy:

CREATE SCHEMA Security;
GO
CREATE FUNCTION Security.fn_region_filter(@Region AS varchar(20))
    RETURNS TABLE
    WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS allowed
    WHERE @Region = USER_NAME()          -- or look up a mapping table
       OR USER_NAME() = 'headoffice@contoso.com';
GO
CREATE SECURITY POLICY Security.RegionPolicy
    ADD FILTER PREDICATE Security.fn_region_filter(Region) ON dbo.FactSales
    WITH (STATE = ON);

• Semantic model. You define roles in the model with DAX filter expressions on tables, for example [Region] = USERPRINCIPALNAME() or a lookup through a security mapping table, then assign Entra groups to the roles in the service. This is static RLS if each role hard-codes a value, and dynamic RLS if it uses USERPRINCIPALNAME().
• OneLake security. Data-access roles on a lakehouse can include a row-level rule written as a SQL-style predicate on a table. These rules are enforced when the data is read through OneLake-aware engines.

RLS in a semantic model does not apply to users who have Write permission on the model (workspace Admin, Member, Contributor), because they can edit the model anyway. This is a classic exam trap.

4.2 Column-level security (CLS) and object-level security (OLS)

• CLS in T-SQL restricts columns with GRANT SELECT ON dbo.Customer (CustomerId, Region) TO [Analysts] and omitting sensitive columns (or DENY SELECT on a column).
• OneLake security can grant a role access to selected columns of a table.
• OLS in a semantic model hides entire tables or columns from a role. It is configured through the model's role metadata (using Tabular Editor or the TMDL view). A hidden object disappears from the field list; a report visual that uses it shows an error for that user.
• Dynamic data masking in the warehouse obfuscates values (for example showing xxxx@xxxx.com) without hiding the column.

4.3 File-level and folder-level access

Lakehouse files live in OneLake. OneLake security (data access roles) lets you grant read access to specific folders under Files/ or specific tables under Tables/, with members taken from Entra groups. A role includes a scope of tables and folders, optionally with row and column rules on tables, and users in several roles get the union of their permissions.

4.4 Where each control is enforced

Because a lakehouse can be read through several engines, the safest pattern is to configure OneLake security once, and let the SQL analytics endpoint and Direct Lake semantic models honour it, rather than duplicating rules in each engine. When a Direct Lake semantic model reads data using a fixed identity, security is enforced by the model's own RLS instead; when it uses the viewer's identity, OneLake security applies. Check which identity mode the scenario describes.

Worked example 2: pick the control. Scenario. A retail lakehouse holds Sales with columns OrderId, Region, Amount, CardNumber. Regional analysts (group Analysts-EMEA) must read only EMEA rows and must not see CardNumber. They use SQL and Spark notebooks. They are Viewers of the workspace.

Reasoning.

1. The same people use SQL and Spark, so a T-SQL-only policy would leave Spark open.
2. OneLake security is the one layer that both engines honour.
3. Create a role EMEA-Analysts with the Sales table, a row filter Region = 'EMEA' and column access excluding CardNumber, then add the group.

Solution. A OneLake security role with row and column rules, and members from the Entra group, keeping them as Viewers.

Why other options fail. Contributor bypasses everything. Dynamic data masking leaves the column visible in structure. Hiding the column only in a semantic model protects reports but not direct lakehouse access.

5. Sensitivity labels

Sensitivity labels come from Microsoft Purview Information Protection. A label such as Confidential or Highly Confidential is applied to Fabric items and Power BI content and:

• is shown on the item and in the lineage view;
• travels with exported data (Excel, PowerPoint, PDF) and can apply encryption and access restrictions defined in the label policy;
• can be applied manually, by default, or by a mandatory labeling policy that requires a label before publishing;
• supports downstream inheritance: when a label is applied to a semantic model, reports and exports that depend on it can inherit it, and a more restrictive label on upstream data can propagate to dependants when the tenant setting is enabled;
• requires the tenant admin to enable "Allow users to apply sensitivity labels for content" and label policies to be published to the users.

A label does not by itself grant or deny access to the item inside Fabric; it governs how the data is protected when it leaves, and it informs audit and DLP. A user can only apply a label they are permitted to use, and lowering a label may require justification, depending on policy.

Worked example 3. An analyst exports a Highly Confidential report to Excel and mails it. Because the label carries encryption, the Excel file is encrypted and only authorized recipients can open it. A common wrong answer is "use RLS", which only filters rows inside Fabric and does nothing for an exported file.

6. Endorsement

Endorsement helps users find reliable content. It is a governance signal, not a security control.

Endorsement applies to many item types, including semantic models, lakehouses, warehouses, dataflows and reports. Endorsed items rank higher in the OneLake catalog. Certification requires tenant settings that define who the reviewers are; ordinary contributors cannot certify their own work.

Common pitfalls

• Giving Contributor to someone who "just needs to read" – it bypasses RLS, CLS and OneLake security.
• Expecting semantic-model RLS to protect the lakehouse behind a Direct Lake or composite model when users can query the lakehouse directly.
• Assuming a sensitivity label restricts in-product access; it protects data that leaves and informs policies.
• Assigning roles to individuals instead of groups.
• Confusing Promoted (anyone with write access) with Certified (only designated reviewers).
• Forgetting that OLS errors appear in visuals that reference a hidden column.

Exam tip: read the persona's engine in the scenario. If users access data from Spark and SQL, think OneLake security; if only through reports, think semantic-model RLS/OLS; if only through SQL, think T-SQL policies.

Mini case study

Fabrikam Logistics runs a Logistics-Prod workspace with a lakehouse LH_Shipments, a Direct Lake semantic model and a report. Requirements: (1) the 12 data engineers must build pipelines; (2) 400 regional managers must see only shipments of their own region in reports; (3) the finance team must read the Cost column in SQL but regional managers must not; (4) the model should show a "trusted" badge once reviewed by the governance office; (5) exported files containing shipment prices must be encrypted.

Proposed solution and commentary.

1. Put the data engineers in an Entra group assigned Contributor; do not make them Members unless they must manage access.
2. Regional managers get no workspace role. They consume through the report or app. Define dynamic RLS on the semantic model using USERPRINCIPALNAME() and a UserRegion mapping table, and assign the managers' group to the role.
3. The Cost column: create a OneLake security role (or T-SQL CLS) granting the finance group access to Cost, and one for managers excluding it; for the semantic model, use OLS to hide Cost from the managers' role.
4. Ask the governance office (designated certifiers) to set the model to Certified; the owners can only mark it Promoted.
5. Apply the Highly Confidential sensitivity label with encryption to the model; exports inherit it.

Why this works. Each requirement is met at the narrowest layer: roles for builders, RLS/OLS for consumers, endorsement for trust, labels for exports. No one receives a role broader than needed.

Key terms

• Workspace role: Admin, Member, Contributor or Viewer, applied to all items in a workspace.
• Item permission: Read, ReadAll, Build, Reshare and similar rights on one item.
• RLS / CLS / OLS: row, column and object-level security.
• OneLake security: role-based data access on lakehouse tables and folders, with row and column rules.
• Sensitivity label: a Purview Information Protection classification that follows content.
• Endorsement: Promoted, Certified or Master data signal.

Summary checklist

• I can state what each workspace role may do and why Contributor bypasses fine-grained rules.
• I can grant one user access to one item without a workspace role.
• I know where RLS, CLS, OLS, masking and file-level access are configured and which engines honour them.
• I know labels protect exported data and inherit downstream, and that they are not an access list.
• I can tell Promoted, Certified and Master data apart and who can set each.
• I remember that the course targets the syllabus effective October 19, 2026 and that the practice length (50 questions) and 80% target are not official.

Official sources

• Study guide for Exam DP-600: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/dp-600 (opens in a new tab)
• OneLake security: https://learn.microsoft.com/en-us/fabric/onelake/security/get-started-security (opens in a new tab)
• OneLake security roles, permissions and scopes: https://learn.microsoft.com/en-us/fabric/onelake/security/data-access-control-model (opens in a new tab)
• Share items in Microsoft Fabric: https://learn.microsoft.com/en-us/fabric/fundamentals/share-items (opens in a new tab)
• Security in Microsoft Fabric: https://learn.microsoft.com/en-us/fabric/security/security-overview (opens in a new tab)