Curators at each of the archives network's regional branches should see only the inter-branch loan records for their own branch when they query a shared Warehouse table, based on their signed-in identity, with no separate table per branch. Which security feature should the team implement on the table?

Row-level security (RLS) in a Fabric Warehouse is implemented with a security predicate function tied to a view or inline table-valued function, which is then bound to the underlying table through a security policy. The predicate typically compares a column value — here, branch identifier — against a value derived from the querying user's identity (such as their security-group membership), so every curator issues the same query but the engine transparently filters rows before returning results. A OneLake data access role restricts access at the item or folder/table level, not row-by-row within one table, so it can't isolate branches inside a single shared table. Dynamic data masking changes how column values appear (e.g., obscuring digits) but never removes entire rows, so a curator would still see every branch's rows, just with a masked column. Object-level security denies or grants access to a whole table object — exactly the opposite of what's needed here, since curators must still see the table, just a filtered slice of it. To validate the policy, an engineer should query the table as two different branch users and confirm each sees only their own branch's loan rows.