Security and Governance in Fabric

Microsoft Fabric security is easiest to understand when management permissions and data access are separated. A user may be able to see or manage a Fabric item without automatically receiving unrestricted access to the underlying OneLake data. Conversely, data access can be scoped more narrowly than the collaborative permissions of a workspace.

For candidates preparing for DP-600, that distinction matters because analytics engineering now includes securing and governing semantic models, lakehouses, warehouses, and other Fabric assets. Current Microsoft guidance describes control-plane permissions through workspaces and items, while OneLake security provides data-plane access down to objects, rows, and columns where supported.

A mature Fabric design therefore answers two questions separately: what may this identity do to the item, and which data may this identity read or change? Security becomes much easier to reason about once those planes are not mixed together.

Workspace roles control broad management capability

Fabric workspaces use roles such as Admin, Member, Contributor, and Viewer to define what users can do across the workspace. Higher roles can create and modify items, while Viewer is intended for consumption rather than item management.

Assign workspace roles to groups instead of individual users where practical. This makes access easier to review and aligns permissions with job responsibility rather than one-off exceptions.

The Fabric Analytics Engineer Associate certification is built around operating analytics solutions, so candidates should understand the difference between being able to edit an item and being able to query every row of its data.

Item permissions narrow access without adding a user to the whole workspace

Fabric items can be shared directly. Item-level permissions let a user see or work with a specific lakehouse, warehouse, report, semantic model, or other item without receiving equivalent permissions to unrelated items in the workspace.

Read permission exposes item metadata but does not automatically mean unrestricted access to every underlying data path. Additional permissions can be required depending on the item, endpoint, and access method.

This pattern is useful when consumers need one product rather than broad workspace membership. It also reduces the temptation to use Contributor access merely because someone needs to view a report or query a dataset.

OneLake security is the data-plane control

Microsoft’s current OneLake security model provides role-based access to data stored in supported Fabric items. Roles can grant Read or ReadWrite permissions and can scope access to tables, folders, schemas, rows, or columns depending on the item and feature support.

OneLake security uses a grant model. That means administrators should understand how multiple grants combine and should not assume that one restrictive role can deny access already granted through another role or permission model.

The broader Microsoft certifications separate analytics, data engineering, security, and administration, but Fabric governance requires those disciplines to meet at the data-access layer.

Row and column controls should reflect business policy

Whole-table access is often too broad. A regional analyst may need only rows for one geography, while a support team may need most columns except a sensitive identifier. Row-level and column-level security express those requirements closer to the data.

Start from policy language. “Managers may see only their region” is a row problem. “Analysts may not see salary” is a column problem. The control becomes easier to validate when the business requirement is explicit.

The DP-600 Fabric solution perspective is useful because security should be designed alongside the semantic model and data product, not applied after consumers already depend on broad access.

Microsoft Entra ID is the identity foundation

Fabric authenticates users and nonuser identities through Microsoft Entra ID. Governance therefore depends on healthy identity lifecycle, security groups, service principals or managed identities where supported, and least-privilege assignment.

Use groups for human roles, separate workload identities from personal user accounts, and avoid production pipelines that fail when the original author leaves the organization.

Identity design also affects sharing and cross-tenant scenarios. External collaboration should be deliberate, with ownership and review rather than assuming a link is sufficient governance.

Purview adds information-protection and governance context

Microsoft Purview capabilities can bring sensitivity labels, information protection, cataloging, lineage, data-loss-prevention, audit, and governance signals into the broader Fabric environment depending on licensing and feature support.

Labels and protection policies can affect who retains access to sensitive Fabric items. Governance teams should define the policy while Fabric administrators and data owners understand the operational effect on users and downstream workloads.

The current OneLake catalog Secure experience also centralizes visibility into workspace roles and OneLake security roles, which helps move governance from scattered configuration toward reviewable access state.

Shortcuts preserve source-side security responsibilities

OneLake shortcuts can reference data without copying it. That is powerful for data sharing and reuse, but it does not mean security disappears at the shortcut boundary. Access to the source and the consuming experience still needs to be designed deliberately.

Document who owns the source, which identity is used to access it, what downstream users can see, and how permissions change if the source moves or the sharing relationship ends.

The adjacent DP-700 data-engineering exam is relevant because data pipelines and shortcuts rely on governed access just as analytics models do.

Audit and lineage make access governable

Security controls are difficult to operate without evidence. Audit logs can show important access and administrative activity, while lineage can reveal which downstream models, reports, or tables depend on a source.

Use lineage before changing a sensitive table or permission. A field that appears unused in one lakehouse may feed multiple semantic models or reports. Impact analysis is part of governance because it prevents a local change from creating an uncontrolled downstream failure.

Monitoring should also identify privileged changes, new sharing relationships, and unexpected access patterns where the platform supports them.

Fabric governance works when access, ownership, and data products align

For every important Fabric item, identify owner, workspace role model, item-sharing model, OneLake data permissions, sensitivity, workload identities, downstream consumers, and audit requirements. Those decisions form the operating contract around the data product.

The DP-800 exam is another adjacent Microsoft data credential, but DP-600 candidates should remain focused on the analytics engineering responsibility: building semantic and analytical solutions that can be shared without losing control of the underlying data.

Security and governance are strongest when users receive the least access required at the correct plane, data protections remain consistent across engines, and every permission can be explained by ownership and business need.

Semantic-model security adds another layer above raw data access. Power BI row-level security, object-level security, build permissions, and report sharing can shape what consumers see even when the underlying Fabric item has broader data permissions. Architects should document which layer enforces each rule so that a future model change does not accidentally bypass the intended restriction.

Deployment pipelines and CI/CD also need governed identities. Production workspaces should not rely on the personal permissions of the analyst who first built the solution. Use appropriate service identities, separate development and production roles, and review who can promote changes. A secure data product can still be compromised through an overprivileged deployment path.

Sensitivity and sharing should be tested together. If an item carries a high-sensitivity label, verify how sharing, exports, downstream reports, and protection policies behave for users who are not in the intended audience. Governance is strongest when the classification changes actual access or handling behavior instead of existing only as metadata.

Fabric capacity and workspace administration can also create separation-of-duties questions. The person who owns platform capacity does not necessarily need access to every sensitive dataset. Likewise, a data owner may need to manage permissions without controlling the entire tenant. Assign roles according to operational responsibility rather than convenience.

For final practice, create a permission matrix for one lakehouse and one semantic model. Include workspace Admin, Member, Contributor, Viewer, item-only user, data engineer service identity, report consumer, and external collaborator. Record what each principal can manage and which data they can see. If the answers are unclear, the governance model is too implicit.

Workspace design itself can support governance. Separating development, test, and production workspaces limits who can modify production artifacts and makes deployment responsibility clearer. Sensitive business domains may also deserve their own workspaces or security groups when ownership and access differ materially.

Direct Lake and SQL endpoints create another reason to understand permission layers. A user may consume a Power BI report successfully while lacking permission to query the underlying OneLake tables directly, or a SQL endpoint may apply its own compute-level permissions. Document the intended consumption path so administrators do not “fix” a legitimate denial by granting unnecessarily broad data access.

For final DP-600 practice, take one report and trace its full security path: user identity, report access, semantic-model security, item permission, OneLake or SQL data access, sensitivity label, and audit evidence. If every layer has a clear owner and purpose, the governance design is likely coherent.

Governance is strongest when access can be explained quickly during an audit or incident: who granted it, why it exists, which data it reaches, and how it can be removed without breaking unrelated consumers.

• Category: All Certifications Certifications