Implement security and governance

Objective coverage

• Implement workspace-level access controls
• Implement item-level access controls
• Implement row-level, column-level, object-level, and file-level access control
• Apply sensitivity labels to items
• Endorse items

Quick reference: workspace roles

Use this table when a question asks for the minimum workspace role. These are capabilities granted by the role itself. Assume required licenses and connections are already available. Separate item grants and data-security rules must be considered when the question explicitly includes them.

Remember: Contributor can create and edit content but cannot manage workspace membership. Member can add users at Member or lower roles. Admin is required to add another Admin, connect Git, or delete the workspace. Viewer can read through the SQL endpoint but does not receive the same unrestricted OneLake/Spark access as the three authoring roles. SQL data-security rules can further restrict the rows or objects returned.

Source: Fabric workspace roles.

Quick reference: permissions and security settings

Sources: Shared semantic models, RLS, OLS, information protection, and endorsement.

Quick reference: when semantic-model RLS applies

Assume the semantic model has a correctly configured West role and the user is assigned to it. The user has no additional grants except those stated below.

Two frequent exam distinctions: granting Build to a Viewer does not remove RLS. Assigning a user to both West and East RLS roles combines the rows allowed by those roles; the second role does not act as a deny. These statements concern semantic-model RLS, not every security mechanism in Fabric.

Source: RLS role behavior.

Choose the control from the requirement

Implement workspace-level access controls

A workspace is a collaboration boundary. Its roles grant capabilities across a collection of items, so workspace membership is a broad answer to an access request. An Admin manages the workspace; a Contributor authors content; a Viewer consumes content subject to relevant data restrictions. A Member can create and edit items and add new Members, Contributors, and Viewers, but cannot add another Admin or delete the workspace. Match the role to required actions instead of treating a higher role as a convenient repair for every access error. Use managed security groups so that joiner and leaver changes can be reviewed centrally.

List the actions needed by each group: read a report, build from a semantic model, edit a notebook, deploy content, or manage membership. Choose the narrowest scope that can provide those actions. Check existing group memberships before adding another grant, because permissions can accumulate. Record who owns the group and how access will be reviewed. Then test using a representative identity outside the authoring team. For semantic-model RLS, workspace Admin, Member, and Contributor roles have edit capabilities and are not constrained like Viewers; testing only as the model author gives misleading evidence.

Northstar creates Sales Readers and Sales Authors groups. Readers receive a distribution path appropriate for consumption, while Authors receive authoring access in development. The regional manager belongs only to Readers and must see West sales. The model developer may see all regions for testing but is not the identity used to demonstrate consumer security. If someone adds the manager to Contributors to fix a report error, the team has changed the security model rather than simply repaired a broken link. Remove unnecessary edit access, diagnose the original missing permission, and repeat the consumer test.

A role name is insufficient evidence. Record effective memberships, item permissions, model role membership, and the actual endpoint tested. A report owner can succeed while a Viewer fails because the paths use different identities or capabilities. Distinguish a license or capacity restriction from an authorization restriction before changing permissions. Sensitivity labels and certification badges do not fix missing rights. The exam distinction is scope: a workspace role governs collaboration broadly, whereas a specific sharing or data policy narrows the intended action.

Scenario: A West manager unexpectedly sees East totals after being made a workspace Contributor. What should the administrator investigate?

Answer: Investigate the newly granted edit-capable role and all inherited memberships. Restore the intended consumer access, test the semantic model as the manager, and confirm both allowed West rows and denied East rows. Do not solve the issue by hiding the East slicer.

Recall: Why is an administrator a poor identity for an RLS acceptance test? When is sharing one item preferable to adding workspace membership?

Implement item-level access controls

An item is a specific Fabric artifact such as a report, semantic model, lakehouse, or warehouse. Item sharing can provide access without admitting someone to the whole workspace. The available permissions depend on the item type. In Power BI, permission to read a report and permission to build content from a semantic model answer different questions. Build supports discovery and creation of downstream analysis; it is not equivalent to permission to edit the shared semantic model. Always inspect the concrete item rather than assuming one universal permission vocabulary.

Identify the report and the semantic model it uses, including any cross-workspace dependency. Decide whether the requester is a consumer or a report author. Grant the supported permissions on the relevant items and check the distribution mechanism, such as a Power BI app. Test the intended workflow end to end. A report can be visible while its data query fails, and a model can be discoverable while an upstream data connection is unusable. Keep connection credentials and workspace edit rights out of a routine report-sharing solution.

An analyst in Marketing must create a report using Sales' approved measures. Grant the analyst the appropriate Build permission on the shared semantic model and the permissions required for their report-authoring workspace. Keep ownership of the model with Sales. The analyst should be able to reuse the Revenue measure without receiving warehouse administration. A second employee who only reads the finished report does not automatically need the same authoring capability. Validate each persona separately, including data restrictions applied to model queries.

Sharing is not transitive permission to every physical data source. Trace the identity used by the semantic-model connection and the rights evaluated by that path. Check whether permissions arrived through a link, explicit grant, app, workspace role, or group. Removing one route may leave another effective grant. If access persists after an apparent revocation, inspect all routes before concluding that the service ignored the change. For the exam, separate item discovery, report consumption, Build, edit, and direct source access; they support distinct tasks.

Scenario: A user can open a shared report but cannot author a new report against its semantic model. What permission should you investigate before adding workspace Contributor?

Answer: Check the model's Build permission and the user's authoring prerequisites. Grant only what the required authoring workflow needs, then validate that source administration and model editing remain unavailable.

Recall: Why can opening a report and querying a source directly produce different access results? How can a permission remain after one sharing link is removed?

Implement row-level, column-level, object-level, and file-level access control

Row-level security limits records; column or object controls limit attributes or model objects; file controls govern physical storage paths. A semantic model can filter West rows while a separately granted lakehouse path still exposes all rows. Security therefore belongs to an access path, not merely to a business dataset's name. A hidden model column is a presentation choice, not a confidentiality control. Semantic-model OLS can protect objects; SQL and OneLake have their own supported enforcement mechanisms, which must be matched to the actual engine.

Draw the routes from each persona to data: report to model, SQL client to endpoint, and notebook to OneLake. Select enforcement on every allowed route and remove unnecessary bypass routes. Define an entitlement table when dynamic RLS depends on the signed-in user. Validate relationships through which that filter propagates. Test one entitled identity, one identity in a different region, and an identity without an entitlement. Repeat with direct source access where it is allowed. Check the current Direct Lake variant because SQL endpoint policies and OneLake policies are not interchangeable.

Use six sales rows: four West and two East. West revenue totals 900; East revenue totals 400. A West consumer should obtain 900 from the semantic model and should not recover East rows by exporting or changing visuals. An analyst with authorized all-region access should obtain 1,300. A person with no entitlement should not default to all regions. If the West user receives 1,300 from a notebook, the model's RLS might be working perfectly while storage permissions violate the intended policy. Fix the additional route or explicitly document why that persona may use it.

Negative tests are as important as positive tests. An empty result could mean correct filtering, a broken relationship, or a failed data load. Prove that the permitted rows exist and are returned to the permitted identity before accepting a denied result. Combining roles can broaden access, so do not assume that an extra role acts as a deny. Investigate group overlap, entitlement duplicates, ambiguous filter paths, and the actual connection identity. Exam questions often distinguish hiding a field from securing it, or model security from storage security.

Scenario: A report hides Salary and filters by region, but an authorized model explorer can still query Salary. What is missing?

Answer: Hiding a field does not enforce object confidentiality. Apply the supported object or column security for that query path, test with a consumer identity, and review other routes to the same data. Keep the regional row filter as a separate control.

Recall: Why must an RLS test include a known permitted row? What changes when a Direct Lake query reads OneLake rather than relying on a SQL endpoint?

Apply sensitivity labels to items

A sensitivity label communicates a classification and can participate in supported protection and inheritance workflows. Its meaning comes from organizational policy. A label called Confidential does not, by its name alone, create a region filter or remove an existing Contributor. Classify the content according to the information it carries, then verify how that label behaves on the specific Fabric item, downstream path, and export format. Authorization, classification, and protection should agree, but they are distinct controls.

Confirm that the label is published to the relevant users and that tenant settings and licensing permit the intended feature. Inspect the existing label and the data represented by the item. Apply the correct label through the supported interface, then inspect downstream inheritance and a representative supported export. Document manual overrides and responsible owners. If a label cannot be applied, check policy availability and permissions before changing the dataset. Do not assume a label visible in one client is automatically enforced in every export or external tool.

Northstar's sales model includes customer contract rates, so its owner applies the organization's Confidential classification. The test plan checks the model, a downstream report, and an approved export route. Separately, the administrator verifies that the West manager still cannot read East data. If the report inherits the expected label but shows East rows, classification passed and authorization failed. If access is correct but the exported artifact lacks the expected supported protection, the export-policy path needs investigation. Keeping these acceptance statements separate makes the evidence useful.

Inheritance is a supported product behavior with prerequisites and exceptions, not a universal law that follows every copy of every byte. Check current documentation for the exact item pair and export route. A screenshot of a label proves the displayed classification at that point; it does not prove downstream enforcement. For an exam scenario, identify whether the requested outcome concerns classifying data, protecting an export, restricting item access, or filtering records. Applying the wrong mechanism can produce a reassuring badge without satisfying the requirement.

Scenario: An owner labels a model Confidential and expects that only Finance can open it, but Sales still has an existing sharing grant. What must change?

Answer: Review and adjust authorization independently of the classification. Keep the appropriate label, remove unauthorized access through all effective grant routes, and test as a Sales consumer. Verify any export protection as a separate requirement.

Recall: What does a visible label establish? Why should an export path be tested rather than inferred from the report label?

Endorse items

Endorsement helps users choose trusted assets. Promotion communicates that an owner considers an item useful; certification involves the organization's configured certifier process. These signals improve discovery and reuse, but neither is proof that every value is correct or that the viewer is entitled to the data. Treat the badge as an entry point into ownership, quality expectations, and review history. A certified model can still contain a faulty measure after an unreviewed change.

Define the asset's owner, intended audience, measures, refresh expectations, and support route. Review its quality checks and security before requesting certification through authorized certifiers. Use promotion for useful content that has not passed the certification process. After material changes, reassess whether the trust claim remains valid. Inspect permissions separately so that a discoverable certified asset does not become an accidental grant. If the certify option is missing, investigate organizational configuration and certifier membership rather than copying the data into a new workspace.

Two models are named Sales. One uses booked revenue; the other uses recognized revenue. Before certification, Northstar documents the accounting definition, currency treatment, date basis, and owner. The certified model becomes the recommended source for monthly recognized revenue. A marketing prototype may still be promoted for exploratory work, with a clear description of its different purpose. The badge helps readers select an appropriate asset only because its meaning is supported by definitions and governance. It should not replace checking whether a measure answers the current business question.

A trust signal can outlive its evidence unless ownership and review are explicit. When figures disagree, inspect definitions, data freshness, security context, and calculation logic rather than choosing whichever model has the most prominent badge. Endorsement is also distinct from sensitivity classification: highly sensitive content can be certified, and public content can be unreviewed. In exam scenarios, certification addresses organizational trust, labels address classification, and permissions address authorization. None of these alone replaces the others.

Scenario: Users keep rebuilding sales models because they cannot identify the approved one. Which governance action addresses discovery without broadening access?

Answer: Establish ownership and quality evidence, certify the approved model through authorized certifiers, and make its purpose discoverable through supported catalog features. Maintain separate access requests and permissions for users who are not yet authorized.

Recall: How does promotion differ from certification? What evidence should be revisited after changing the revenue definition in a certified model?

Shared Fabric foundations

The following field notes adapt this project’s original DP-700 explanations for the shared Fabric foundation. They provide supporting engineering context for the DP-600 objectives above; they do not add separate measured objectives.

Build an access decision from the outside in

Workspace roles define a broad collaboration boundary. Admin manages the workspace and access; Member collaborates broadly and can manage many workspace capabilities; Contributor creates and changes content; Viewer primarily consumes. Admin, Member, and Contributor are elevated identities for OneLake because their workspace rights include write access. A narrow OneLake read role therefore cannot be used to reduce the data rights already granted by one of those broader workspace roles.

Inventory people, service principals, and groups; assign each to a job function; and grant the lowest workspace role that permits the required collaboration. Prefer Microsoft Entra security groups so joiner, mover, and leaver changes occur in one identity system. Separate administration from content development, keep at least two governed owners, and review assignments periodically. Validate with a user who has no overlapping group membership. For services, document the identity, credential owner, rotation method, allowed workspace, and exact jobs.

Choose a workspace role only when the identity needs capabilities across the workspace. Do not grant Contributor merely to let a consumer query one table; use item and data permissions. Conversely, repeated direct shares across most items are a signal that the person may genuinely belong in the workspace. The failure mode to avoid is permission accumulation: a user receives narrow access directly but also inherits broad access through a workspace group, so a test of the narrow policy appears ineffective.

Scenario. Data engineers belong to a Contributor group, the platform team uses a small Admin group, and report consumers are not workspace members. A contractor who needs one lakehouse is shared that item and assigned a narrow OneLake role. Test the contractor, a Contributor, and an unassigned account. The contractor should not discover unrelated workspace items; the Contributor will still have broad OneLake rights. This three-identity test is more informative than testing only as the workspace owner.

When access is unexpectedly allowed, enumerate every workspace role and group, direct item permission, OneLake role, SQL grant, semantic-model role, and cached session. When access is denied, check the same layers in order plus tenant settings and endpoint-specific prerequisites. Remove ambiguity by using a fresh test identity and a private browser session. Record both positive and negative tests; “the administrator could open it” is not evidence of least privilege.

Item permissions and the data plane

Item permissions answer “may this identity interact with this item?” but not always “may it read every underlying row through every engine?” Read commonly exposes item metadata. Additional permissions such as ReadData or ReadAll govern documented compute or OneLake routes for supported items. A report, semantic model, SQL endpoint, and lakehouse can therefore participate in one experience while enforcing different permissions.

Start at the consumer experience and trace backward: report → semantic model → SQL endpoint or OneLake table → source or shortcut target. Grant the report or item permission first, then only the downstream data permission the intended route requires. Use Manage permissions to inspect direct grants and reshare rights. Avoid granting build, write, or reshare unless the user must create new content or delegate access. Re-test after removing a grant because tokens and sessions can temporarily obscure the result.

Use a curated report when consumers need answers, item sharing when they need a specific reusable item, and workspace membership when they participate in the workspace lifecycle. Granting ReadAll for OneLake access is materially different from granting basic Read metadata access. Direct Lake also requires careful reasoning about which identity and fallback path performs the query. Never infer the data plane solely from whether the item appears in navigation.

Worked access trace. Lee can open a report but receives an error when connecting directly to the lakehouse SQL endpoint. That can be correct: the report path may be authorized through its semantic model while direct SQL data access was never granted. If the requirement is report consumption only, do not “fix” the result with Contributor. If direct analysis is required, grant the documented endpoint permission and test a permitted and forbidden table.

Classify the failing action precisely: discover item, open item, query SQL, read OneLake, build a semantic model, write data, or reshare. Each action points to a different permission. Examine group expansion and inherited workspace roles before adding another direct grant. A mini-lab should create a matrix of three users by four actions and predict each outcome before testing it.

Data-level controls

Object or folder security chooses the tables, schemas, or paths a role can reach. Column security removes selected attributes. Row security applies a predicate to records. These controls can be combined, but OneLake roles use a grant model: a restrictive role does not deny access obtained from another role or permission path. Engine-native SQL or semantic-model security may have different authoring and enforcement surfaces, so identify the query route in every design.

Define access from a business policy, not from the current folder layout. Create roles for stable functions, grant only required tables or folders, then apply row and column rules where supported. Use immutable business keys and a governed identity-to-scope mapping for dynamic row filtering. Validate Spark, SQL, Direct Lake, and OneLake API paths that are actually in scope. Test nulls, multiple group memberships, new rows, schema changes, and an identity that should see nothing.

Prefer object or folder grants when whole datasets differ by audience. Use CLS when a column must not be visible, RLS when records differ by user context, and a curated view when a stable consumer contract or derived logic is needed. Masking is not a substitute for removing a sensitive column. Avoid elaborate per-user roles; group-driven roles and mapping tables scale better and are auditable. Check current feature support before assuming the same rule is enforced by every Fabric engine.

Worked policy. Regional analysts may read Sales.OrderFact only for their region and must not see Customer.Email; finance may read all regions and the email column. Create separate group-based roles, apply the region predicate to the analyst role and exclude or restrict Email, then test an analyst in two regions, finance, and an unassigned user. Adding an analyst to Contributor would invalidate the intended OneLake restriction and should be caught by the test.

If a filter appears bypassed, look for broad workspace write, another granting role, ownership, a different engine, or a cached result. If a query fails, distinguish inability to reach the item from denial at table, column, or row evaluation. Use a minimal query against one known object and progressively add columns and predicates. Preserve the identity, endpoint, query, expected rows, actual rows, and effective memberships as security-test evidence.

Masking, classification, trust, and evidence

Dynamic data masking is a presentation control evaluated at query time for principals without UNMASK. Configure a supported mask on the target column, grant ordinary query access to a test role, and compare results with and without UNMASK. Choose a mask that reduces accidental exposure without misleading users about the data type. Because values remain unchanged and inference can be possible, use encryption, RLS, CLS, or denied object access for true confidentiality boundaries. Troubleshoot by checking the querying principal, UNMASK grants, object permissions, endpoint, and supported type.

Sensitivity labels classify an item according to organizational information protection policy. Prerequisites include tenant configuration, labels published to the author, and a supported item or propagation path. Choose a label based on the data's policy classification, not the item's popularity. Apply it, verify the displayed label and any documented downstream inheritance or export behavior, and test the relevant route. A label can persist as governance metadata or invoke supported protection, but it is not evidence that workspace, item, and data permissions are correct. If a label is unavailable, inspect Purview publication, licensing, tenant settings, user scope, and item support.

Endorsement describes organizational trust. Owners can promote suitable items; authorized reviewers certify items or designate master data according to the organization's governance process. Define criteria—owner, documentation, quality checks, freshness, security review, and support contact—before applying a badge. Review it when those facts change. Certification does not grant access or guarantee that a consumer's interpretation is valid. If endorsement options are missing, verify write permission, tenant configuration, and designated certifier status.

Fabric audit evidence is searched through Microsoft Purview Audit. Establish the investigation question and time zone, then query an appropriate time range, users, operations, and workload context. Preserve exported results with the query criteria and investigation record. Audit is for recorded user and admin activity; Monitoring hub and workload logs explain operational executions. Account for retention, licensing, ingestion delay, operation naming, and clock boundaries before concluding an event is absent. As a mini-lab, perform a benign item-share change, wait for ingestion, locate its audit record, and compare what the audit event tells you with what the item's current permission page tells you.

OneLake security roles grant supported table and folder access within a data item. The author needs the documented Fabric Write or Reshare capability, and role members should be stable groups where possible. Create the role, choose Read or ReadWrite as required, select data objects, apply optional row or column filters, assign members, and test through the intended engine. Default roles can map documented item or workspace permissions to data access. Because grants are additive, always inspect other roles and broad workspace rights when a user sees too much. For a shortcut, evaluate both the OneLake reference and the remote source identity or credential path.

For exam scenarios, separate four verbs: authorize with workspace, item, and data permissions; obscure returned values with masking; classify with a sensitivity label; signal trust with endorsement. Then distinguish audit evidence from operational monitoring. A request for “one table only” points away from Contributor and toward item plus OneLake data permissions. A request to hide rows by region points to RLS, not a label or mask.

Recall and mini-lab. Why can a Contributor bypass the intent of a narrow OneLake read role? What additional capability does a user need when Read allows item discovery but not direct data access? Contrast CLS with DDM in one sentence. Explain why Certified and Confidential answer different questions. Finally, design a five-row access matrix for an administrator, engineer, analyst, report-only consumer, and unassigned user; include at least one denied test for workspace, item, SQL, and OneLake access.

Security scenario drills

Report consumer versus direct lake access

Nora must view a governed Power BI report but must not browse lakehouse files or query its SQL endpoint. Share the report/app through the supported consumption path and provide only the semantic-model/report permissions that path requires. Do not add Nora as Contributor and do not grant ReadAll merely because the report uses OneLake-backed data. Test report rendering, build/export behavior as required, direct SQL, direct OneLake, unrelated item discovery, and reshare.

If the report works but direct SQL fails, that may be the intended least- privilege outcome. If the report fails, trace the semantic model's connection, identity, Direct Lake/fallback behavior, model security, and source permissions instead of granting a broad workspace role. Record the successful consumer path and every denied alternate route.

Regional analysts with protected attributes

Analysts may see orders only for assigned regions and must not see personal email; Finance may see all regions and email. Start with group-based identities and ensure analysts do not inherit Admin, Member, or Contributor. Grant the appropriate item/data access, implement a region policy using a governed identity-to-region mapping, and use CLS/object design to remove Email from the analyst path. DDM may reduce accidental display but is not the primary boundary.

Test an analyst in one region, an analyst assigned to two regions, Finance, an unassigned user, a null/unknown region, and Spark/SQL/Direct Lake routes in scope. Count expected versus actual rows and columns. If an analyst sees everything, inspect additive OneLake roles and workspace write before rewriting the RLS predicate.

Labeled and certified does not mean authorized

A curated lakehouse is labeled Highly Confidential and certified as the trusted source. A new user still cannot open it. This is consistent: the sensitivity label classifies and may protect supported flows; certification signals that an authorized governance process trusts the asset; neither grants the user an item or data permission. Determine the business requirement and grant the narrow workspace/item/OneLake or endpoint permission only if approved.

Conversely, a user with access can still mishandle content if the label/export route is not supported or organizational policy is absent. Test the exact item, downstream inheritance/export path, and access separately. Review certification when owner, quality, freshness, security, or documentation changes.

Audit an unexpected permission change

A restricted table became readable to a contractor. Preserve the observation, identity, time zone, item, endpoint, and current effective memberships. Search Purview Audit over an appropriate window for share, permission, role, or group- related operations available to the investigation; export with query criteria. Compare audit history with current workspace roles, direct item grants, OneLake roles, SQL/model roles, and Entra group membership.

Audit can show recorded actions but may not encode the entire present effective- permission calculation, and absence can reflect retention, ingestion delay, or filter choice. After removing the unintended grant, re-test denied and approved users, identify the control gap, and add periodic access review or alerting. Keep sensitive audit evidence under restricted investigation handling.

Shortcut across security boundaries

A lakehouse shortcut points to an external storage account. The shortcut object, Fabric item, OneLake role, connection identity, and source ACL all participate. Granting the user access to see the lakehouse does not necessarily authorize the target, and a workspace Contributor can be broader than the intended narrow role. Document whether access uses a shared connection, delegated identity, or another supported credential route.

Test an owner, intended reader, denied reader, and expired/rotated connection. Deleting the shortcut removes the reference, not external data. Sensitivity and endorsement should be reviewed for the exposed Fabric item, but neither repairs the underlying authorization path.

Capstone: governed analytics workspace

A health-services analytics team (using synthetic exam data) needs engineers to build, regional analysts to query only their region, executives to consume one report, and an external auditor to inspect access-change evidence for a limited period. Design the boundary before assigning roles.

Place engineers in an Entra group with Contributor only in the development workspace. Keep workspace Admin and Member groups small and separate. Analysts and executives should not become Contributors in Production. Share the required warehouse/lakehouse or semantic/report item and grant the documented data path: regional row policy plus protected columns for analysts; report-only consumption for executives. Give the audit investigator controlled Purview Audit access and an evidence export location, not broad data authoring.

Classify sensitive items through published Purview labels and verify supported inheritance/export routes. Certify the curated semantic model only after owner, source, quality, freshness, security, documentation, and support criteria pass. Certification signals trusted reuse; the label communicates sensitivity; the permission layers enforce access.

Expected access matrix

“Elevated” is a warning in the matrix: administrators and Contributors are poor negative-test identities because workspace write can supersede narrow OneLake grants. Test each persona with clean membership and record effective groups, endpoint, action, expected and actual result.

Changes and investigation

Simulate four events: an analyst changes region, an engineer leaves, a label is changed, and an unintended direct item share is added. Group-driven regional mapping and engineer access should update through governed identity processes. The label change follows information-protection policy and review. The direct share should be discovered through access review and investigated through the relevant audit activities and current effective-permission state.

Preserve audit query criteria, UTC/local time interpretation, operation/user/item identifiers, exported evidence, and investigator. Remove the unintended share, retest both allowed and denied paths, and add a preventive control. Do not infer from a missing search result that no change occurred until retention, ingestion delay, licensing, operation naming, and filters are considered.

Acceptance evidence

The capstone passes when least-privilege groups and owners are documented; workspace, item, OneLake/SQL/model policies form one traced path; regional and column tests include denied cases; direct lake access remains unavailable to report-only users; label and endorsement behavior is verified separately from authorization; shortcut/source credentials are owned and rotated; and a benign permission change can be found, explained, remediated, and retested.

Sources and provenance

The measured objectives follow the DP-600 blueprint effective July 21, 2026. Product references were retrieved for this edition; the book manifest records the actual retrieval time and SHA-256 of each downloaded HTML response. Examples and scenarios are original teaching material. Shared field guides reuse this project’s original DP-700 writing where the underlying Fabric concepts apply. Microsoft Learn remains authoritative, especially for current feature support and capacity limits.

• Study guide for Exam DP-600: Implementing Analytics Solutions Using Microsoft Fabric
• Roles in workspaces in Microsoft Fabric - Microsoft Fabric
• Row-level security (RLS) with Power BI - Microsoft Fabric
• Object-Level Security (OLS) with Power BI - Microsoft Fabric
• Permission model - Microsoft Fabric
• OneLake security roles, permissions, and scopes - Microsoft Fabric
• Dynamic Data Masking in Fabric Data Warehouse - Microsoft Fabric
• Information protection in Fabric - Microsoft Fabric
• Endorsement overview - Microsoft Fabric
• Track user activities in Microsoft Fabric - Microsoft Fabric