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?
STORED PROCEDURE
CONSTRAINT
SCHEMA
FUNCTION Correct Answer
Community Votes
D
100%
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.