Tag: Power BI Security

Business Intelligence, Data Governance, Data Security, Microsoft Certification, PL-300, Power BI

Practice Questions: Apply Sensitivity Labels (PL-300 Exam Prep)

 
This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections: 
Manage and secure Power BI (15–20%) 
    --> Secure and govern Power BI items 
        --> Apply sensitivity labels

Below are 10 practice questions (with answers and explanations) for this topic of the exam. 
There are also 2 practice tests for the PL-300 exam with 60 questions each (with answers) available on the hub.

Practice Questions

Question 1

What is the primary purpose of sensitivity labels in Power BI?

A. To restrict which rows of data users can see
B. To control workspace access
C. To classify and protect sensitive data
D. To improve report performance

Correct Answer: C

Explanation:
Sensitivity labels are used to classify data based on sensitivity and enable protection and governance—not to control access or filter data.

Question 2

Where are sensitivity labels created and managed?

A. Power BI Desktop
B. Power BI Service
C. Microsoft Purview (Microsoft 365 compliance portal)
D. Microsoft Entra ID

Correct Answer: C

Explanation:
Sensitivity labels are centrally defined and managed in Microsoft Purview. Power BI only consumes and applies them.

Question 3

Which Power BI items can have sensitivity labels applied? (Select all that apply)

A. Semantic models
B. Reports
C. Dashboards
D. Measures

Correct Answer: A, B, C

Explanation:
Labels can be applied to semantic models, reports, and dashboards, but not to individual measures or columns.

Question 4

What happens when a report is created using a labeled semantic model?

A. The report ignores the label
B. The report automatically inherits the label
C. The report applies Row-Level Security
D. The report requires Admin approval

Correct Answer: B

Explanation:
Sensitivity labels inherit and propagate to downstream content such as reports.

Question 5

Which statement about sensitivity labels is true?

A. Sensitivity labels filter data at query time
B. Sensitivity labels replace Row-Level Security
C. Sensitivity labels classify content but do not restrict row visibility
D. Sensitivity labels control workspace membership

Correct Answer: C

Explanation:
Sensitivity labels classify data and support protection but do not filter rows or control access.

Question 6

A user exports data from a labeled Power BI report to Excel. What is the expected behavior?

A. The label is removed
B. The label remains and is applied to the Excel file
C. Export is blocked automatically
D. RLS is disabled

Correct Answer: B

Explanation:
Sensitivity labels propagate to exported files, helping protect data outside Power BI.

Question 7

Which scenario best demonstrates the value of sensitivity labels?

A. Limiting data visibility by region
B. Preventing users from editing reports
C. Ensuring confidential data remains protected when shared or exported
D. Reducing dataset refresh times

Correct Answer: C

Explanation:
Sensitivity labels help protect data beyond Power BI by enforcing classification and downstream protections.

Question 8

Which Power BI security feature should be used instead of sensitivity labels to restrict rows of data?

A. Workspace roles
B. Object-Level Security
C. Row-Level Security
D. Build permission

Correct Answer: C

Explanation:
Row-Level Security (RLS) restricts which rows users can see. Sensitivity labels do not.

Question 9

Where can sensitivity labels be applied by a user?

A. Only in Power BI Desktop
B. Only in the Power BI Service
C. In both Power BI Desktop and Power BI Service
D. Only by Power BI Admins

Correct Answer: C

Explanation:
Sensitivity labels can be applied or updated in both Desktop and the Service, depending on permissions.

Question 10

Which statement best describes how sensitivity labels fit into Power BI security?

A. They replace workspace roles and RLS
B. They are optional and unrelated to governance
C. They complement other security features by supporting data classification
D. They are only used for auditing

Correct Answer: C

Explanation:
Sensitivity labels are part of a layered security and governance approach, complementing permissions, RLS, and workspace roles.

Final PL-300 Exam Reminders

  • Sensitivity labels are about classification and protection, not access control
  • Labels are created in Microsoft Purview, applied in Power BI
  • Labels propagate to reports and exported files
  • Labels work alongside RLS and permissions—not instead of them

Go back to the PL-300 Exam Prep Hub main page

Business Intelligence, Data Governance, Data Security, Microsoft Certification, PL-300, Power BI

Apply Sensitivity Labels (PL-300 Exam Prep)

 
This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Manage and secure Power BI (15–20%)
   --> Secure and govern Power BI items
      --> Apply sensitivity labels

Note that there are 10 practice questions (with answers and explanations) for each topic of the exam.
There are also 2 practice tests for the PL-300 exam with 60 questions each (with answers) available on the hub.

Overview

Applying sensitivity labels is an important governance capability within Power BI and a tested topic in the “Manage and secure Power BI (15–20%)” domain of the PL-300: Microsoft Power BI Data Analyst certification exam. Sensitivity labels help organizations classify, protect, and control the handling of data across Power BI content and the broader Microsoft ecosystem.

For the exam, you should understand what sensitivity labels are, where they come from, how and where they are applied, what they do (and do not) enforce, and how they support data governance and compliance.

What Are Sensitivity Labels?

Sensitivity labels are metadata tags used to classify data based on its level of sensitivity, such as:

  • Public
  • Internal
  • Confidential
  • Highly Confidential

They are part of Microsoft Purview Information Protection (formerly Microsoft Information Protection) and are used consistently across Microsoft services, including:

  • Power BI
  • Microsoft Excel, Word, and PowerPoint
  • SharePoint and OneDrive

Key Concept: Sensitivity labels are about data classification and protection, not row-level filtering.

Purpose of Sensitivity Labels in Power BI

Sensitivity labels help organizations:

  • Identify sensitive or regulated data
  • Apply consistent data classification standards
  • Enforce downstream protections (e.g., encryption, restrictions)
  • Improve visibility and compliance reporting
  • Reduce the risk of data leakage

From an exam perspective, labels support governance, not access control.

Where Sensitivity Labels Come From

Sensitivity labels are:

  • Defined centrally in Microsoft Purview (via the Microsoft 365 compliance portal)
  • Created and managed by security or compliance administrators
  • Made available to Power BI through tenant settings

Power BI does not create labels—it only consumes and applies them.

Power BI Items That Can Be Labeled

Sensitivity labels can be applied to:

  • Semantic models
  • Reports
  • Dashboards
  • Dataflows
  • Excel files connected to Power BI datasets

Exam Tip: Labels are applied to items, not to individual columns or rows.

How Sensitivity Labels Are Applied

Manual Application

Users can manually apply sensitivity labels:

  • In Power BI Desktop
  • In the Power BI Service

Typically:

  • A label dropdown is available
  • Users select the appropriate classification
  • The label is saved as metadata on the item

Automatic / Default Labeling (Awareness Level)

Organizations may configure:

  • Default labels for new content
  • Mandatory labeling, requiring a label before saving or publishing

These configurations are handled outside Power BI but affect user behavior inside it.

Inheritance and Propagation

Sensitivity labels can inherit and propagate across Power BI content.

Examples:

  • A report inherits the label from its semantic model
  • Exported data (e.g., to Excel) retains the sensitivity label
  • Downstream files carry the classification

Exam Focus: Labels help maintain data classification beyond Power BI.

What Sensitivity Labels Do NOT Do

This distinction is frequently tested.

Sensitivity labels:

  • ❌ Do not filter rows (that’s RLS)
  • ❌ Do not control who can open reports
  • ❌ Do not replace workspace roles or permissions

Sensitivity labels:

  • ✅ Classify content
  • ✅ Enable downstream protection
  • ✅ Support compliance and governance

Sensitivity Labels vs Other Security Features

FeaturePurpose
Workspace rolesControl who can access content
RLSRestrict which rows users can see
Object-Level SecurityHide tables or columns
Sensitivity labelsClassify and protect data

PL-300 Focus: Understand how sensitivity labels complement, not replace, other security features.

Enforcement and Protection (Conceptual Awareness)

Depending on configuration, sensitivity labels may enforce:

  • Encryption of exported files
  • Restrictions on sharing
  • Watermarking or headers in documents
  • Limited access outside the organization

In Power BI, enforcement is typically indirect, affecting data after it leaves the service.

Applying Labels in Power BI Desktop vs Service

Power BI Desktop

  • Labels can be applied during report or model development
  • Labels are published with the content

Power BI Service

  • Labels can be applied or updated after publishing
  • Admins may enforce labeling policies

Governance Best Practices

  • Use sensitivity labels consistently across content
  • Align labels with organizational data policies
  • Apply labels at the semantic model level where possible
  • Educate users on correct label usage
  • Combine labels with RLS and permissions for layered security

Common Exam Scenarios

You may be asked to determine:

  • How to classify confidential data in Power BI
  • What happens when data is exported from a labeled report
  • Whether labels restrict user access
  • Which feature supports data classification and compliance

Key Takeaways for the PL-300 Exam

  • Sensitivity labels classify data by sensitivity level
  • Labels are created in Microsoft Purview, not Power BI
  • Power BI supports applying labels to multiple item types
  • Labels propagate to downstream content
  • Sensitivity labels support governance, not row-level filtering
  • Labels complement RLS, permissions, and workspace roles

Practice Questions

Go to the Practice Questions for this topic.

BI Administration, Data Security, Microsoft Certification, PL-300, Power BI

Configure Item-Level Access in Power BI (PL-300 Exam Prep)

 
This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Manage and secure Power BI (15–20%)
   --> Secure and govern Power BI items
      --> Configure Item-Level Access

Note that there are 10 practice questions (with answers and explanations) at the end of each topic. Also, there are 2 practice tests with 60 questions each available on the hub below all the exam topics.

Overview

Item-level access in Power BI controls who can access specific Power BI items—such as reports, dashboards, semantic models (datasets), and apps—and what actions they can perform on those items.

This topic is part of the Manage and secure Power BI (15–20%) exam domain and falls specifically under Secure and govern Power BI items, making it a critical governance concept for PL-300 candidates.

Unlike workspace roles (which define broad permissions across an entire workspace), item-level access allows more granular control over individual Power BI assets.

What Is Item-Level Access?

Item-level access refers to permissions assigned directly to individual Power BI items, independent of workspace roles. These permissions determine whether users can:

  • View an item
  • Share an item
  • Build new content using an item
  • Reshare or export data
  • Modify or manage the item

Item-level access is commonly configured for:

  • Reports
  • Dashboards
  • Semantic models (datasets)
  • Apps (indirectly through audience access)

Why Item-Level Access Matters (Exam Perspective)

From a PL-300 standpoint, item-level access is important because it helps:

  • Enforce principle of least privilege
  • Enable self-service BI safely
  • Separate content creation from content consumption
  • Support enterprise governance without duplicating workspaces

Expect exam questions that test when to use item-level permissions instead of workspace roles, and how item-level access interacts with security features like RLS.

Configuring Item-Level Access by Item Type

1. Report-Level Access

Reports can be shared directly with users or groups.

Key capabilities:

  • View report
  • Share report (optional)
  • Build new content (if underlying model allows it)

How it’s configured:

  • Use the Share button on a report
  • Assign access to users, security groups, or distribution lists

Important exam note:
Sharing a report does not automatically grant access to the underlying semantic model unless explicitly allowed.

2. Dashboard-Level Access

Dashboards are typically shared for executive or summary-level consumption.

Key characteristics:

  • View-only by default
  • No data modeling or editing
  • Tiles link back to underlying reports (which require separate access)

Exam tip:
Users must also have access to the source reports behind dashboard tiles to avoid broken visuals.

3. Semantic Model (Dataset) Item-Level Access

Semantic models support some of the most important item-level permissions.

Key permissions:

  • Read – view reports using the model
  • Build – create new reports or analyze in Excel
  • Reshare – share the dataset with others

Common use case:

  • Grant Build permission to analysts so they can create their own reports without modifying the dataset.

Exam highlight:
The Build permission is essential for self-service BI scenarios and is frequently tested.

4. App Access (Audience-Based)

Apps use audiences to control item-level visibility.

What audiences allow you to do:

  • Show different content to different user groups
  • Hide specific reports or dashboards
  • Control navigation and access without duplicating content

Best practice:

  • Use Azure AD security groups for app audiences.

Item-Level Access vs Workspace Roles

FeatureWorkspace RolesItem-Level Access
ScopeEntire workspaceIndividual items
GranularityCoarseFine-grained
Best forContent creators/adminsConsumers & self-service
Exam focusGovernanceSecurity precision

Key exam takeaway:
Workspace roles control what users can do, while item-level access controls what items they can access.

Item-Level Access and Row-Level Security (RLS)

These two are often confused on the exam.

  • Item-level access controls access to content
  • RLS controls data visibility within content

They are complementary, not interchangeable.

Example scenario:

  • Item-level access → Can the user open the report?
  • RLS → What rows of data does the user see after opening it?

Best Practices for Configuring Item-Level Access

  • Use Azure AD security groups instead of individuals
  • Grant Build permission carefully
  • Avoid oversharing datasets
  • Combine item-level access with RLS for data security
  • Prefer apps and audiences for large-scale distribution

Common Exam Traps to Watch For

  • Assuming report sharing grants dataset access automatically
  • Confusing workspace roles with item permissions
  • Forgetting that dashboard tiles require report access
  • Overlooking Build permission in self-service scenarios

Summary for PL-300 Exam Readiness

To succeed on PL-300 questions about item-level access, you should be able to:

✔ Identify when item-level access is required
✔ Configure permissions for reports, dashboards, and datasets
✔ Understand Build vs Read permissions
✔ Explain how item-level access differs from workspace roles
✔ Combine item-level access with RLS appropriately

Practice Questions

Go to the Practice Questions for this topic.