A security predicate function is the warehouse object behind row-level security
Configure security and governance
AnswerCorrect 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.
You have a Fabric warehouse named DW1. DW1 contains a table that stores sales data and is used by multiple sales representatives. You plan to implement row-level security (RLS). You need to ensure that the sales representatives can see only their respective data. Which warehouse object do you require to implement RLS?
100% of anonymous learners picked answer D.
Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
Looking for RLS in stored procedures or constraints; neither can serve as the per-row predicate that a security policy evaluates for every query.
Community Discussion (4 comments)
QAZdbarhate12345678👍 5Selected: D
To 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.
Adriel_1996👍 1Selected: 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👍 1Selected: D
you create a predicate function which gets evaluated to filter user access to certain rows in a Yes or No manner
No comments yet — spotted an error or have a note? Share it below.
Log in to comment, report an error, or add a note about this question.
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.