DP-600 Fabric Security: Permission Without Exposure

A report that shows only the right figures can still sit on top of an unsafe data platform. A regional manager may see a carefully filtered dashboard while an overly broad workspace role gives the same person access to underlying tables. Another user may be blocked from a report despite having permission to query its source. In Microsoft Fabric, the answer is rarely a single checkbox labeled “secure.” Authorization is distributed across workspaces, items, data, connections, and semantic models. Understanding those boundaries is an important part of the DP-600 exam.

Consider a healthcare analytics team combining appointment, billing, and staffing information. Analysts need to build aggregate trends, managers need departmental results, and patients’ identifiable data must not become available simply because someone can edit a report. The design must support useful analytics without expanding access as data moves from a lakehouse to a model and eventually into visualizations.

First identify who can reach each layer

Start with a simple access-path diagram. Who can read the source lakehouse? Who can query a warehouse or SQL analytics endpoint? Who can edit the semantic model? Who can only view a published report? A user’s effective access can result from direct item permissions, workspace membership, data permissions, and the identity used by a connection. Granting a broad workspace role for convenience may give a developer far more capabilities than are needed for their task.

Build role descriptions around work rather than job titles alone. A transformation engineer may need permission to create notebooks and write curated tables in a development workspace. A department manager may need only consumption rights to a certified model in production. An auditor might require read-only evidence of changes without being able to alter a pipeline. The principle of role-based access control is useful here: permissions should reflect the actions people are authorized to perform, and assignments should be reviewed when responsibilities change.

Distinguish workspace, item, and underlying data permissions

Workspace roles govern collaboration and administrative capabilities at a workspace boundary. Item-level permissions can control access to specific Fabric artifacts. The underlying data may have separate rules, including OneLake security or SQL-based access where those mechanisms apply. A semantic model also has its own permissions and potential row- or object-level rules. These layers can complement one another, but their effects should not be assumed to be identical. A user who can create a report from a model does not necessarily need access to its source storage.

In the healthcare example, place transformation assets in an engineering workspace and publish approved analytical models to a consumption workspace. Grant report consumers the least scope necessary. Then test whether a supposedly restricted consumer can discover an underlying lakehouse, open a SQL query surface, build a new report from the model, or export rows. The ability to use an interface does not prove authorization is correctly contained. The point is to verify actual access paths rather than infer security from a workspace’s descriptive name.

Apply row and object restrictions at the correct boundary

Row-level security limits which records an identity may see. Object-level security can restrict exposure of tables or columns in a semantic model, while OneLake security offers controls over data accessed through supported compute paths. Column-level and file-level permissions address other forms of exposure. Decide which boundary is authoritative for each sensitive field. A semantic-model filter can be appropriate for report-only consumers, but it does not secure a lakehouse against a person who has separate direct access to that lakehouse.

A manager who leads only the eastern region may need claims totals filtered by permitted department. Do not trust a manually selected visual filter as an access mechanism; a consumer can sometimes change report interactions or create additional visualizations. Security policies should be enforced by a mechanism that applies to the intended access surface. Validate with real representative identities and adverse scenarios. For example, what happens if the manager belongs to two security groups, or if a report is shared into a second workspace? Those are tests of policy semantics, not just of layout.

Security-test matrices reveal errors that a single administrator account cannot show. Make rows for identities such as contributor, viewer, report consumer, and unaffiliated employee. Make columns for actions such as opening a report, creating a new report from the model, reading a source table, changing a pipeline, and exporting detail records. The intended allow-or-deny result becomes a visible policy statement. Execute the checks after a connection change or a workspace-role update and compare them with the approved matrix. A permissions audit is strongest when it tests both legitimate use and denied actions.

This exercise also identifies excessive concentration of privilege. If every analyst receives Contributor rights merely to inspect data, the intended semantic-model RLS boundary may not apply to them in the way it applies to Viewers. Revisit the design: can a read-oriented item permission or a governed shared model meet their task? Least privilege is not just about reducing the number of people with access; it also means granting the right kind of access to the right layer.

Understand Direct Lake identity and fallback behavior

Direct Lake introduces a particularly important design question: whose identity is used when the semantic model accesses data? Single sign-on and fixed-identity connections can create different permission behavior. If users authenticate directly to the source, their source rights matter; if a managed connection uses a fixed identity, the model may become the primary boundary for consumers. That choice requires deliberate authorization and a clear understanding of who can bypass the model by accessing underlying data elsewhere.

There is also a technical contrast between using Direct Lake directly over OneLake storage and using a model that accesses SQL analytics endpoints. The former does not use DirectQuery fallback, while the latter may fall back for certain security or query conditions. Depending on the chosen configuration, a restricted SQL endpoint view may produce a slower query path or an error instead of an expected Direct Lake result. A DP-600 candidate should not memorize “Direct Lake bypasses refresh” and stop there. Test whether the security model and storage mode deliver correct results with the actual consumer identity under realistic capacity conditions.

Govern discoverability, sensitivity, and endorsement

Security involves more than the mechanics of a permission check. Analysts need to find the right sanctioned model and understand whether its contents are safe to distribute. Sensitivity labels communicate handling expectations, while endorsement can signal a trusted or promoted analytical asset. Neither feature replaces the underlying authorization mechanism. A confidential model with an endorsement badge is still unsafe if a broad group can access unfiltered records through an unintended route.

Metadata and lineage also help governance. People should know who owns an approved metric, which upstream tables it depends on, and what happens if those sources are retired or renamed. For the healthcare example, a model named “appointment efficiency” should document whether cancelled appointments are included, when data is refreshed, and which aggregated fields may be shared outside the clinical team. These descriptive controls reduce accidental misuse; enforced permissions address deliberate or accidental exposure through technical pathways. Good governance requires both.

Treat development and deployment as security events

A development workspace often contains test data and experimentation that should not leak into production. Separate environments, source-controlled definitions, change reviews, and deployment pipelines can reduce that risk, but promoting an artifact does not automatically replicate every source identity or permission exactly as intended. A new connection might point to the wrong dataset, or a model deployed successfully might use a credential with wider source access. Add a security check to release criteria rather than assuming the deployment tool has solved the problem.

Define test identities and expected results. A developer should verify the full model in a development environment, a department viewer should see only authorized records after deployment, and an unaffiliated user should be denied access. Review changes to workspace membership, sharing settings, connection identities, and security roles alongside code changes. A release that preserves financial totals but grants an unintended group access to personal data has failed just as surely as one that corrupts the calculations.

Investigate authorization failures systematically

When a report fails with an access error, the worst reaction is to give the requester an administrator role until it loads. Instead, trace the request. Can the user open the report? Do they have permission to query its semantic model? Is the connection using their identity or a fixed identity? Can that effective identity read the Delta tables, shortcut targets, or SQL source involved? Does a row restriction remove every record, making the report appear empty rather than blocked? Each observation narrows the problem.

Consider two apparently identical failures. One manager sees an empty table because the department key used by the security rule is missing from the user mapping; another receives an authorization error because the Direct Lake model accesses an external shortcut whose target denies the effective identity. Adding a workspace role could mask the second issue while leaving the first unresolved and creating new exposure. Diagnose the specific permission boundary, make the smallest justified change, and rerun both positive and negative access tests.

Document which team owns each authorization decision. Identity administrators may own group membership, data owners may approve access to patient or financial records, and platform engineers may configure the corresponding Fabric permissions. If access requests arrive only as “make the report work,” one person can accidentally combine approval and implementation without enough oversight. A lightweight approval record should identify the dataset, purpose, scope, recipient, and expected duration. When access is no longer needed, that same record makes revocation easier to justify and verify.

Prove security from the least-privileged account

Build a miniature analytics solution with a staff fact table, department dimension, and a financial measure. Create one role that can develop the data assets and another that can view only a restricted analytical result. Publish the model through a controlled path. Now attempt every consumption route available to the viewer: report interaction, export, new report creation where permitted, and direct source access. Document the outcomes. If an action should be denied, verify denial explicitly rather than interpreting the absence of a button as proof.

The goal for DP-600 is to understand how governed analytics remains useful. Security that blocks every legitimate user is not a successful product; convenience that quietly broadens rights is not a successful control. A robust design has documented ownership, understandable data lineage, tested identities, and explicit boundaries between creating, managing, and consuming an analytical asset. When access goes wrong, the engineer can explain precisely where the policy is enforced and how to correct it without trading confidentiality for a working report.