Microsoft DP-700: OneLake Security and Shortcut Access Lab

A Fabric data engineer can build a technically correct lakehouse and still expose sensitive data by granting the wrong permission. In Microsoft’s DP-700 exam, security is part of implementing and managing the analytics solution. That means choosing the right control boundary—not assuming that assigning someone a Viewer label or creating a OneLake shortcut automatically makes the dataset private.

This lab follows a fictional retailer with sales records from several regions. Analysts need the aggregated metrics for their business unit, a data engineer needs to maintain the source pipeline, and a finance auditor has narrower access to raw invoice details. The retailer also references one dataset stored outside its lakehouse through a shortcut. Each case tests a different type of permission. A useful implementation must permit legitimate analysis while proving that unrelated rows and confidential columns remain unavailable.

The broader Fabric workspace and data-security concepts remain a useful starting point. Here the focus is more specific: which identity reaches which path through which engine, how shortcut authentication changes the access check, and how to troubleshoot a denied or unexpectedly permitted result without giving everyone Administrator rights.

Map permissions before creating the first role

Microsoft Fabric applies permissions at several scopes: the workspace, the item, the OneLake folder/table path and sometimes the query-engine or semantic-model layer. These scopes serve different purposes. Workspace Admin, Member and Contributor roles support relatively broad operational work. Giving one to a person who only needs a particular table can inadvertently grant more visibility than a narrow OneLake data-security role appears to allow.

OneLake security roles can grant read access to specific tables and folders, and can include row-level security (RLS) and column-level security (CLS) for eligible tables. These granular roles are especially useful for Viewer or item-Read users. They do not act as a general-purpose deny rule overriding broad privileges a user already received by being a workspace Admin, Member or Contributor. The data access model is grant-based; conflicting grants must be understood before concluding that a narrow role protects every principal.

The practical test should therefore use the actual requesting identity. An administrator’s successful query does not prove that a Viewer cannot access the same data. Create approved test groups representing an analyst, an engineering operator and an auditor, and document exactly which tables and columns each one should see. Use synthetic data and avoid giving the test users real access to production sales or personal information.

Build the smallest meaningful access test

Imagine a Delta table named Sales containing a region, order identifier, amount and internal margin field. An analyst assigned to West should see West rows but not East rows, and should not see internal margins. Use the OneLake roles and supported security controls for the item and table. Write down the expected result before configuring the rules so you can recognize when a policy is only superficially correct.

A row-level restriction can allow a subset of records based on a supported predicate. Column-level restriction limits the columns available to a role. Microsoft supports applying RLS and CLS together within one OneLake security role. Combining a role with RLS and a separate role with CLS for the same table is unsupported and may cause query errors. Separately, the effective access of multiple grant roles can be broader than intended, so inspect all assignments before trusting a restriction. For example, when OneLake CLS governs a query that requests all columns, Spark returns only the permitted columns, whereas SQL analytics endpoints enforcing OneLake security in user identity mode and semantic models can reject requests for restricted columns. SQL analytics endpoints in delegated identity mode instead use SQL-native permissions and filtering, so test that mode separately.

These are not merely user-interface curiosities. An application’s error may indicate that the intended security rule is being enforced, not that the dataset is corrupted. A candidate who responds by granting workspace Contributor to make an unauthorized SQL query succeed would be fixing the symptom by removing the control. Instead, determine what result the principal is permitted to receive and adjust the query or role appropriately.

Do not assume that every table format is eligible for the same RLS and CLS behavior. The current Fabric documentation describes support for Delta Parquet and selected virtualized Iceberg table paths, with limitations for other formats and unsupported engine combinations. Verify the exact item type and current support when designing the lab. A security role that contains syntactically invalid references can cause a query failure or no rows, so test both a valid positive and a denied negative case.

Shortcuts are pointers, not permission shortcuts

OneLake shortcuts let Fabric reference data that resides elsewhere in OneLake or in supported external systems without necessarily copying it into the local lakehouse. This can reduce redundant storage and simplify access, but the security analysis becomes more nuanced. The data still has a source owner and a target system; the path visible in a consuming lakehouse is not automatically the authoritative permission store.

Microsoft describes two authentication patterns for shortcuts: identity passthrough and delegated. Same-tenant OneLake-to-OneLake shortcuts use passthrough by default and can use a delegated connection when configured. Cross-tenant OneLake shortcuts and external shortcuts rely on delegated credentials or a configured identity under their supported model. That distinction decides whose credentials the target system sees.

Under passthrough, the calling user’s identity is presented at the target. The user cannot simply read another team’s table because the shortcut points to it; the target must authorize that user, and the consumer-side security also matters. Under delegated access, the connection uses an approved service identity or credential. A consumer can see the intersection of their consumer-path permissions and what that configured identity is authorized to reach, subject to the documented shortcut and engine exceptions.

For example, suppose the retailer’s Finance team publishes an authorized OneLake table but permits only the Finance service identity to read it. The Engineering workspace creates a delegated shortcut using that identity. The engineer must still configure appropriate OneLake consumer roles: otherwise an overly broad workspace grant can expose records that Finance did not intend ordinary analysts to inspect. A connection credential is not a substitute for a consumer-facing authorization policy.

Walk through the four shortcut questions

Before creating a shortcut in an authorized test workspace, answer four questions. First, what is the source system and item path? Second, which account or identity authenticates to that source? Third, what permission is required to create and read the shortcut within the consuming item? Fourth, which Fabric engines and identities will access the resulting data? A shortcut that is visible in the explorer does not establish that every operation over its target will succeed.

Creating a shortcut generally requires write access on the consumer item or the relevant OneLake path and authorized read access to the target under the applicable supported model. Querying the shortcut involves the rights of the requesting user and, for delegated flows, of the configured connection identity. When a third-party source such as Amazon S3 or Azure Data Lake Storage is involved, source-specific permissions and connector support may add another layer.

Test a small file or table. First, access it as the authorized engineering identity. Then try as a consumer with only the intended Read permissions. The engineer’s success and the consumer’s failure can both be correct outcomes. Compare the shortcut’s item/path permissions with the target or connection rights before deciding where to change configuration.

Finally, perform a negative test with a user who must not see the restricted financial data. If that user succeeds, inspect inherited item grants, workspace membership, OneLake roles and delegated shortcut permissions. If access fails for a legitimate analyst, inspect whether the source credential has expired, the shortcut target has moved or the appropriate permission has not been granted.

Understand the identity and query-engine exceptions

OneLake shortcuts and SQL analytics endpoints have two distinct identity decisions. A delegated shortcut authenticates to its target with a configured identity and can apply appropriate OneLake security to access through its consumer shortcut path. However, a SQL analytics endpoint configured in delegated identity mode does not enforce end-user OneLake security roles at the SQL table layer: SQL-native GRANT/REVOKE, RLS, CLS or data masking must supply filtering, or the endpoint must run in user identity mode. Do not confuse shortcut credential delegation with the SQL endpoint’s query-security mode.

Microsoft also documents a specific failure path: when a delegated-mode SQL analytics endpoint queries a shortcut whose source table has OneLake row-, column- or object-level security policies, the endpoint blocks access rather than silently passing the owner’s privileges through. Where OneLake filtering is required, configure the consumer SQL endpoint in user identity mode and verify the original access roles; granting broader SQL rights does not solve a source-policy conflict. This is distinct from the delegated shortcut’s configured connection credentials.

Likewise, the current OneLake documentation calls out special behavior when CLS and RLS are combined across producer and consumer sides of a delegated shortcut. It is more accurate to describe the tested effective permission path than to claim a universal behavior for every possible engine and table type. In an exam scenario, distinguish identity passthrough, delegated target access and the security role used to filter what the consumer actually sees.

Keep an evidence table for each client: identity, workspace/item role, OneLake role, shortcut authentication mode, source credential or target role, chosen engine and observed result. This turns what appears to be an arbitrary 403 or forbidden-table message into a structured investigation. The question is not merely whether one user could read a table; it is whether the architecture enforced the intended policy for every relevant access path.

A case study: the analyst sees too much

The fictional retailer creates a new workspace for regional analytics. An administrator shares a lakehouse and creates a OneLake role intended to restrict West analysts to West orders. Testing with an administrative session shows every region, while a normal Viewer sees only West. Is the role broken? Not necessarily. The administrator’s broad workspace authority may legitimately bypass restrictions aimed at lower-privilege consumers.

Now suppose a West analyst was mistakenly added as a Member to resolve an unrelated pipeline-edit permission. The analyst gains broader visibility than before. The real problem may be that a convenience workspace role expanded the user’s authority. Fixing it by adding another restrictive OneLake role may not remove the existing broad grant. Review whether the analyst needs the Member role at all and replace it with appropriately scoped item/data permissions.

At the same time, a delegated shortcut may use a connection identity with broad source access. Evaluate the consumer’s shortcut-path privileges, any OneLake security restrictions and the actual query engine; for a SQL analytics endpoint in delegated identity mode, review its separate SQL security policies rather than assuming OneLake roles will filter the result. Make sure a broad workspace grant or an unfiltered delegated SQL endpoint does not defeat the intended boundary. Separating the two problems—broad workspace privilege and delegated target credential—leads to a much safer remediation than blindly disabling every shortcut.

Translate the lab into DP-700 reasoning

The best DP-700 preparation is not learning the names of five security settings. It is being able to predict the outcome for the real querying identity, understand where permission is evaluated and test the correct positive and negative behaviors. Security is part of implementing a functioning analytics solution; a “fix” that gives everyone broad access undermines the solution even if all queries turn green.

This lab intentionally uses documented concepts and fictional identities rather than claiming that its cases were executed in a live customer’s Fabric environment. Current OneLake security support, identity delegation details and engine behavior should always be checked against Microsoft’s latest documentation before a production change or exam attempt after the announced October 19, 2026 update.