Implement Row-Level and Object-Level Security for PII
You are connecting to a data source that contains Personally Identifiable Information (PII). You need to ensure that only authorized users can view the data in Power BI reports. Which TWO actions should you take?
Quick Answer
Implementing object-level security to hide entire sensitive tables, alongside row-level security to restrict which rows a given user can see within the tables they can still access, is the answer because PII protection in Power BI usually needs to work at two different levels of granularity at once. Row-level security operates inside a table: you define roles in Power BI Desktop, write DAX filters that describe which rows each role should see, and then map users to those roles once the report is published to the service, so two users looking at the same report can see entirely different subsets of rows. Object-level security operates a level above that, controlling whether a user can see a table or column at all, which matters when an entire table, or a column holding sensitive PII, should be invisible to some users rather than merely filtered. Used together, OLS keeps unauthorized users from even knowing certain sensitive fields exist, while RLS makes sure that within the fields someone can see, they only see the rows relevant to them. When a scenario involves protecting sensitive data at both the table/column level and the row level simultaneously, expect the answer to combine OLS and RLS rather than relying on either mechanism alone.
⚠ Common exam trap
A common mix-up: candidates confuse data masking (Option B) with dynamic security, not realizing that Power Query masking is irreversible and applies to all users, whereas RLS and OLS provide granular, user-specific access control without altering the underlying data.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Define row-level security (RLS) roles in Power BI Desktop.
Row-Level Security (RLS) allows you to restrict data access at the row level based on user roles defined in Power BI Desktop. By creating roles and using DAX filters, you can ensure that only authorized users see specific rows of PII data when the report is published to the Power BI service and users are mapped to roles.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable encryption at rest for the dataset.
Why it's wrong here
Encryption at rest protects data from unauthorized physical access but does not control user permissions.
- ✗
Use Power Query to mask PII columns by replacing values with '***'.
Why it's wrong here
Masking in Power Query is static and applies to all users; it does not provide granular access control.
- ✓
Define row-level security (RLS) roles in Power BI Desktop.
Why this is correct
RLS filters data for users based on their role, restricting access to rows they are authorized to see.
- ✗
Apply sensitivity labels to the dataset.
Why it's wrong here
Sensitivity labels classify data but do not enforce access restrictions at the row level.
- ✓
Implement object-level security (OLS) to hide sensitive tables from certain users.
Why this is correct
OLS can hide entire tables or columns from unauthorized users, complementing RLS.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PL-300 question from scratch — 217 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PL-300
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. You are configuring a Power BI dataset with row-level security (RLS) using a JSON policy. The exhibit shows an RLS configuration. A user 'analyst@contoso.com' has access to the 'Orders' table. However, when the user views the report, no data is displayed. What is the most likely cause?
hard- A.The user's email domain does not match the data source.
- B.The connection string uses Integrated Security, which requires a gateway.
- ✓ C.The RLS policy is missing a filter expression to allow rows.
- D.The table name 'Orders' is misspelled.
Why C: The RLS policy shown in the exhibit lacks a filter expression that defines which rows the user is allowed to see. In Power BI, a row-level security policy must include a DAX filter that returns a table of allowed rows; without it, the policy effectively denies all rows to the user. The user 'analyst@contoso.com' has access to the 'Orders' table, but the missing filter means no rows pass the security check, resulting in an empty report.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PL-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-300 exam.