Configure security and governance

A new analyst needs to read exactly one table in a lakehouse called SalesGold, one item among the dozens sitting in a Fabric workspace, and nothing else. Four different Fabric surfaces can say yes to that request, and choosing the wrong one is how a one-table ticket ends with someone who can browse every notebook, pipeline, and warehouse their team owns. Working out which surface fits a request like that, for every shape of request the exam puts in front of you, is what this page is for.

This page covers the security and governance slice of the domain. Its siblings cover the rest: configuring workspace settings covers the Spark, domain, OneLake, and Apache Airflow settings a workspace carries, lifecycle management covers version control and deployment pipelines, and orchestration covers scheduling and pipeline activities. If you arrived from one of those pages, the topic has changed: nothing below is about how content moves between environments, only about who may see it and how that is recorded.

Three checks, then four layers

Before any read succeeds, Fabric runs three checks in a fixed order: Microsoft Entra authentication (can this identity sign in to the tenant), Fabric access (can it reach Fabric at all), and data security (may it perform this action on this table or file). Microsoft's permission model^[1] article states that a user must pass every level, and that the levels evaluate sequentially. The first two are mostly tenant plumbing. The third is where your design decisions live, and it is decided by four grant layers:

Layer	What one grant covers
Workspace role	Every supported item in one workspace
Item permission	One item, plus its SQL analytics endpoint for a lakehouse
SQL engine grant	Schemas, tables, views, columns, and rows reached over T-SQL
OneLake security role	Tables, schema folders, and file folders in OneLake storage

Two names in that table are worth pinning down before they are used again. OneLake is the single data lake that Fabric workspaces sit on top of, divided into a separate container per workspace, so every item's data physically lives there. The SQL analytics endpoint is the Transact-SQL surface Fabric places over a lakehouse, which is why a lakehouse can be queried with SQL at all.

Those four layer names are used consistently for the rest of the page. Fabric access control uses roles and permissions assigned to identities, with each of the four layers applied at a different reach. Read that as a working habit rather than a definition: to work out what someone may do, look for the grants attached to that principal, note which of the four layers each grant sits at, and let the reach of that layer tell you how far it carries. Every item's data physically lives in the same lake, so where the bytes sit never answers the question by itself. Note also that these four are the grant layers rather than the whole of access control: a sensitivity label associated with a Microsoft Purview protection policy can also control whether an access attempt succeeds, under the narrow conditions set out under "Sensitivity labels in Fabric" below.

The figure below traces the three ordered checks and expands the third into the four layers, which are the subject of the next four sections.

The practical takeaway is a single question to ask of every access request: what is the narrowest layer that satisfies it? Answering "workspace role" for a request that names one item is the single most common overreach in Fabric security design, and, as the sections below show, it is also the answer that makes every finer control underneath it stop mattering.

Workspace roles are the widest of the four layers, and their defining property is that they are not selective: a role applies to all items within the workspace, so there is no version of Viewer that reveals one lakehouse and hides the others.

Fabric has four roles, listed from most to least capable: Admin, Member, Contributor, and Viewer. The roles in workspaces^[2] reference publishes the full capability grid; the rows that decide most exam questions are these.

Capability	Admin	Member	Contributor	Viewer
Update and delete the workspace	Yes	No	No	No
Add or remove people, including other admins	Yes	No	No	No
Add members or others with lower permissions	Yes	Yes	No	No
Create workspace identity	Yes	No	No	No
Connect workspace to a Git repository	Yes	No	No	No
Create or modify warehouse and database items	Yes	Yes	Yes	No
Write or delete lakehouse and warehouse schema and data	Yes	Yes	Yes	No
Read lakehouse and warehouse data with T-SQL (ReadData)	Yes	Yes	Yes	Yes
Read through OneLake APIs and Spark (ReadAll)	Yes	Yes	Yes	No
Connect to the SQL analytics endpoint	Yes	Yes	Yes	Yes

Read the grid for the gaps rather than the grants. Contributor is the role that writes data but lacks these workspace-level administrative capabilities: it cannot add a workspace user, cannot create the workspace identity, cannot connect the workspace to Git, and cannot edit OneLake security roles. Member adds sharing and the ability to add people at Member level or lower, which is why a Member cannot promote anyone to Admin. Viewer is the only role that reads with T-SQL but not with Spark: it gets ReadData and can connect to a SQL analytics endpoint, and it does not get ReadAll, so a Viewer running a notebook against the lakehouse files fails until an item or OneLake permission supplies that access.

Roles combine to the highest, never the lowest

When a person picks up more than one role assignment, the roles resolve to the most permissive of them. Roles can be assigned to individuals or to security groups, Microsoft 365 groups, and distribution lists, and the same reference states that someone in several user groups "get the highest level of permission that's provided by the roles that they're assigned", with nested groups passing the role down to every contained user. Adding an existing Member to a Viewer group therefore changes nothing about what they can do.

That rule is worth holding next to the layer model, because it generalises. Fabric grants accumulate, so adding a grant never takes access away. Three named rules do take it away: a T-SQL DENY inside the SQL engine, which overrides a GRANT on the same object; a row-level security policy, which filters rows for every user unless it is written to exempt them; and the column-level security carried inside a OneLake security role when enforced through the SQL analytics endpoint, which hides a column across roles rather than unioning them. Nothing else on this page subtracts. The sections on the SQL engine, on masking, and on OneLake security take each in turn, where accumulation produces its most surprising results.

The takeaway for design is to treat the workspace role as a statement about a person's relationship to the whole workspace. If the honest answer is "they work in this workspace", assign a role. If it is "they need one thing from this workspace", the next section is the right layer.

Not every principal in a Fabric workspace is a person. Two non-human identities solve different problems, and they are easy to confuse because both end up as a service principal in Microsoft Entra ID.

A Microsoft Entra service principal is an identity you create and own, registered as an application in your tenant. It can be assigned a Fabric workspace role and then inherits exactly the same permissions a user in that role would have for application programming interface (API) based operations, including the Items REST API and the Job Scheduler API. Nothing about it is special: an automation account assigned Contributor can do what a human Contributor can do, which is why the least privileged role that covers the job's item and scheduler actions is the correct assignment.

A workspace identity is different in ownership. It is an automatically managed service principal that Fabric creates for, and binds to, one workspace. Per the workspace identity^[3] documentation, Fabric creates the Entra service principal and app registration on your behalf and "uses workspace identities to obtain Microsoft Entra tokens without the customer having to manage any credentials". Its two supported uses are authentication for connections from items such as OneLake shortcuts, pipelines, semantic models, and Dataflows Gen2 (CI/CD), and trusted workspace access, which lets a workspace read or write firewall-enabled Azure Data Lake Storage Gen2 accounts through shortcuts.

Three constraints on the workspace identity are worth memorising. A workspace admin can create or delete it. It cannot be created in a My workspace. And by default it is granted no workspace role at all, so it is an authentication mechanism first and a permission holder only if you deliberately make it one. Deleting it is not reversible, and deleting the workspace deletes the identity with it.

Choose between them on ownership of the credential. When the requirement names a pipeline or shortcut connecting to an Azure resource without a stored secret, that is the workspace identity. When it names automation calling Fabric APIs on a schedule, that is a service principal holding a workspace role.

Item permissions answer the request the workspace role cannot: give this person this one item, and nothing else in the workspace. Sharing an item grants access directly to the recipient and does not make them a member of any workspace role, which the permission model^[1] illustrates with a worked example where removing a report's item permission still leaves a workspace Viewer able to open it, because two independent layers were granting the same access.

What the base share actually gives

Sharing grants Fabric Read by default, and Read is narrower than it sounds. For a warehouse, the sharing and permissions^[4] reference describes Read as "the equivalent of CONNECT permissions in SQL Server": the recipient can connect to the SQL analytics endpoint and can query nothing until either a broader permission or a T-SQL GRANT on specific objects arrives. That is worth holding against the previous section, where a workspace Viewer could query tables straight away: the Viewer held ReadData through their workspace role, while a share recipient starts from item-level Read, which is a different and much smaller grant that happens to share the word. Sharing a lakehouse also grants access to its SQL analytics endpoint, and lakehouse sharing^[5] states plainly that sharing "grants read access only. It doesn't grant workspace membership or write permissions".

The additional permissions offered in the sharing dialog are what turn Read into a usable data path, and each names its engine. These are the ones a lakehouse share offers; individual item types add their own on top, so read a sharing dialog rather than assuming this list is complete for every item.

Permission	What it allows
Read	Open the shared item, or connect to its endpoint
ReadData (Read all with SQL analytics endpoint)	Read every table and view over T-SQL, equivalent to the SQL Server db_datareader role
ReadAll (Read all with Apache Spark)	Read the underlying files through Spark and the OneLake APIs
SubscribeOneLakeEvents	Subscribe to the item's OneLake events in Real-Time hub
Execute Apache Spark	Run Spark jobs through the lakehouse Livy endpoint

ReadData and ReadAll are the pair that most often decides an exam answer, and the warehouse reference is explicit that they "are separate permissions that do not overlap". Granting ReadData to someone whose notebook reads Delta files with Spark leaves them failing; granting ReadAll to someone who only needs T-SQL hands over the whole file layer. The figure below follows one recipient down both paths, marks which permission each one needs, and names the rule set that filters what comes back on each: SQL rules on the T-SQL side, OneLake security roles on the Spark and OneLake API side. Each of those two rule sets gets its own section further down.

Resharing, and who may share at all

Workspace Admins and Members can share by default. Contributors and Viewers can share only if they hold explicit Share (reshare) permission on the item, and a resharer can never grant more than they themselves hold. Note also that Read, ReadData, and ReadAll are shareable while Write is not, which is the mechanical reason the sharing path cannot be used to hand out write access.

Two practical shapes fall out of this. For least-privilege access to named warehouse objects, share with no additional permissions and then use T-SQL GRANT on exactly those objects; ReadData would be far broader. For write access, stop using item permissions altogether and assign a workspace role such as Contributor, or, for the narrow lakehouse case, a OneLake security role carrying ReadWrite.

The SQL engine grant is the layer that gets specific about rows and columns, and its three mechanisms all live in the database tier, meaning the rules apply on every query from every client rather than being enforced by an application. All three apply to both a Warehouse and a lakehouse SQL analytics endpoint, and all three are invisible to Spark and the OneLake APIs.

There are three sanctioned approaches, and they answer different questions. Object-level grants decide which tables, views, functions, and procedures a caller may touch at all. Row-level security (RLS) decides which rows of a permitted table come back. Column-level security (CLS) decides which columns a caller may reference. Pick by what the requirement restricts, then implement.

Object-level grants

The narrowest starting point is a share with no additional permissions plus explicit T-SQL. Fabric supports the familiar GRANT, REVOKE, and DENY statements against schemas, tables, views, functions, and stored procedures, documented under SQL granular permissions^[6]. This is the mechanism that subtracts at the object level: a DENY on an object overrides a GRANT on it, which is why a warehouse can be shaped down to a single approved view.

Row-level security

RLS restricts rows using two objects that must both exist. The row-level security^[7] reference specifies an inline table-valued function (a function that returns a table expression, abbreviated inline TVF) that holds the row-by-row test, called the predicate, bound and enforced by a CREATE SECURITY POLICY^[8] statement. A stored procedure cannot take the function's place.

Listing 1: the predicate function and the security policy that binds it

-- The predicate: returns one row when the caller may see the input row,
-- and an empty result when they may not. WITH SCHEMABINDING is the default
-- and lets Fabric skip extra permission checks on the predicate itself.
CREATE FUNCTION Security.tvf_securitypredicate(@SalesRep AS nvarchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS tvf_securitypredicate_result
WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'manager@contoso.com';
GO

-- The policy: binds the predicate to a column of the target table.
-- Without this statement the function is inert; the policy is what enforces it.
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.tvf_securitypredicate(SalesRep)
ON sales.Orders
WITH (STATE = ON);
GO

Comments are valid Transact-SQL, so the two above can stay in a real script. In Listing 1, the SalesRep column named in the ADD FILTER PREDICATE clause is the value passed to the function's @SalesRep parameter for each row, which is how a per-row decision is made from a table-level policy.

Filter predicates are applied while reading from the base table, so they affect SELECT, UPDATE, and DELETE. The application is not told that rows were removed; if everything is filtered, the caller simply gets an empty set. INSERT is not filtered, so a user can insert a row that they will then be unable to read. Each table needs its own policy, and a table with none returns unfiltered data. The figure below traces one query through the policy and the predicate.

One consequence catches people out, and it is the row-level exception to the accumulate-upward rule. Security policies apply to every user including dbo, and the reference notes that if members of roles like Admin, Member, or Contributor need to see all rows for troubleshooting, "the security policy must be written to allow that", exactly as Listing 1 allows manager@contoso.com.

Column-level security

CLS needs no policy object at all. It is a column-scoped GRANT^[9], which Microsoft recommends assigning to roles rather than individuals for manageability.

Listing 2: granting SELECT on named columns, leaving CreditCard out

GRANT SELECT ON Customers(CustomerID, FirstName, LastName, Phone, Email) TO [Charlie@contoso.com];

The behaviour worth remembering is what happens on a wildcard query. SELECT * FROM Customers run as Charlie does not quietly omit the ungranted CreditCard column; it fails outright with Msg 230 ... The SELECT permission was denied on the column 'CreditCard'. Choose CLS when a query touching a forbidden column must fail, and the masking of the next section when it must succeed with the value obscured.

Taken together: object grants choose the tables, RLS filters the rows, CLS gates the columns, and none of the three reaches beyond the T-SQL path. The section after next rebuilds equivalent controls for readers who arrive over Spark.

Dynamic data masking (DDM) is the third control in the SQL engine layer, and the odd one out among them. It does not decide who may read a column; it decides what the column looks like when someone reads it. The data in the database is unchanged, so applications keep working and masking rules are applied to query results only.

Four masking functions are available on a warehouse or SQL analytics endpoint column, per the dynamic data masking^[10] reference.

Function	Effect	Example syntax
Default	Full mask by data type: XXXX for strings, 0 for numerics, 1900-01-01 for dates	MASKED WITH (FUNCTION = 'default()')
Email	Exposes the first letter and a .com suffix, as aXXX@XXXX.com	MASKED WITH (FUNCTION = 'email()')
Random	Replaces a numeric value with a random value in a stated range	MASKED WITH (FUNCTION = 'random(1, 12)')
Custom String	Exposes a prefix and suffix with custom padding between	MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')

Who sees through a mask is decided by permissions. Viewing masked data needs only SELECT on the table; viewing unmasked data needs UNMASK on the column or CONTROL on the database. Because workspace Admin, Member, and Contributor hold CONTROL on the database by design, they see unmasked values by default, which is the accumulate-upward pattern from the workspace-role section showing up again. Managing masks needs ALTER ANY MASK plus ALTER on the table, a pair typically granted to a security officer.

The blind spot

A mask changes the displayed value, not the query engine's ability to evaluate a predicate against the real one. Microsoft's own worked example makes the failure concrete, and it is the reason masking never counts as a boundary.

Listing 3: a range query that infers a masked salary

SELECT ID, Name, Salary FROM Employees
WHERE Salary > 99999 and Salary < 100001;

Every row Listing 3 returns displays Salary as 0, but the fact that those rows came back at all reveals that each of those employees earns between $99,999 and $100,001. Repeat with narrowing ranges and the real number falls out. The documentation's conclusion is unambiguous: do not use dynamic data masking alone to secure sensitive data from users who have query access.

Use DDM for what it is good at, which is preventing accidental exposure in result sets that people look at all day. Put the actual boundary in object-level, row-level, or column-level security, and grant UNMASK only to principals who must retrieve original values.

OneLake security is the layer that secures the data where it actually sits, which is why it is the one that also works for a notebook. Everything in the two previous sections stopped at the T-SQL path; this layer grants access to tables and folders in OneLake itself, and because Delta tables and schemas are represented as folders, one model covers structured tables and unstructured files alike.

The access control model^[11] defines a role by four parts: a type, a permission, a scope, and members. The type is the first thing to internalise, because only GRANT-type roles are supported. There is no deny role. The model is deny-by-default, so a principal starts with no data access and picks up whatever roles grant. Permissions are Read and ReadWrite. Note that this Read is not the item-permission Read of the sharing section: OneLake Read is a data permission equivalent to VIEW_DEFINITION plus SELECT, where item Read only opens the item, and ReadWrite adds ALTER, DROP, UPDATE, and INSERT. Roles can be defined on lakehouses, mirrored databases, mirrored catalogs, and Azure Databricks mirrored catalogs.

Scope inherits downward. Granting a folder grants everything beneath it, and granting a subfolder also grants the ability to list and traverse its parent directories so the data stays discoverable, in the same way a Windows folder permission does. This is an analogy the documentation itself draws, not Fabric terminology.

Why a restrictive role does not restrict a Contributor

Every new item gets default roles, which are ordinary OneLake roles created automatically: a lakehouse gets DefaultReader, covering all folders under Tables/ and Files/ for everyone holding ReadAll, and DefaultReadWriter for everyone holding Write. That is the machinery behind the rule that matters most here. Workspace Admin, Member, and Contributor always hold Write to OneLake, and the reference states that those roles "override any OneLake security Read permissions".

So a restrictive OneLake role placed on a Contributor changes nothing about what they can read. Granular OneLake security is a tool for principals whose broader layers are already narrow: Viewers, and recipients holding Read on the item. If a requirement says a data engineer must write tables but must not see a sensitive folder, no OneLake role delivers it while they remain Contributor.

Rows and columns inside a role

OneLake roles can carry their own row-level and column-level filtering, expressed as SQL predicates for rows and a hidden-column list for columns. This is a separate implementation from the warehouse RLS and CLS of the earlier section, sharing the names but not the objects, and Fabric engines apply it at query time. That filtering is generally available for the Lakehouse, Spark notebooks, the SQL analytics endpoint in user's identity access mode, and Direct Lake on OneLake semantic models, and is in preview for Eventhouse (rows only) and authorized third-party engines.

How multiple roles combine is the part that generates errors. Within one role, the granted objects, the row filter, and the column list intersect: the role shows the rows that pass its predicate, from the columns it allows, of the tables it grants. Across roles, results union, and the combination a user actually gets is called their effective role. The figure below shows both operations. The documented limitation follows from mixing the two: "the same user in two or more roles with different allowed columns isn't supported if any of the roles also has an RLS statement". Put the row rule and the column rule for one table in one role.

Two more shapes worth carrying into an exam. A role with ReadWrite cannot contain RLS or CLS constraints at all. And in the SQL analytics endpoint specifically, column-level security uses a deny semantic and intersects across roles rather than unioning, so a column hidden in any role stays hidden there.

Finally, the operational limits: 250 roles per item (raisable to 1000 by request), 500 members per role, and 500 permissions per role. Role definition changes take about five minutes to apply, and a change to a user group's membership takes about an hour, with some engines needing another hour of cache expiry on top.

The summary to carry away is that OneLake security is the only layer that reaches every engine, and the only one whose rules survive a reader switching from T-SQL to Spark, but it buys that reach at the cost of being unable to restrict anyone who already holds a writing workspace role.

A sensitivity label is a classification stamped on a Fabric item, drawn from Microsoft Purview Information Protection rather than defined inside Fabric. The label travels with the item and, through the OneLake catalog governance experiences, gives administrators a view of which assets are labelled, which are not, and where a given label has spread.

Fabric offers several routes to getting items labelled, described in the information protection^[12] article, and they exist because manual labelling alone never reaches full coverage.

Capability	What it does	Fabric support
Manual labeling	A permitted user applies a label to an item	All Fabric items
Default labeling	An item gets a label on create or edit if none is applied	All Fabric items, with limitations
Programmatic labeling	Labels set, changed, or removed via Power BI admin REST APIs	All Fabric items
Downstream inheritance	A label propagates to dependent items	All Fabric items, with limitations
Mandatory labeling	Items cannot be saved unlabelled	Power BI items fully; some Fabric items with limitations

Downstream inheritance is on by default. It flows Power BI item to Power BI item, Fabric item to Fabric item, and Fabric item to Power BI item, and it does not flow Power BI item to Fabric item. Items autogenerated from a lakehouse or warehouse take the label of that parent and do not reach further upstream for it.

Where labels do and do not control access

A label is not a permission, with one carefully bounded exception. On its own a label classifies. It gates access only when it is associated with a Microsoft Purview protection policy, and then only inside the tenant where the label was applied; the related publishing-policy path covers Power BI Desktop files and supported export paths such as Excel, PDF, and PowerPoint. The article marks every other scenario as unsupported for access control, explicitly including cross-tenant access and exports to .csv or .txt.

The exam-relevant reading is therefore narrow. When a question asks how to classify Fabric items or make classification spread with lineage, the answer is sensitivity labels. When it asks how to stop a named group accessing a Fabric item, consider whether the scenario calls for one of the four grant layers or a sensitivity label associated with a Microsoft Purview protection policy.

Endorsement answers a different question from every other feature on this page: not who may use an item, but whether they should trust it. An endorsed item wears a badge in the interface and is listed ahead of unendorsed items in some lists, and that is the whole of its effect. It changes no permission.

The endorsement overview^[13] defines three badges, and they differ mainly in who is allowed to apply them.

Badge	Claim	Who can apply it	Scope
Promoted	The creators think the item is ready for sharing and reuse	Any user with write permissions on the item	Any Fabric or Power BI item except Power BI dashboards
Certified	An organization-authorized reviewer confirms it meets quality standards and is authoritative	Only users specified by a Fabric administrator	Any Fabric or Power BI item except Power BI dashboards
Master data	The item is a core, single-source-of-truth data source	Only users specified by the Fabric administrator	Only items that contain data, such as lakehouses and semantic models

The distinction that questions hang on is self-service versus reviewed. Promoted is a claim by the people who built the item, so it asserts nothing about organizational review; any user can request certification, but only designated reviewers actually certify. Certification and master data endorsement have to be enabled by a Fabric administrator before either appears, and certification enablement can be delegated to domain administrators, which lets a different reviewer set exist per domain.

Read a scenario for who is doing the asserting. A data engineer marking their own gold table ready for reuse is Promoted. A governance team signing off that the customer table is the authoritative source is Master data if the item holds data, and Certified for the general quality claim.

The audit log is the record of who did what, and it is the answer whenever a question asks about a past action rather than a present permission. Fabric writes user and admin activity into the unified audit log, and you search it in the Microsoft Purview portal rather than anywhere in the Fabric interface.

Access is gated outside Fabric. Per track user activities^[14], you must be assigned the Audit Logs role in Exchange Online to reach the audit log; by default the Compliance Management and Organization Management role groups carry it, and the View-Only Audit Logs role also permits searching. A Fabric administrator role by itself is not the qualifying permission.

Four filters carry most investigations, and they combine with AND, so results match all criteria at once:

• Date and time range, using Start date and End date, defaulting to the past seven days and displayed in Coordinated Universal Time (UTC)
• Activities, returning only the operations you select from the published operation list
• Users, given as email addresses, and left blank to return every user and service account in the organization
• File, folder, or site, searched by name or URL

The same records are reachable from Exchange Online PowerShell for scripted extraction. One gap is worth knowing: when capacity ID and capacity name are absent from an audit entry, you find them in the Microsoft Fabric Capacity Metrics app instead.

Do not confuse this with the Monitoring hub, which is covered in depth on the monitoring page. The Monitoring hub shows runs and their status for items the viewer already has access to, which makes it an operational tool; the audit log is the tenant-wide compliance record of user and administrative operations. A question about proving who exported a dataset last month is an audit log question, not a Monitoring hub question.

DP-700 security questions are usually a permission-selection problem dressed as a scenario. The stem describes a person, an access path, and a boundary, and the four answers are usually the four grant layers. Working the stem in a fixed order gets you to the right layer quickly.

Ask, in this order: how many items does this person need (one, or the workspace), which engine do they read with (T-SQL, or Spark and OneLake APIs), and is the restriction about tables, rows, columns, or displayed values. Those three answers pick the layer and usually the exact permission.

Stem shapes and the answer they want

• "Grant access to one lakehouse without exposing other workspace items" wants item sharing. Any workspace role is wrong because roles apply to every item.
• "The user must query one approved view and nothing else" wants a share with base Read plus a T-SQL GRANT on that view. ReadData is the trap: it is read access to every table and view.
• "A notebook must read the Delta files with Spark" wants ReadAll or a OneLake permission. ReadData is the trap, because the two permissions do not overlap.
• "Queries referencing the sensitive column must fail" wants column-level security. Dynamic data masking is the trap, because masked queries succeed.
• "Values must be hidden from casual viewing but reports keep working" wants dynamic data masking, and the follow-up is usually that masking alone is not a boundary.
• "Restrict a Contributor to selected tables" is a trick premise: no OneLake role restricts a Contributor. The answer changes their workspace role or their item access first.
• "Row filtering must also apply to Spark readers" wants a OneLake security role, not warehouse RLS, because SQL rules stop at the T-SQL path.
• "Row and column limits on the same table" wants both rules in one OneLake role.
• "Mark the item as reviewed and authoritative by the organization" wants Certified, or Master data for a data-containing item. Promoted is the trap because it is self-service.
• "Classify items and have the classification follow lineage" wants sensitivity labels. A label reaches access control only when it is associated with a Microsoft Purview protection policy in the applying tenant or with a Microsoft Purview publishing policy for Power BI Desktop files and supported export paths, so unless the stem puts one of those policies on the table, a grant-or-deny question still wants one of the four layers.
• "Find out who performed an operation" wants the audit log in the Microsoft Purview portal. The Monitoring hub is the trap.

Distractors that recur

Three families of wrong answer show up repeatedly. The first substitutes one engine's control for another's, offering warehouse RLS for a Spark requirement or a OneLake role for a T-SQL one. The second assumes a grant can subtract, offering a restrictive role placed on a principal whose workspace role already grants more. The third offers governance metadata as an access control, most often a sensitivity label where a permission belongs; the one documented exception is the protection-policy case above, which a stem has to name explicitly.

When two answers both look defensible, prefer the one that grants less. A correctly scoped answer in this domain is almost always the narrowest layer that still satisfies the stated requirement.