Courseiva
Manage and secure Power BI →mediumMultiple Choice

PL-300 Manage and secure Power BI Practice Question

You have a Power BI dataset that uses DirectQuery to a SQL Server data warehouse. You need to ensure that when users view reports, they see only data relevant to their department. The data warehouse contains a 'Department' column. What should you implement?

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 and assign users.

The correct option is D: defining row-level security (RLS) roles in Power BI Desktop and assigning users, because RLS filters rows at query time based on the user's identity, so each user sees only the rows matching their department in the 'Department' column, and it works with DirectQuery by translating the filter into the source query. This is the standard, scalable way to enforce per-user data visibility in a single dataset. Option A only controls how credentials are passed to the source and does not by itself filter rows by department. Option B is inefficient and does not use a single governed dataset, and Option C, object-level security, restricts access to tables or columns rather than filtering rows by department value.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Configure the data source credentials to pass the user's identity.

    Why it's wrong here

    Configuring the data source credentials to pass the user's identity (e.g., SSO) only routes the authenticated identity to the SQL Server for database-level authentication and permissions. It does not define any row-level filtering within the Power BI dataset; after the query executes, the entire result set is returned to Power BI, and without RLS roles, every user sees all rows. Credential passthrough addresses 'who can access the source', not 'which rows of that source a specific user may see'.

  • ✗

    Create separate datasets for each department and grant access accordingly.

    Why it's wrong here

    Creating separate datasets for each department multiplies maintenance overhead, refresh schedules, and security configurations, and it fractures the data model into silos that prevent cross-departmental analysis. This approach also fails when a single user belongs to multiple departments or when department membership changes over time, requiring new datasets and re-granting of access for every change. RLS is the intended scalable solution because it centralizes security in one dataset via roles, reducing duplication and administrative effort.

  • ✗

    Implement object-level security (OLS) on the 'Department' column.

    Why it's wrong here

    Object-level security (OLS) on the 'Department' column hides the entire column from a role, but it does not restrict which rows are visible; users would still see all records, just without the Department name displayed. OLS is a model-level security feature designed to limit metadata (columns, tables, or measures), not data rows, and it is typically used in conjunction with RLS to provide a full security layer. Applying OLS alone would leak rows from other departments, so it cannot satisfy the requirement to show only each department's data.

  • ✓

    Define row-level security (RLS) roles in Power BI Desktop and assign users.

    Why this is correct

    Define row-level security (RLS) roles in Power BI Desktop by creating a role with a DAX filter—such as an expression using USERPRINCIPALNAME() or a mapping table—that filters the dataset to only the rows relevant to the signed-in user. After publishing, assign users or groups to the role in the Power BI Service, and the filter is automatically applied to all report consumers. This is the standard, supported approach for row-level access in a single dataset, and it works across DirectQuery and Import modes.

About these practice questions

Courseiva writes every PL-300 question from scratch — 524 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 →

How Courseiva writes practice questions · Editorial policy

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.