Microsoft Fabric brings analytical workloads onto OneLake, but shared storage does not mean that every workspace member should see every row. DP-700 expects a data engineer to know which control protects an item, which control protects the data in that item, and which identity is used when a notebook, shortcut or SQL consumer reads it. Confusing these boundaries is one of the fastest ways to grant too much access while thinking a report filter has solved the problem.<\/p>\n
Consider a single lakehouse holding orders, customer addresses and a sensitive Workspace roles determine what a member can generally do in a workspace, including how they interact with items. Item permissions can grant access to a specific lakehouse, warehouse or other artifact without opening all neighboring workloads. OneLake security roles then define access to data scopes such as tables, folders, rows and columns, where supported. Keep these separate in your permission matrix. A user who can open a lakehouse shell is not automatically approved to read its sensitive employee table.<\/p>\n Microsoft’s OneLake security role documentation<\/a> explains the grant-oriented role model and the supported table, folder, row and column choices. Read the current item-specific availability and query-engine integration carefully. Different Fabric engines and item types can enforce a security rule differently; never promise the same row filter works through every endpoint without a verification test. Direct file access is particularly important to check if a consumer can bypass the expected SQL security layer.<\/p>\n A practical matrix has rows for identities and columns for objects and operations. For example, an ingestion identity may read a source landing folder and write a bronze Delta table, while a validation job reads bronze and writes silver. A finance group gets read access to curated aggregates but not the raw address field. An incident responder may inspect run logs but must not automatically be able to export customer records. Document whether each role grants Remember that group membership is dynamic. An Entra group-based grant can expand as members join; test both newly added and removed users. Audit service identities independently from human roles. For a copied analytical dataset, the data engineer should also document how permissions change when a new table is introduced: does it inherit a broad default? Is a security role created before the data becomes accessible? These are release questions, not cleanup work.<\/p>\n Row-level security answers which records<\/em> a principal may see; column-level security answers which fields<\/em> may be returned. When region managers should only inspect orders in their assigned territory, an RLS rule can express that membership. When fulfillment staff may inspect shipment states but not the customer risk score, a column restriction is relevant. Neither replaces a complete data classification system: an aggregate can still disclose small groups, and a copied export may have its own access path.<\/p>\n Test with three personas: an entitled person, a person from another region, and someone with no assigned data role. Verify expected returned counts and column visibility through every supported consumer your design actually uses. Also test whether a privileged workspace contributor legitimately bypasses a restriction, and account for that in your threat model. Do not claim security merely because one SQL query returned no data; verify direct file, Spark and downstream access paths where relevant to the item.<\/p>\n Sensitivity labels communicate the classification and handling rules for content. They are useful for reporting and governed sharing, but a label is not an all-purpose authorization mechanism. Endorsement distinguishes a certified or promoted analytical item from an unreviewed draft; it also does not grant a data permission by itself. Combine these concepts carefully: an item can be endorsed for quality while still restricting sensitive columns, and a high-classification dataset may require both narrow access and additional review before it is copied elsewhere.<\/p>\n Fabric audit logs help reconstruct changes and access-related activity where auditing is enabled and supported. An incident investigation should answer who changed a role or a connection, which identity read the object, when it occurred and whether the source dataset had already been propagated. Do not rely solely on run status from an orchestration pipeline: a technically successful job might have shared a table with the wrong audience. The operating design should correlate change approvals, permission updates and published data versions.<\/p>\n A OneLake shortcut can expose data from another Fabric item or external storage without duplicating files. The shortcut’s identity and access model matters: an internal reference may use the calling user’s identity, while an external shortcut may rely on cloud connection credentials. The shortcut security and loading discussion<\/a> is especially relevant when deciding whether a consumer is authorized by the source location or only by the destination workspace. Do not assume a shortcut magically sanitizes data or makes residency restrictions disappear.<\/p>\n Mirroring adds another boundary. A mirrored database brings source information into an analytical context; the team must understand connector scope, table selection, source-side grants and downstream Fabric permissions. If a source account can access data far outside the intended analytical contract, the issue may originate before Fabric has any chance to filter it. Compare the effective data surface after mirroring against the approved source inventory and block unexpected tables before downstream publication.<\/p>\n Create a sample orders table with customer and region fields, then define finance and fulfillment personas. Design a limited role, verify the allowed and denied combinations, and document which service identity can write to the table. Change one user\u2019s group membership and confirm the expected propagation behavior rather than assuming permission changes take effect instantaneously. Repeat the reads with the intended query engines. Record a minimal audit trail of the test and ensure no real customer data is used.<\/p>\n Then add a shortcut to a second lakehouse and repeat the test. If the destination audience can see more through the shortcut than through the approved path, do not fix the discrepancy by hiding a notebook cell. Revisit the source and destination authorization model. Finally test a deployment to a second workspace to see whether roles, labels and connections require additional configuration. These practical exercises tie data protection to Fabric workspace lifecycle management<\/a> rather than treating security as a standalone multiple-choice topic.<\/p>\n A defendable DP-700 answer identifies the identity, data object, access path, permitted operations and enforcement location. It also distinguishes data-governance metadata from executable grants. With those five facts, the team can reason about least privilege without trusting a single convenient UI view.<\/p>\n","protected":false},"excerpt":{"rendered":" Microsoft Fabric brings analytical workloads onto OneLake, but shared storage does not mean that every workspace member should see every row. DP-700 expects a data engineer.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,8],"tags":[],"class_list":["post-4197","post","type-post","status-publish","format-standard","hentry","category-ai-data","category-certifications"],"_links":{"self":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/4197","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/comments?post=4197"}],"version-history":[{"count":2,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/4197\/revisions"}],"predecessor-version":[{"id":4439,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/4197\/revisions\/4439"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=4197"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=4197"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=4197"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}risk_score<\/code> column. Finance analysts need amounts aggregated by period; fulfillment workers need order and delivery fields; the data engineering service identity needs limited write access to append approved changes. Hiding risk_score<\/code> from a Power BI visual does not make the column inaccessible through other supported paths. Security must be designed where the data is actually exposed.<\/p>\nStart with the workspace and item boundaries<\/h2>\n
Build a permission matrix against personas, not just departments<\/h2>\n
Read<\/code> or ReadWrite<\/code> to a supported scope and avoid giving broad Admin rights solely to fix an authentication error.<\/p>\nRow and column filtering are different decisions<\/h2>\n
Connect sensitivity labels and audit evidence to permissions<\/h2>\n
Shortcuts and mirrors require source-aware governance<\/h2>\n
A negative-test lab for DP-700<\/h2>\n