Fabric access control has a control plane and a data plane
The DP-700 security objective names workspace- and item-level permissions, row, column, object and file/folder controls, dynamic masking, sensitivity labels, endorsements, audit evidence and OneLake security. These settings are related but they do not all mean the same thing. A workspace role governs what a person can do with Fabric artifacts; it is not a universal statement about every row a downstream system can return. Microsoft’s documentation for OneLake security distinguishes management or control-plane permissions from data-plane access.
Imagine an accounting lakehouse with finance records and a public aggregate table. Engineers need to develop dataflows and monitor data quality; business analysts need to query approved totals; finance controllers can read employee-level or customer-level details. Putting them all in the same workspace does not justify giving them identical data permissions. Security must follow intended purpose, scope and the supported read path.
Create an access matrix first: actor, item, row set, sensitive columns, permitted actions and how an attempted denial will be observed. Without that statement, teams sometimes add a broad Contributor or Member role to solve a query error that came from a data role or misconfigured shortcut.
Workspace and item permissions are different levers
A workspace role may permit creation, editing, sharing or management of items depending on the role and workload. Item-level sharing and permissions can allow a narrower audience to consume a particular lakehouse, warehouse or related artifact. An item can also expose data through supported SQL or OneLake interfaces with their own relevant controls. Review actual effective permissions rather than relying on a role name displayed in a portal screenshot.
For example, an analyst may need query access to a curated warehouse without permission to edit its table definitions or schedule production pipelines. A data engineer may need to manage a notebook while receiving only specific source access. Use the least scope that supports the task and keep powerful production roles restricted to people who are accountable for change and recovery.
When an expected query is denied, identify the engine and identity that evaluated the request. A Fabric UI access failure, a SQL permission failure and a direct OneLake file access failure can have different causes. Broadly granting workspace admin rights may mask the mistake and create new exposure. The workspace configuration material covers the surrounding runtime and ownership design.
Fine-grained data rules depend on which engine reads the data
Row-level security restricts the records available to a principal under the supported access path; column-level security restricts sensitive fields; object-level security can conceal objects; file or folder permissions govern storage-level paths. A security design should specify where those rules are defined and enforced and test a representative query, not assume all engines automatically apply an identical policy. Microsoft continues to expand OneLake security integrations, but preview experiences have their own prerequisites.
In a fictional dataset containing customer IDs and salary information, the finance analyst needs totals while a controller is permitted to inspect individual records for an approved investigation. A row filter can enforce scoped subsets; a protected column can be omitted from a broad role, and a curated aggregate can sometimes be a simpler, safer product. Dynamic data masking changes how some values appear under supported queries; it is not equivalent to encryption or an absolute denial of all inference from correlated fields.
A person who can read raw files through a different authorization path may not be constrained in the same way as a query consumer. Trace the supported execution context, including shortcut behavior, direct file access and credentials. The correct question is what data can a specific identity actually retrieve through the intended interface—not whether a check box exists.
A useful negative test compares direct OneLake access with a read through a supported SQL engine. An analyst allowed to view an aggregated table through one engine should not automatically receive permission to enumerate its backing files and reconstruct restricted columns through an alternate path. If data-plane policies are enforced differently depending on integration support, document the gap and either block the unsupported route or provide a separately curated dataset. Preview features should be tested in the actual tenant before an article labels the outcome guaranteed. Least privilege is an end-to-end property of available access paths.
Security is also temporal. A user who was entitled to a business unit’s data last month may change roles today while a service identity with an old group assignment retains access. Build periodic entitlement review around actual effective grants and resource ownership, not merely the most visible direct role. When revoking access, confirm that existing tokens, shortcuts or cached report experiences follow the expected product behavior. A successful administrative removal is only one piece of proof that the intended data boundary is restored.
OneLake shortcuts carry both convenience and source responsibilities
A shortcut makes existing data available in an approved Fabric path without forcing an independent physical copy in every scenario. Its security depends on shortcut type, backing service, supported credential behavior and the identities that consume it. A seemingly convenient shortcut to an external account does not remove contractual, residency or source-access requirements. Record the physical source owner and whether the source is expected to remain available.
If one table query succeeds but another fails, check both target data permissions and how the shortcut resolves the destination. An incorrect connection identity, expired source credential, or a newly restricted source path can produce failures that are not solved by changing the local item owner. Conversely, a source that permits broad access does not become appropriately restricted simply because the shortcut sits under a carefully named Fabric workspace.
Shortcuts and mirroring decisions affect whether a Fabric consumer references existing source data or maintains a replicated copy. Security review remains necessary in both modes because the copy strategy is not itself an access-control policy.
Sensitivity labels, endorsement and audit evidence play different roles
Sensitivity labels communicate and, in supported experiences, help enforce information-handling requirements. An endorsement such as certification or promotion signals a trust or governance decision about an item; it does not independently guarantee that every record inside is current or that all access paths are secure. Audit logs can show supported activities and changes but do not automatically capture every source event. These are classification, curation and evidence mechanisms, not substitutes for permissions.
In a regulated data product, designate an accountable owner, classify its content, establish who reviews access, and explain the evidence needed for an incident. An endorsed item with outdated tables can still mislead consumers. A labelled dataset with excessive privileges can still be exposed. Neither a label nor an endorsement removes the need for periodic source and access review.
Audit records themselves can include usernames, resource identifiers and sensitive operational context. Limit who can access them and make retention fit actual investigation and compliance needs. When testing, use a harmless approved action and verify the expected audit evidence is produced instead of assuming logging is complete because a toggle says ‘on’.
Design a security test that includes both allowed and denied results
Start from three fictional identities: a platform engineer, a finance analyst and a business stakeholder. The engineer can maintain a pipeline but must not be able to read all restricted finance columns merely because they can modify a notebook. The analyst can query approved rows and see masked or excluded values as designed. The stakeholder can see published aggregates without access to raw source files. State those intended results before touching the permission interface.
Test a successful permitted operation and an intentionally denied operation at the relevant SQL, Fabric item or OneLake interface. Confirm the identity used, effective assignment, query path and observed output. If the test fails, distinguish a missing permission from a wrong source connection or nonexistent table; that distinction avoids granting more privilege than necessary.
When requirements include external sharing, a partner tenant or an unusual consumer engine, check current support and licensing directly. Describe paper scenarios as paper scenarios. A published learning article should never claim real access isolation was verified without authenticated tenant evidence.
Governance is an operating loop, not a one-time security template
People change roles, service principals gain new responsibilities, data products are retired and shared connections drift. Access reviews, item ownership, source permissions and audit investigation should be revisited when those changes occur. A data engineer contributes by maintaining reproducible deployments and observable data boundaries, coordinating with governance owners rather than implying a technical setting provides comprehensive legal compliance.
A good incident exercise traces unexpected finance-row access: identify principal and read engine, review effective rights and audit records, assess the legitimate workflow, revoke or narrow unsafe access, and retest both required and prohibited operations. Preserve evidence before a policy change if an actual incident is under investigation.
The DP-700-ready explanation identifies exactly what is protected, where it is enforced, what happens under a shortcut or alternate query path, and what evidence would demonstrate correct behavior. Understanding these boundaries is more important than memorizing a long table of role names in isolation.