Fabric security is difficult because the same business table may be reached through a workspace, lakehouse, warehouse SQL endpoint, Spark notebook or OneLake shortcut, and those paths do not automatically enforce identical controls. Build an access matrix for an engineer, a report reader and a denied contractor. Specify workspace/item permissions, relevant OneLake security roles, SQL or semantic-model protections and the source authorization used by a shortcut. Test a permitted query and a request for a restricted row using the caller’s actual identity, then change group membership and test again to expose stale access. In third-party DP-700 Fabric-security practice cases, a defensible answer identifies the effective principal, policy enforcement point and denial evidence for each data path—not just a workspace role name. Test that explanation against the actual Fabric configuration before treating the proposed access design as secure.

Take a fictional healthcare supplier that stores shipment totals alongside restricted customer contracts. The data engineer prepares public product statistics and regional customer records. Operations needs aggregate counts, but only an approved contract-review team can inspect identified client transactions. A report that hides the client-name column while allowing the user to download unrestricted underlying files is not protected; the security design must follow the full access path.

Separate the control plane from the data plane

Microsoft’s OneLake data security overview distinguishes control-plane permissions from data-plane access. Workspace roles and item-sharing permissions determine which artifacts a principal can manage or open. OneLake security roles can scope the data that a principal can access at table, folder, row or column levels where supported. These decisions interact, but they are not equivalent and should not be described as interchangeable ‘Fabric access.’

A contributor on a development workspace can be authorized to build a pipeline; that does not imply the account should read every production shipment contract. Conversely, a reporting user can require a specific curated table but no permission to alter notebooks or deployment rules. Begin each security review with a matrix containing principal, operation, workspace/item boundary, underlying data scope and reason for access. Then design roles to that matrix rather than grant a broad role and hope downstream filters will compensate.

For the supplier example, use two test identities: a data steward with a governed read path to identified records, and an analytics consumer restricted to anonymized or aggregate values. Validate both an expected successful read and a deliberately denied read. The negative case matters because an aggregate chart can look correct even when raw files are accessible through another engine.

Choose workspace roles and item access deliberately

Workspace roles primarily support administration and collaboration. Item permissions are useful when a person needs a narrower supported artifact than the entire workspace. Review the scope of read, build, share or write operations in the actual item type rather than assume permission inheritance is identical for notebooks, warehouses, lakehouses and semantic models. A role that supports editing an item may be wider than a production reader should receive.

Avoid using a shared workspace administrator identity to execute all pipelines. An automation identity should have just the permissions needed for its destinations and its run operations. If it writes silver Delta tables, do not casually grant it unrestricted management of all workspaces or a role that permits changing tenant security settings. Document any temporary elevated permissions separately, including their owner, expiry and audit evidence.

Treat deployment as a security change as well as an artifact update. When a test workspace is promoted, inspect permissions and connected credentials in the target; a deployment pipeline cannot prove least privilege merely because the item successfully appears. If the source target or shortcut points to a production directory under an unexpectedly broad identity, a technically successful deployment may create a new data-exposure path.

Use OneLake security roles for supported granular access

OneLake security roles let administrators define access at supported table and folder scopes. Microsoft’s role management documentation describes how to create and assign roles and supported row- or column-level restrictions. Implementation support varies by item type, engine and capability; verify the current product matrix instead of treating a lakehouse table, mirrored catalog and data warehouse as if they share every setting.

For synthetic contracts, create an authorized regional table reader whose scope includes only a designated region and excludes a confidential note column where the selected feature supports that policy. Validate what happens when the same user queries through a supported Fabric engine. The policy should apply to the intended direct data access path rather than only to a front-end report. Keep a test record that belongs to a forbidden region and assert that it does not appear. Before calling the restriction effective, also inspect the DefaultReader role and any other broad grants that could restore access through a different role.

A row-level policy protects a different dimension than an object grant. A user may be allowed to read a table but only a subset of its records. Column-level access addresses sensitive attributes such as a customer address. A folder-level boundary can prevent a principal from navigating raw documents that are never intended for reporting. Choose these controls from a real classification and user task, not from a desire to enable every security feature at once.

Know what happens when a query engine cannot enforce a policy

OneLake’s authorized engine model is in preview. A registered engine uses a dedicated Microsoft Entra identity to read underlying files and policy metadata, but must enforce the requesting user’s effective table, row and column permissions when processing a query. An engine unable to enforce a required row- or column-level restriction can be blocked rather than allowed to return unfiltered data. An empty or denied result from such an engine is not proof the user lacks all access everywhere; it may be a capability boundary.

This affects design and testing. A policy that works through one Fabric query experience should not be copied as a universal statement about all SQL, Spark, shortcut or external application paths. Maintain a matrix of item type, engine, security feature, supported status and test result. Include a route that is expected to fail safely, and label preview integrations and limitations accurately. A secure architecture may choose a different engine rather than weaken the policy to make an unsupported tool work.

An app running outside Fabric also needs an authenticated path. Its network connectivity, Entra identity and authorized engine capabilities may differ from an interactive Fabric user. Do not place unrestricted credentials in code to solve a policy denial. If the engine cannot enforce the granular policy the business requires, redesign that access path or use a supported controlled service boundary.

Protect shortcuts without overlooking the source

OneLake shortcuts can reference data from another item or external storage without copying every file. The engineering benefit is access to an existing source, but the trust boundary does not disappear. The source has its own ownership, credentials, freshness and permissions, while the consuming item can have a different workspace and audience. Test what the consuming reader is allowed to see and which identity authorizes the shortcut target.

A data team might make a shortcut to a supplier’s restricted contract export in a broad reporting workspace. If everyone with workspace access can now reach the raw export under a shared identity, the ‘one copy’ pattern has increased exposure. A better pattern may expose a curated Delta table or governed serving item whose data classification matches the consumer. A shortcut is a storage reference, not an authorization policy or a data-quality certification.

OneLake shortcuts and mirroring create different data-freshness and source-ownership patterns. Their security requirements must be tested independently: a shortcut may reference a source whose identity and permissions are governed elsewhere, while a mirrored representation has a different synchronization and consuming-engine path. In an access-revocation exercise, remove an approved reader from the source and examine what each consuming engine can still retrieve. A successful SQL query, notebook run or semantic-model response is not proof that every access path enforces the intended boundary.

Distinguish semantic, SQL and storage protections

Fabric security layers interact without becoming interchangeable. A semantic model can apply row-level or object-level restrictions for its audience, while an independent lakehouse, shortcut or SQL connection may use different permissions. Understanding Fabric security layers helps distinguish those query and storage surfaces; a DP-700 engineer must also account for the identities performing ingestion, intermediate staging, orchestration and publishing. Test a reporting reader’s permitted view and a denied direct data-path query with the actual consuming identity, not only a privileged workspace owner.

Keep restricted raw data in a location where the consuming report audience cannot simply bypass the curated serving layer. For example, the reporting team may need regional totals but never the original contract PDFs. Build a secure source-to-curation flow and assign export rights only where justified. Test both the report view and the storage/SQL routes available to the same identity rather than assuming a secure front end proves the back end secure.

Sensitive data may also leak through notebook outputs, job parameters, diagnostic logs and the intermediate tables created during a transformation. Limit retention and who can inspect execution artifacts. A technically correct data permission is insufficient when an unrestricted operational log contains the complete payload. Favor source IDs, status and protected trace references over copying confidential fields into general monitoring.

Apply labels, endorsement and audit without confusing their jobs

Sensitivity labels communicate and enforce supported information-protection handling rules; endorsement helps users understand which artifacts are promoted or certified by the organization. They have different functions from OneLake data-role grants. Labeling an item ‘confidential’ does not grant or revoke a user’s ability to run a data query on every engine, and endorsing a dataset does not certify that its source permissions are safe.

Define an owner for each protected data asset, ensure classification is consistent across raw and curated layers, and maintain an auditable record of who changed an access policy or shared an artifact. The DP-700 guide includes Fabric audit logs in the management domain. The purpose is to reconstruct the decision and change, not merely to report a count of users with access.

Test a controlled revocation. Remove an allowed test group from the data security role, observe the result through the intended engine and review the expected audit evidence. Cache behavior and propagation can vary, so do not assert instant revocation everywhere without a verified runtime measurement. Record the actual time to effective denial and the response path for high-impact access changes.

Design a permission regression lab

Use synthetic tables containing regional shipment counts, fictitious contract names and a controlled restricted note. Build an explicit principal-to-operation matrix before configuring any grants. Test a steward, a developer, a report consumer and an unauthorized user against workspace item actions, OneLake tables and a shortcut where supported. State the expected result for each operation and capture actual evidence only when the environment permits execution.

Include failure injections: accidentally broaden a workspace role in test, remove a OneLake role membership, point a shortcut at a different source and query through an unsupported engine. Observe whether access is correctly denied and whether audit data lets an operator identify the changed boundary. Restore the original configuration and retest. A release must block if a forbidden identity can read restricted content even when aggregate dashboards work correctly.

A governed Fabric solution is not simply a set of green permission indicators. It is a verifiable chain from trusted identity through workspace, item, storage, query engine, pipeline and output. For DP-700, the durable skill is explaining where each boundary is enforced, what an exception means, and why a denial or retrieval result is safe for the real workload.