Which Warehouse Object Implements Row-Level Security in Fabric?

DP-700 By islever Editorial Last updated

Configure security and governance

Short answer

D Create a user-defined FUNCTION that returns a predicate evaluated per user, then bind it as the filter predicate of a security policy on the DW1 sales table.

Question

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?
  1. STORED PROCEDURE
  2. CONSTRAINT
  3. SCHEMA
  4. FUNCTION Correct Answer

Key Takeaways

The question tests knowledge that RLS filtering logic lives in a schemabound inline table-valued FUNCTION used as a filter predicate — the trap is picking SCHEMA because RLS is often loosely described as organizing access.

Row-level security in a Microsoft Fabric warehouse is built from a user-defined function that returns a yes/no predicate for each row, which is then bound to the table through a security policy. This page confirms that the FUNCTION is the required warehouse object, and explains why schemas, constraints, and stored procedures do not provide RLS filtering.

Common mistake: The most common wrong choice is C (SCHEMA), because learners associate row filtering with organizing objects into security schemas; a schema only groups database objects and cannot evaluate USER_NAME() to allow or deny individual rows.

Expert Analysis

Why the Answer Is Correct

A FUNCTION is the required object because RLS in a Fabric warehouse is implemented by creating a user-defined inline table-valued function (for example, Security.tvf_securitypredicate) that returns a row only when USER_NAME matches the row's owner column. That function is then referenced as the FILTER PREDICATE of a CREATE SECURITY POLICY statement applied to the sales table, so each sales representative only sees their own rows. Without the predicate function there is nothing for the security policy to evaluate, making the function the indispensable warehouse object the question asks for. The official Microsoft tutorial for row-level security in the data warehouse follows exactly this sequence: define the function, then define the security policy.

Why the Other Options Are Wrong

A SCHEMA (C) is only a logical container used to organize tables, procedures, and policies; creating a "Security" schema is a supporting step but it performs no row filtering on its own. A CONSTRAINT (B), such as CHECK or FOREIGN KEY, validates or relates data at write time and cannot vary its evaluation per connected user, so it cannot restrict rows by identity. A STORED PROCEDURE (A) can run imperative T-SQL, but RLS filtering must apply transparently to every query against the table, including ad-hoc SELECTs from reporting tools, which only a predicate function bound through a security policy guarantees. Stored procedures and schemas may appear in an RLS script, yet neither is the object that defines the row-access rule.

Community Comment Notes

Every commenter selected D, with Adriel_1996 posting a full script that creates a schema, then a function, then a security policy, illustrating that the function carries the predicate logic. QAZdbarhate12345678 wrote that you "need to use a FUNCTION to define the filtering logic," and prabhjot noted you "create a predicate function which gets evaluated to filter user access to certain rows in a Yes or No manner." Tuki93 linked the Microsoft tutorial on defining security policies, while Mustafa_Shazly observed that a schema is used "to organize database objects only," which is precisely why C fails. The consensus matches the official documentation, so the community majority here is reliable.

Official Reference

https://learn.microsoft.com/en-us/fabric/data-warehouse/tutorial-row-level-security#2-define-security-policies

This link opens the official vendor documentation in a new tab.

Exam Strategy

On DP-700 RLS questions, remember the two-object pattern: a predicate function defines the rule and a security policy applies it; if only one object is asked for, it is the function. Ignore objects that merely organize or validate data, since they cannot vary results by user identity.

Frequently Asked Questions

Why isn't a SCHEMA enough to implement row-level security in DW1?

A schema only groups database objects such as tables and policies; it has no logic that can test USER_NAME() and allow or deny individual rows of the sales table.

How does the RLS function relate to the security policy?

The function implements the filter predicate logic, and CREATE SECURITY POLICY binds that function to the table so every query is filtered automatically for the connected user.

More DP-700 FAQ →

Discussion 9 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 9

  1. Adriel_1996 👍 15 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
  2. QAZdbarhate12345678 👍 15 Answered 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.
  3. Tuki93 👍 3 Answered D
    https://learn.microsoft.com/en-us/fabric/data-warehouse/tutorial-row-level-security#2-define-security-policies
  4. Wipag 👍 2 Answered D
    To implement Row-Level Security (RLS) in a Microsoft Fabric warehouse (DW1), you need to define a security policy that uses a user-defined function to filter rows based on the current user.
  5. prabhjot 👍 2 Answered D
    you create a predicate function which gets evaluated to filter user access to certain rows in a Yes or No manner
Show 4 more comments
  1. alqazqzy.asseel 👍 1 Answered D
    To implement RLS in warehouse we should first define a FUCNTION with filtering parameters in this case can be for example the user email, then create SECURITY POLICY that define the defined function as FILTER PREDICATE
  2. Mustafa_Shazly 👍 1 Answered D
    D apply security but we used it when applying RLS schema to organize database objects only.
  3. Josekonoor 👍 1 Answered D
    for RLS at SQL world, function to be used
  4. smanzana 👍 1 Answered D
    Función or Security Policy

Reader comments & corrections

No reader corrections 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.

A 500-million-row fact table exceeds the F32 Direct Lake guardrail, so increase the capacity to F64

S-grade

Shortcut caching supports only S3/GCS shortcuts and excludes files larger than 1 GB

S-grade

Updating warehouse tables requires at least the Contributor workspace role because Write is not shareable to a Viewer

S-grade

Run T-SQL in a KQL database only by prefixing the query with a -- comment line

S-grade

← Back to DP-700 Study Guide