A security predicate function is the warehouse object behind row-level security
Short answer
D Warehouse RLS uses a security policy bound to an inline table-valued FUNCTION that filters rows so each sales representative sees only their own data.
Question
Key Takeaways
Warehouse RLS is a predicate FUNCTION plus a SECURITY POLICY: the function decides whether each row is visible to the current user, and the policy binds it to the table.
Implementing row-level security in a Fabric warehouse requires a user-defined inline table-valued FUNCTION that encodes the filter predicate; a security policy then applies that function to the sales table so each representative sees only their own rows.
Common mistake: Looking for RLS in stored procedures or constraints; neither can serve as the per-row predicate that a security policy evaluates for every query.
Expert Analysis
Why the Answer Is Correct
Row-level security in a Fabric warehouse is defined with a CREATE SECURITY POLICY statement that references a user-defined inline table-valued FUNCTION acting as the predicate. The function encapsulates the filtering logic, for example comparing a sales-representative column to USER_NAME, and returns whether each row is visible, so representatives see only their own data.
Why the Other Options Are Wrong
Option A (stored procedure) runs procedural logic on demand but cannot be attached to a security policy as a row filter. Option B (constraint) enforces data integrity on writes, not per-user read filtering. Option C (schema) is a namespace for objects and provides no row-level logic.
Community Comment Notes
The community is unanimous (D 100). QAZdbarhate12345678 (5 likes) explains a UDF is created and associated with the RLS policy, and Adriel_1996 pastes the canonical pattern of creating a Security schema function and then a security policy from Microsoft's row-level security tutorial.
Official Reference
https://learn.microsoft.com/en-us/fabric/data-warehouse/tutorial-row-level-security
This link opens the official vendor documentation in a new tab.
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 4 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 4
-
QAZdbarhate12345678 👍 5 Answered DTo implement Row-Level Security (RLS) in a Fabric warehouse like DW1, need to use a FUNCTION to define the filtering logic. Specifically, a user-defined function (UDF) is created and associated with the RLS policy to determine which rows each user can access.
-
Tuki93 👍 2 Answered Dhttps://learn.microsoft.com/en-us/fabric/data-warehouse/tutorial-row-level-security#2-define-security-policies
-
Adriel_1996 👍 1 Answered D-- Creating schema for Security CREATE SCHEMA Security; GO -- Creating a function for the SalesRep evaluation CREATE FUNCTION Security.tvf_securitypredicate(@UserName AS varchar(50)) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS tvf_securitypredicate_result WHERE @UserName = USER_NAME() OR USER_NAME() = '[email protected]'; GO -- Using the function to create a Security Policy CREATE SECURITY POLICY YourSecurityPolicy ADD FILTER PREDICATE Security.tvf_securitypredicate(UserName_column) ON sampleschema.sampletable WITH (STATE = ON); GO
-
prabhjot 👍 1 Answered Dyou create a predicate function which gets evaluated to filter user access to certain rows in a Yes or No manner
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.