Security in Microsoft Fabric is not one permission screen. A DP-700 data engineer has to reason across workspace access, item permissions, data-level controls, OneLake security, labels, endorsements, audit logs, and the operational boundaries between development and production. The challenge is to give people and services enough access to do their work without making the analytical estate broadly permissive.<\/p>\n
The most useful security design starts with ownership and data sensitivity, not with assigning roles after the solution is built.<\/p>\n
Workspaces group Fabric items, but they also establish an important administration boundary. Teams should decide whether a workspace represents an environment, domain, product, or another ownership model and then apply that convention consistently.<\/p>\n
Mixing unrelated teams and data in one workspace creates broad access and unclear ownership. Splitting every small artifact into a separate workspace creates administrative overhead. The right design balances isolation, lifecycle, collaboration, and support responsibility.<\/p>\n
The Microsoft DP-700<\/a> target covers this configuration layer because workspace design influences both security and deployment.<\/p>\n Workspace roles grant capabilities across the workspace, while item-level permissions can narrow or extend access to specific artifacts. Use the broadest level only when the user\u2019s job actually requires it. A report consumer, pipeline operator, and engineer developing notebooks do not need identical rights.<\/p>\n Role design should follow tasks. Give engineers the rights needed to build and troubleshoot in development, restrict production changes to controlled paths, and separate administrative functions where risk justifies it.<\/p>\n The principle is similar to role-based access control<\/a> generally: permissions should map to responsibilities rather than convenience.<\/p>\n Sometimes two users can access the same analytical item but should not see the same data. Row-level security can restrict records by user or role, while column- or object-level controls can protect sensitive attributes or structures. Folder and file controls matter when OneLake data is exposed through file-oriented access.<\/p>\n The choice depends on the consumer path. A semantic consumer, SQL user, Spark notebook, and file reader can interact with data differently, so a security design must consider the interfaces that actually expose the information.<\/p>\n A policy that is correct for one access path can be incomplete if another path bypasses it. DP-700 scenarios often reward candidates who think about the full data route rather than one UI.<\/p>\n OneLake provides the common storage foundation for Fabric, which makes consistent storage access especially important. The organization should define who can read or write particular data, how shortcuts inherit or intersect with source permissions, and how shared data products are exposed without granting unnecessary workspace control.<\/p>\n OneLake shortcuts<\/a> can reduce data copies, but they do not reduce the need to understand ownership. If a downstream team accesses data through a shortcut, the source owner still controls schema and lifecycle, and the security model must remain clear across that relationship.<\/p>\n Documenting these cross-domain dependencies prevents surprise when source policies change.<\/p>\n Dynamic data masking can reduce exposure of sensitive values in supported query scenarios, but masking is not the same as authorization. A user who should never access a sensitive field needs appropriate access controls, not only a display transformation.<\/p>\n Sensitivity labels communicate classification and can support governance processes across analytical assets. They help users and administrators understand whether data is public, internal, confidential, or governed under a stronger policy.<\/p>\n Security controls work best in layers: classification explains sensitivity, permissions limit access, masking can reduce casual exposure, and audit logs provide evidence of activity.<\/p>\n Endorsement helps consumers identify promoted or certified analytical items. It is a quality and governance signal, not a security grant. A certified data product can still contain confidential information and require strict access.<\/p>\n This distinction matters because organizations often combine discoverability, governance, and security in the same catalog experience. The controls serve different questions: \u201cCan I find this?\u201d, \u201cShould I trust it?\u201d, and \u201cAm I allowed to use it?\u201d are not the same.<\/p>\nApply least privilege at workspace and item level<\/h2>\n
Protect data with row, column, object, and file-level controls<\/h2>\n
Use OneLake security deliberately<\/h2>\n
Use masking and labels for different security problems<\/h2>\n
Endorse trusted data without confusing trust with access<\/h2>\n