Hotspot Question You have an Azure SQL database named DB1 that contains a table named Orders. The Orders table contains a row for each sales order. Each sales order includes the name of the user who…

The correct answer is Create:: A security policy in the Orders table; Control access to the rows by using:: A table-valued function. To implement Row-Level Security (RLS) in Azure SQL Database, you must create a security policy and define a table-valued function to control row access based on user identity.

Submitted by helene.fr· Mar 6, 2026Implement a secure environment

Question

Hotspot Question You have an Azure SQL database named DB1 that contains a table named Orders. The Orders table contains a row for each sales order. Each sales order includes the name of the user who placed the order. You need to implement row-level security (RLS). The solution must ensure that the users can view only their respective sales orders. What should you include in the solution? To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Answer:

Exhibits

Answer Area

Create:A security policy in the Orders table
A materialized view in DB1A security policy in the Orders tableDatabase scoped credentials in DB1
Control access to the rows by using:A table-valued function
A masking ruleA table-valued functionThe CONTAINS predicate

Explanation

To implement Row-Level Security (RLS) in Azure SQL Database, you must create a security policy and define a table-valued function to control row access based on user identity.

Approach. To implement Row-Level Security (RLS) that ensures users only view their own sales orders in an Azure SQL database, two main components are required:

Create: A security policy in the Orders table: A security policy is the fundamental object in SQL Server and Azure SQL Database used to implement RLS. It contains one or more security predicates and binds them to target tables (in this case, the Orders table) to filter rows based on the user's context.
Control access to the rows by using: A table-valued function: RLS predicates are typically defined using inline table-valued functions. This function encapsulates the logic that determines which rows a user can access (e.g., comparing a user column in Orders to the SESSION_USER or CURRENT_USER). The security policy then applies this function as a filter predicate to the Orders table, ensuring only relevant rows are returned to the user.

Common mistakes.

common_mistake. Common mistakes include confusing RLS with other security features or misunderstanding the components required:

Materialized view: Materialized views are for performance optimization by pre-computing query results, not for enforcing row-level security or access control.
Database scoped credentials: These are used for authenticating to external resources (like Azure Blob Storage) from within the database and are unrelated to filtering rows based on user identity.
Masking rule: Dynamic Data Masking (DDM) is used to obscure sensitive column data (e.g., showing only the last 4 digits of a credit card number), not to filter rows based on who the user is. It addresses data obfuscation, not access control at the row level.
The CONTAINS predicate: This is a full-text search function used for querying text columns and has no role in implementing RLS for user-specific row access.

Concept tested. The core concept tested is the implementation of Row-Level Security (RLS) in Azure SQL Database (or SQL Server), specifically understanding the primary components: security policies and predicate functions (typically inline table-valued functions) used to filter rows based on user context.

Reference. https://learn.microsoft.com/en-us/sql/relational-databases/security/row-level-security?view=sql-server-ver16

Topics

#row-level security#security policy#table-valued function#predicate-based access

Community Discussion

No community discussion yet for this question.

Full DP-300 Practice