PL-300 Prepare the data Practice Question
You are a Power BI developer at a healthcare organization. You are building a report that must comply with HIPAA regulations. You need to ensure that patient data is not exposed to unauthorized users. You plan to use Row-Level Security (RLS) with roles defined in Power BI Desktop. However, you also need to limit the data imported into the model to only necessary columns. The source is an Azure SQL Database with a table 'Patients' containing columns: PatientID, Name, SSN, Diagnosis, AdmissionDate, DischargeDate. Which two actions should you take? (Choose TWO)
⚠ Common exam trap
Many exam-takers confuse data security measures (like encrypted connections or credential storage) with data minimization and access control, leading them to select options that protect data in transit or enable refresh but do not directly limit imported columns or enforce row-level filtering.
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
✓
Create RLS roles to restrict access by Diagnosis.
Option A is correct because defining RLS roles in Power BI Desktop and mapping them to users in the Power BI service enforces row-level filtering so that each user only sees the patient rows they are authorized to view, which is a core HIPAA minimum-necessary access control. Option E is correct because removing SSN and Name in Power Query before loading implements data minimization, ensuring sensitive identifiers are never imported into the semantic model where they could be exposed. Option B is not correct because storing credentials in the Power BI service is a connectivity/authentication practice, not a data-exposure control for this scenario. Option C is not correct because disabling query caching does not restrict which data is imported or who can see it. Option D is not correct because an encrypted connection protects data in transit but does not limit imported columns or enforce row-level access for report consumers.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create RLS roles to restrict access by Diagnosis.
Why this is correct
Creating row-level security (RLS) roles with a DAX filter on the Diagnosis field dynamically restricts which rows each user or role can view. This ensures that a user assigned to a specific role only sees patient records matching authorized diagnoses, directly preventing unauthorized data exposure at the row level. RLS is evaluated at query time in the Power BI service, making it a robust access-control mechanism that works regardless of how the report is accessed.
- ✗
Store data source credentials in the Power BI service.
Why it's wrong here
Storing data source credentials in the Power BI service simply allows the service or an on-premises gateway to authenticate to the underlying database when refreshing data. This configuration does not impose any restrictions on what a viewer can see in the published reports; any user with access to the dataset can still see the full dataset unless a separate security layer like RLS is applied. Credential management is about connectivity, not about user-level authorization, so it does not protect sensitive diagnosis-specific data from unauthorized viewers.
- ✗
Disable query caching for the dataset.
Why it's wrong here
Disabling query caching for the dataset changes how Power BI caches query results to improve performance, but it has no bearing on data exposure or security. Query caching only affects the speed of dashboard tiles and report loads by reusing cached datasets; it does not alter row-level security, column visibility, or user permissions. Therefore, disabling it is a performance tuning decision that does nothing to prevent unauthorized users from seeing sensitive data.
- ✗
Use encrypted connection to the database.
Why it's wrong here
Using an encrypted connection to the database, such as TLS or SSL, secures data in transit between the database and the Power BI service or on-premises gateway. However, encryption protects against interception during transmission; it does not govern which rows or columns a report viewer is permitted to see after the data arrives in Power BI. Since the requirement is to prevent unauthorized users from viewing diagnosis-specific information, encryption alone is insufficient and does not address user-level access control.
- ✓
Remove the SSN and Name columns in Power Query before loading.
Why this is correct
Removing the SSN and Name columns in Power Query before loading ensures that personally identifiable information (PII) is never part of the Power BI dataset, eliminating the risk of that data being displayed or exported by any user. This data-minimization approach directly addresses sensitive data exposure by excluding the columns entirely, but it does not provide per-user row filtering. When combined with RLS, this technique forms a layered security strategy, but on its own it only removes categories of data, not restricts access by diagnosis.
Go deeper
Related to this question
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 →
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.