Category: Power BI

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

Implement Row-Level Security (RLS) Roles (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
      --> Implement Row-Level Security (RLS) Roles

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

Implementing Row-Level Security (RLS) is a critical skill for Power BI Data Analysts and a key topic within the “Manage and secure Power BI (15–20%)” domain of the PL-300: Microsoft Power BI Data Analyst certification exam. RLS ensures that users only see the data they are authorized to view, even when accessing the same reports or semantic models.

For the exam, you must understand how RLS roles are created, how they are implemented using DAX, how users and groups are assigned, and how RLS behaves in the Power BI Service.

What Is Row-Level Security?

Row-Level Security restricts access to specific rows of data in a semantic model based on the identity of the user viewing the report.

RLS:

  • Is defined in Power BI Desktop
  • Uses DAX filter expressions
  • Is enforced in the Power BI Service
  • Applies to all reports that use the semantic model

Key Concept: RLS controls data visibility, not report visibility.

RLS Architecture in Power BI

The RLS workflow consists of four main steps:

  1. Define roles in Power BI Desktop
  2. Create DAX filter expressions for tables
  3. Publish the semantic model to the Power BI Service
  4. Assign users or groups to roles in the Service

Each role defines which rows are visible when the user is a member of that role.

Creating RLS Roles in Power BI Desktop

Step 1: Create Roles

In Power BI Desktop:

  • Go to Model view or Report view
  • Select Modeling → Manage roles
  • Create one or more roles (e.g., SalesWest, SalesEast)

Roles are placeholders until users or groups are assigned in the Power BI Service.

Step 2: Define Table Filters (DAX)

RLS is implemented using DAX filter expressions applied to tables.

Example: Static RLS

[Region] = "West"

This filter ensures that users assigned to the role only see rows where Region equals West.

Exam Tip: RLS filters act like WHERE clauses and reduce visible rows—not columns.

Static vs Dynamic RLS

Static RLS

  • Filters are hardcoded values
  • Each role represents a specific segment
  • Easy to understand, but not scalable

Example:

[Department] = "Finance"

Dynamic RLS (Highly Exam-Relevant)

Dynamic RLS uses the logged-in user’s identity to filter data automatically.

Common functions:

  • USERPRINCIPALNAME()
  • USERNAME()

Example:

[Email] = USERPRINCIPALNAME()

Dynamic RLS:

  • Scales well
  • Reduces number of roles
  • Is commonly used in enterprise models

Best Practice: Use dynamic RLS with a user-to-dimension mapping table.

Assigning Users to RLS Roles (Power BI Service)

After publishing the semantic model:

  1. Go to the Power BI Service
  2. Navigate to the semantic model
  3. Select Security
  4. Assign users or Microsoft Entra ID (Azure AD) groups to roles

Best Practice: Always assign security groups, not individual users.

Testing RLS

In Power BI Desktop

  • Use Modeling → View as
  • Test roles before publishing
  • Validate DAX logic

In Power BI Service

  • Use View as role
  • Confirm correct filtering for assigned users

Exam Tip: “View as” does not bypass RLS—it simulates user access.

RLS Behavior in Common Scenarios

Reports and Dashboards

  • RLS applies automatically
  • Users cannot see restricted data
  • Visual totals reflect filtered data

Power BI Apps

  • RLS is enforced
  • No additional configuration required

Analyze in Excel / External Tools

  • RLS is enforced if the user has Build permission
  • Users cannot bypass RLS through external connections

Important RLS Limitations (Exam Awareness)

  • RLS does not hide tables or columns (use Object-Level Security for that)
  • RLS cannot be applied directly to measures
  • Workspace Admins are not exempt from RLS unless explicitly configured
  • RLS does not apply in Power BI Desktop for the model author unless using “View as”

Object-Level Security (OLS) vs RLS

FeatureRLSOLS
Controls rows✅❌
Controls columns/tables❌✅
Configured in Desktop✅❌ (External tools)
Exam depthHighAwareness only

PL-300 Focus: RLS concepts are tested far more deeply than OLS.

Governance and Best Practices

  • Use dynamic RLS wherever possible
  • Centralize security logic in the semantic model
  • Use groups, not individuals
  • Document role logic for maintainability
  • Test RLS thoroughly before sharing reports

Common Exam Scenarios

You may be asked to determine:

  • Why different users see different values in the same report
  • How to reduce the number of RLS roles
  • How to implement user-based filtering
  • Where RLS logic is created vs enforced

Key Takeaways for the PL-300 Exam

  • RLS restricts row-level data visibility
  • Roles and filters are created in Power BI Desktop
  • Users and groups are assigned in the Power BI Service
  • Dynamic RLS uses USERPRINCIPALNAME()
  • RLS applies to all reports and apps using the semantic model
  • RLS is enforced at the semantic model level

Practice Questions

Go to the Practice Questions for this topic.

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

Configure Access to Semantic Models (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 Access to Semantic Models

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

Configuring access to semantic models (formerly known as datasets) is a core responsibility of a Power BI Data Analyst and a key topic within the “Manage and secure Power BI (15–20%)” domain of the PL-300 exam. This topic focuses on how access to data models is controlled, shared, governed, and secured so that users can interact with data appropriately—without compromising data integrity or confidentiality.

For the exam, you should understand how semantic models are shared, who can access them, what level of access they have, and how security is enforced at both the model and row level.

What Is a Semantic Model in Power BI?

A semantic model is the business-ready representation of data in Power BI. It includes:

  • Tables, relationships, and hierarchies
  • Measures, calculated columns, and KPIs
  • Data formatting and metadata
  • Security rules (such as Row-Level Security)

Semantic models are published to the Power BI Service and act as the foundation for reports, dashboards, and analysis.

Access Control Concepts You Must Know

Workspace Roles

Access to semantic models is primarily governed by workspace roles in the Power BI Service:

RoleCapabilities Related to Semantic Models
ViewerCan view reports and read data (if permitted)
ContributorCan create and edit content, including reports
MemberCan publish, update, and share semantic models
AdminFull control, including managing permissions and security

Exam Tip: Viewers cannot create new reports from a semantic model unless Build permission is explicitly granted.

Semantic Model Permissions

Semantic models support item-level permissions, separate from workspace roles.

Key permissions include:

  • Read – Allows users to view data used in reports
  • Build – Allows users to create new reports using the semantic model
  • Reshare – Allows users to share the semantic model with others

These permissions can be assigned to:

  • Individual users
  • Security groups
  • Microsoft Entra ID (Azure AD) groups

Best Practice: Grant access using security groups instead of individual users for scalability and easier management.

Build Permission (Highly Exam-Relevant)

Build permission is one of the most tested concepts in this topic.

With Build permission, users can:

  • Create new reports using the semantic model
  • Use the model in Excel (Analyze in Excel)
  • Use the model via external tools (when allowed)

Without Build permission:

  • Users can view reports
  • Users cannot create new reports from the model

Build permission can be granted:

  • Automatically through workspace role (Member/Admin)
  • Manually on the semantic model
  • Via sharing settings

Sharing Semantic Models

Semantic models can be shared in several ways:

  • Through workspace access
  • By directly sharing the semantic model
  • By publishing reports that use the model
  • Via Power BI Apps

When sharing, you can choose whether recipients:

  • Can build new content
  • Can reshare the model
  • Are restricted by existing security rules

Exam Scenario: A user can view a report but cannot create their own—this often indicates missing Build permission.

Row-Level Security (RLS)

Row-Level Security restricts which rows of data a user can see within a semantic model.

Key RLS concepts:

  • Roles are defined in Power BI Desktop
  • DAX filters control row visibility
  • Users or groups are assigned to roles in the Power BI Service
  • RLS applies to all reports using the model

Types of RLS:

  • Static RLS – Fixed filters (e.g., Region = “West”)
  • Dynamic RLS – Filters based on the logged-in user (e.g., USERPRINCIPALNAME())

Important: RLS is enforced at the semantic model level, not the report level.

Object-Level Security (OLS) (Awareness Level)

While not deeply tested, you should be aware that Object-Level Security can:

  • Hide tables, columns, or measures from specific users
  • Be configured using external tools (e.g., Tabular Editor)

OLS complements RLS but is more advanced and typically managed by model developers.

Certified Dataset / Endorsed Semantic Models

To support governance, Power BI allows semantic models to be endorsed:

  • Promoted – Indicates the model is reliable and ready for reuse
  • Certified – Officially validated and approved by data owners or admins

Endorsements help users:

  • Identify trusted data sources
  • Avoid using unofficial or duplicate models

Exam Tip: Certification requires specific tenant permissions and approval workflows.

Power BI Apps and Semantic Models

When distributing content via a Power BI App:

  • Access to the semantic model is controlled through the app
  • Users can be allowed to connect to the underlying semantic model
  • RLS still applies

Apps provide a controlled, read-only distribution method while maintaining centralized security.

Common Exam Scenarios

You may be asked to determine:

  • Why a user cannot build a report from an existing model
  • How to allow self-service reporting without giving full workspace access
  • How to restrict data visibility for different users
  • Which permission or role best fits a business requirement

Key Takeaways for the PL-300 Exam

  • Semantic models are secured through workspace roles and item-level permissions
  • Build permission is essential for report creation and analysis
  • Row-Level Security controls data visibility per user
  • Use groups, not individuals, for scalable access control
  • Endorsed and certified models support governance and trust
  • Security is applied at the semantic model level, not per report

Just a FYI … this topic emphasizes balancing self-service analytics with strong data governance, a recurring theme throughout the PL-300 exam.

Practice Questions

Go to the Practice Questions for this topic.

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

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.

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

Assign Workspace Roles (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
      --> Assign Workspace Roles

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

In Power BI, workspaces are collaborative containers used to develop, manage, and distribute content such as semantic models (datasets), reports, dashboards, dataflows, and apps.
Assigning workspace roles is a core governance task that ensures users have the appropriate level of access—no more and no less—based on their responsibilities.

For the PL-300 exam, you are expected to understand:

  • The four workspace roles
  • What each role can and cannot do
  • When to assign each role
  • How workspace roles relate to security, governance, and content lifecycle

Power BI Workspace Roles

Power BI provides four predefined workspace roles:

1. Admin

Highest level of access

Admins have full control over the workspace and its contents.

Key capabilities:

  • Add or remove users and assign roles
  • Update workspace settings
  • Publish, update, and delete all content
  • Configure semantic model settings (refresh, credentials, endorsements)
  • Publish and update workspace apps
  • Delete the workspace

Typical use cases:

  • Power BI service administrators
  • BI platform owners
  • Lead analytics engineers

🔑 Exam tip: Only Admins can manage workspace access and delete a workspace.

2. Member

Content creators and managers

Members can actively create and manage content, but they cannot manage workspace access.

Key capabilities:

  • Create, edit, and delete reports and dashboards
  • Publish semantic models
  • Configure scheduled refresh
  • Publish and update workspace apps
  • Share content (depending on tenant settings)

Limitations:

  • Cannot add or remove workspace users
  • Cannot delete the workspace

Typical use cases:

  • Power BI developers
  • Data analysts responsible for production content

3. Contributor

Content creators without publishing authority

Contributors can build and modify content, but they cannot publish apps or manage access.

Key capabilities:

  • Create and edit reports and semantic models
  • Upload PBIX files
  • Modify existing content they have access to

Limitations:

  • Cannot publish or update workspace apps
  • Cannot manage workspace users
  • Cannot change workspace settings

Typical use cases:

  • Analysts building reports for review
  • Developers working in shared or pre-production workspaces

4. Viewer

Read-only access

Viewers can consume content but cannot modify anything.

Key capabilities:

  • View reports, dashboards, and apps
  • Interact with visuals (filters, slicers)
  • Export data (if allowed)

Limitations:

  • Cannot create or edit content
  • Cannot publish apps
  • Cannot configure refresh or settings

Typical use cases:

  • Business users
  • Executives and stakeholders
  • Consumers of certified content

🔑 Exam tip: Viewers require a Power BI Pro license unless the workspace is in Premium capacity.

Assigning Workspace Roles

Workspace roles are assigned in the Power BI service:

  1. Navigate to the workspace
  2. Select Access
  3. Add users or groups
  4. Assign the appropriate role (Admin, Member, Contributor, Viewer)

🔐 Best practice: Assign Azure AD security groups instead of individual users to simplify governance and reduce maintenance.

Governance and Security Considerations

Least Privilege Principle

Always assign the lowest role necessary for a user to perform their job.

  • Consumers → Viewer
  • Report authors → Contributor or Member
  • Platform owners → Admin

Separation of Duties

Use different workspaces for:

  • Development
  • Testing
  • Production

Assign higher roles in dev, more restrictive roles in prod.

Workspace Roles vs Item-Level Security

  • Workspace roles control what users can do
  • Row-level security (RLS) controls what data users can see

Both are often used together.

Common Exam Scenarios

You may see questions such as:

  • Which role allows a user to publish an app but not manage access? → Member
  • Which role is required to assign users to a workspace? → Admin
  • Which role should be assigned to report consumers? → Viewer
  • Why use Contributor instead of Member? → To prevent app publishing or access management

Key Takeaways for PL-300

  • Know all four workspace roles
  • Understand capabilities vs limitations
  • Admin = access + settings
  • Member = manage content + apps
  • Contributor = build content only
  • Viewer = consume content only
  • Assign roles strategically for security and governance

Practice Questions

Go to the Practice Questions for this topic.

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

Configure a Semantic Model Scheduled Refresh (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%)
   --> Create and manage workspaces and assets
      --> Configure a Semantic Model Scheduled Refresh

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

A semantic model scheduled refresh ensures that Power BI reports and dashboards display up-to-date data without requiring manual intervention. For the PL-300 exam, this topic focuses on understanding when scheduled refresh is supported, what prerequisites are required, and how to configure refresh settings correctly in the Power BI service.

This skill sits at the intersection of data connectivity, security, and workspace management.

What Is a Semantic Model Scheduled Refresh?

A scheduled refresh automatically reimports data into a Power BI semantic model (dataset) at defined times using the Power BI service. It applies only to Import mode and composite models with imported tables.

Scheduled refresh does not apply to:

  • DirectQuery-only models
  • Live connections to Power BI or Analysis Services

Prerequisites for Scheduled Refresh

Before configuring scheduled refresh, the following conditions must be met:

1. Dataset Must Be Published

Scheduled refresh can only be configured after publishing the semantic model to the Power BI service.

2. Valid Data Source Credentials

You must provide and maintain valid credentials for all data sources used in the dataset.

Supported authentication methods vary by source and may include:

  • OAuth
  • Basic authentication
  • Windows authentication
  • Organizational account

3. Gateway (If Required)

A gateway is required when the semantic model connects to:

  • On-premises data sources
  • Data sources in a private network
  • On-premises dataflows

Cloud-based sources (such as Azure SQL Database or SharePoint Online) do not require a gateway.

4. Import Mode Tables

At least one table in the semantic model must use Import mode. DirectQuery-only models do not support scheduled refresh.

Configuring Scheduled Refresh

Scheduled refresh is configured in the Power BI service, not in Power BI Desktop.

Key Configuration Steps

  1. Navigate to the workspace
  2. Select the semantic model
  3. Open Settings
  4. Configure:
    • Data source credentials
    • Gateway connection (if applicable)
    • Refresh schedule

Refresh Frequency and Limits

Shared Capacity

  • Up to 8 refreshes per day
  • Minimum interval of 30 minutes

Premium Capacity

  • Up to 48 refreshes per day
  • Shorter refresh intervals supported

These limits are enforced per dataset.

Refresh Options and Settings

Scheduled Refresh

Allows you to define:

  • Days of the week
  • Time slots
  • Time zone
  • Enable/disable refresh

Refresh Failure Notifications

You can configure email notifications to alert dataset owners if a refresh fails.

Incremental Refresh

Incremental refresh:

  • Requires Power BI Desktop configuration
  • Reduces refresh time by refreshing only new or changed data
  • Still depends on scheduled refresh to execute

Common Causes of Refresh Failure

  • Expired credentials
  • Gateway offline or misconfigured
  • Data source schema changes
  • Timeout due to large datasets
  • Unsupported data source authentication

Scenarios Where Scheduled Refresh Is Not Needed

  • DirectQuery datasets (data is queried live)
  • Live connections to Analysis Services
  • Manual refresh and republish workflows (not recommended for production)

Exam-Focused Decision Rules

For the PL-300 exam, remember:

  • Import mode = scheduled refresh
  • DirectQuery = no scheduled refresh
  • On-premises source = gateway required
  • Refresh settings live in the Power BI service
  • Premium capacity allows more frequent refreshes

Common Exam Traps

  • Confusing scheduled refresh with DirectQuery
  • Assuming all datasets require a gateway
  • Forgetting credential configuration
  • Thinking refresh schedules are set in Desktop

Key Takeaways

  • Scheduled refresh keeps semantic models current
  • Configuration happens in the Power BI service
  • Gateways depend on data source location
  • Capacity affects refresh frequency
  • Incremental refresh improves performance but still relies on scheduling

Practice Questions

Go to the Practice Questions for this topic.

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

Identify When a Gateway Is Required (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%)
   --> Create and manage workspaces and assets
      --> Identify When a Gateway Is Required

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

In Power BI, a data gateway acts as a secure bridge between on-premises data sources and the Power BI service in the cloud. Understanding when a gateway is required—and when it is not—is a core skill assessed in the Manage and secure Power BI section of the PL-300 exam.

This topic focuses less on installing gateways and more on decision-making: recognizing data source locations, connection modes, and refresh requirements.

What Is a Power BI Gateway?

A Power BI gateway is software installed on a local machine or server within a private network. It enables the Power BI service to:

  • Refresh data from on-premises sources
  • Query on-premises data in real time (DirectQuery or Live connection)
  • Maintain secure communication without opening inbound firewall ports

There are two main gateway types:

  • On-premises data gateway (standard) – supports multiple users and services
  • On-premises data gateway (personal) – single-user scenarios (limited use, not recommended for enterprise)

When a Gateway Is Required

You must use a gateway when both of the following are true:

  1. The data source is on-premises or in a private network
  2. The Power BI service needs to access the data after publishing

Common Scenarios That Require a Gateway

1. Scheduled Refresh from On-Premises Data

If a dataset connects to:

  • SQL Server (on-premises)
  • Oracle, Teradata, SAP
  • On-premises file shares
  • On-premises data warehouses

…and you want scheduled refresh, a gateway is required.

2. DirectQuery or Live Connections to On-Premises Sources

A gateway is required for:

  • DirectQuery to on-premises SQL Server
  • Live connections to Analysis Services (SSAS) on-premises

This applies even if no refresh schedule exists, because queries are sent at report view time.

3. On-Premises Dataflows

If a Power BI dataflow connects to on-premises data, a gateway is required to refresh the dataflow.

4. Hybrid Scenarios

If a dataset combines:

  • Cloud data (e.g., Azure SQL Database)
  • On-premises data (e.g., local SQL Server)

A gateway is still required for the on-premises portion.

When a Gateway Is NOT Required

A gateway is not needed when Power BI can access the data source directly from the cloud.

Common Scenarios That Do NOT Require a Gateway

1. Cloud Data Sources

No gateway is required for:

  • Azure SQL Database
  • Azure Synapse Analytics
  • Azure Data Lake Storage
  • SharePoint Online
  • OneDrive
  • Power BI semantic models
  • Dataverse
  • Public web data

2. Import-Only Reports Viewed in Power BI Desktop

While working only in Power BI Desktop, no gateway is needed—even for on-premises data—because Desktop connects directly.

A gateway becomes relevant only after publishing.

3. Manual Refresh in Power BI Desktop

If data refresh happens manually in Desktop and the dataset is republished, no gateway is required (though this is not scalable).

Gateway and Connection Mode Summary

Connection ModeOn-Premises SourceGateway Required
Import (Scheduled Refresh)YesYes
Import (Cloud Source)NoNo
DirectQueryYesYes
Live Connection (SSAS)YesYes
Dataflows (On-Prem)YesYes
Desktop-onlyYesNo

Exam-Focused Decision Rules

For the PL-300 exam, remember these rules:

  • On-premises + Power BI Service = Gateway
  • Cloud source = No gateway
  • DirectQuery always needs a gateway if the source is on-premises
  • Desktop usage alone does not require a gateway
  • Hybrid datasets still require a gateway

Common Exam Traps

  • Assuming a gateway is needed for all refresh scenarios
  • Forgetting that Azure SQL Database does NOT require a gateway
  • Confusing publishing with refresh
  • Overlooking gateway needs for dataflows

Key Takeaways

  • Gateways are about location, not data size
  • They enable secure, outbound-only communication
  • The exam tests recognition, not installation steps
  • Focus on where the data lives and how Power BI accesses it

Practice Questions

Go to the Practice Questions for this topic.

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

Promote or certify Power BI content (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%)
   --> Create and manage workspaces and assets
      --> Promote or certify Power BI content

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

In Power BI, promoting and certifying content helps organizations establish trust, data governance, and self-service analytics at scale. These features allow users to quickly identify which datasets, reports, and dataflows are approved for reuse and suitable for decision-making.

For the PL-300 exam, you must understand:

  • The difference between promoted and certified content
  • Who can promote or certify content
  • Which Power BI artifacts support these labels
  • How promotion and certification impact discovery, reuse, and governance

What Does It Mean to Promote Content?

Promoted content indicates that an item is recommended for use, but it has not gone through a formal certification process.

Key Characteristics of Promoted Content

  • Signals good quality and usefulness
  • Often created by experienced report authors or teams
  • Does not require tenant-level approval
  • Can be promoted by:
    • Dataset owners
    • Workspace members (depending on permissions)

Supported Artifacts

  • Datasets (semantic models)
  • Dataflows
  • Reports

Common Use Cases

  • Department-level datasets
  • Team-managed reports
  • Content that is reliable but still evolving

What Does It Mean to Certify Content?

Certified content represents the highest level of trust in Power BI. It indicates that the content has been reviewed, approved, and governed according to organizational standards.

Key Characteristics of Certified Content

  • Approved by authorized reviewers
  • Requires Power BI tenant admin configuration
  • Used as a single source of truth
  • Clearly marked with a Certified badge

Who Can Certify Content?

  • Users assigned as certifiers by a Power BI tenant administrator
  • Typically part of:
    • IT
    • Data governance
    • Center of Excellence (CoE)

Supported Artifacts

  • Datasets (semantic models)
  • Dataflows

Important for the exam:
Reports cannot be certified directly — certification applies to the underlying dataset or dataflow.

Promote vs. Certify: Key Differences

FeaturePromotedCertified
Approval requiredNoYes
Tenant admin involvementNoYes
Trust levelMediumHigh
Intended audienceTeam or departmentOrganization-wide
Governance reviewInformalFormal
Exam relevanceMediumHigh

How Promotion and Certification Affect Users

When users browse content in Power BI:

  • Certified items appear first in searches
  • Users are encouraged to build new reports using certified datasets
  • Reduces duplication of datasets and metrics
  • Improves consistency across reports and dashboards

This directly supports self-service analytics with governance, a recurring PL-300 theme.

Where Promotion and Certification Are Configured

Promotion and certification are managed in:

  • Power BI Service
  • Dataset or dataflow Settings
  • Workspace context (not Power BI Desktop)

Tenant admins control:

  • Whether certification is enabled
  • Who can certify content

Exam Scenarios to Watch For

On the PL-300 exam, expect scenarios like:

  • Choosing between promoted vs. certified content
  • Identifying who can certify a dataset
  • Determining why a report cannot be certified
  • Understanding how certification affects dataset reuse

Best Practices (Exam-Relevant)

  • Promote content that is reliable but not formally governed
  • Certify content that is:
    • Widely used
    • Business-critical
    • Carefully validated
  • Use certification to enforce:
    • Metric consistency
    • Trusted KPIs
    • Enterprise reporting standards

Key Takeaways for PL-300

  • Promotion = recommended, informal trust
  • Certification = governed, enterprise-approved trust
  • Only datasets and dataflows can be certified
  • Certification requires tenant admin setup
  • Certified content supports scalable self-service BI

Practice Questions

Go to the Practice Questions for this topic.

BI Administration, Business Intelligence, Microsoft Certification, PL-300, Power BI

Configure Subscriptions and Data Alerts in Power BI (PL-300)

 
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%)
   --> Create and manage workspaces and assets
      --> Configure Subscriptions and Data Alerts

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

Subscriptions and data alerts in Power BI are notification and monitoring features that help users stay informed about changes in data without actively logging into reports or dashboards. For the PL-300 exam, candidates are expected to understand when to use each feature, how they are configured, their limitations, and how they fit into content distribution and governance.

Power BI Subscriptions

What Is a Subscription?

A subscription sends scheduled email notifications containing a snapshot or link to a report page or dashboard. Subscriptions are designed for passive consumption, allowing users to stay updated on key metrics.

Key Characteristics of Subscriptions

  • Can be created for:
    • Reports
    • Report pages
    • Dashboards
  • Delivered via email
  • Can be scheduled (daily, weekly, etc.)
  • Can include:
    • An image of the visual
    • A link to the content
  • Respect Power BI security and permissions

Types of Subscriptions

TypeDescription
User subscriptionA user subscribes themselves to content
Subscription for othersRequires appropriate permissions (often via workspace or app)

Requirements and Limitations

  • Users must have access to the underlying content
  • Subscriptions do not bypass Row-Level Security (RLS)
  • Report subscriptions require:
    • Content to be hosted in Power BI Service
    • Dataset refresh to be functioning correctly
  • Some advanced features require Power BI Pro or Premium capacity

When to Use Subscriptions (Exam Scenarios)

  • Executives want regular snapshots of KPIs
  • Stakeholders prefer email updates over interactive dashboards
  • Reporting needs are scheduled and predictable

Power BI Data Alerts

What Is a Data Alert?

A data alert notifies users when a numeric value crosses a defined threshold. Alerts are event-driven rather than time-based.

Supported Content for Alerts

  • Dashboard tiles only
  • Must display a single numeric value
  • Examples:
    • Card visuals
    • KPI tiles
    • Gauge tiles

❌ Data alerts cannot be set on report visuals directly.

Alert Triggers

Users can configure alerts based on:

  • Greater than
  • Less than
  • Equal to

Alerts can be delivered via:

  • Email
  • Power BI Service notifications

Alert Behavior

  • Alerts are evaluated after dataset refresh
  • Alerts trigger only when thresholds are crossed
  • Can be turned on/off without deleting

When to Use Data Alerts (Exam Scenarios)

  • Monitoring thresholds (e.g., sales below target)
  • Detecting operational issues
  • Requiring immediate action rather than scheduled updates

Subscriptions vs. Data Alerts (PL-300 Favorite Comparison)

FeatureSubscriptionsData Alerts
TriggerSchedule-basedThreshold-based
ContentReports, pages, dashboardsDashboard tiles only
PurposeInformational updatesException monitoring
DeliveryEmailEmail + notifications
Requires dashboardNoYes

Permissions and Governance

  • Users must have view access to subscribe or create alerts
  • Alerts and subscriptions respect RLS
  • Workspace admins can control who can:
    • Share content
    • Create subscriptions for others
  • Subscriptions support centralized distribution when combined with Power BI apps

Common PL-300 Exam Pitfalls

  • Assuming alerts work on report visuals ❌
  • Confusing subscriptions with data-driven alerts ❌
  • Forgetting that alerts require dashboard tiles ❌
  • Assuming subscriptions ignore security ❌

Exam Tip Keywords to Watch For

If the question mentions:

  • “Notify when a value exceeds a threshold” → Data Alert
  • “Send weekly email updates” → Subscription
  • “Dashboard tile” → Data Alert
  • “Passive consumption” → Subscription

Summary

To succeed on the PL-300 exam, you should be able to:

  • Configure report and dashboard subscriptions
  • Understand when subscriptions vs. alerts are appropriate
  • Recognize feature limitations and permissions
  • Choose the correct solution based on business requirements

Practice Questions

Go to the Practice Questions for this topic.

BI Administration, Business Intelligence, Microsoft Certification, PL-300, Power BI

Choose a Distribution Method 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%)
   --> Create and manage workspaces and assets
      --> Choose a Distribution Method in Power BI

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

Choosing the correct distribution method in Power BI is a key responsibility of a Power BI Data Analyst. It ensures that the right users get the right content, with appropriate access, performance, and governance. On the PL-300 exam, this topic tests your understanding of how and when to distribute content using different Power BI mechanisms, as well as the trade-offs between them.

Distribution decisions typically involve who the audience is, how often content changes, security requirements, and whether self-service or centralized control is preferred.

Common Power BI Distribution Methods

1. Sharing Reports and Dashboards

What it is:
Directly sharing a report or dashboard with users from the Power BI Service.

Key characteristics:

  • Users must have Power BI licenses
  • Access can be view-only or allow reshare
  • Relies on dataset permissions
  • Simple and quick to implement

When to use:

  • Small audiences
  • Ad hoc or informal sharing
  • Limited governance requirements

PL-300 tip:
Sharing does not automatically grant access to the underlying dataset unless configured.

2. Power BI Apps (Recommended for Most Scenarios)

What it is:
A packaged collection of reports, dashboards, and datasets published from a workspace.

Key characteristics:

  • Centralized distribution
  • Supports versioning and updates
  • Read-only experience for consumers
  • Strong governance and consistency

When to use:

  • Large or stable audiences
  • Enterprise or departmental reporting
  • Controlled release of certified content

PL-300 tip:
Apps are the preferred distribution method for most production scenarios.

3. Workspace Access

What it is:
Granting users direct access to a workspace with roles such as Viewer, Contributor, or Member.

Key characteristics:

  • High level of access
  • Intended for collaboration
  • Users can see all workspace content

When to use:

  • Development and collaboration
  • Analyst or creator teams
  • Not ideal for business consumers

PL-300 tip:
Workspace access is not a distribution method for broad audiences.

4. Dashboard Subscriptions

What it is:
Scheduled email snapshots of dashboards or reports.

Key characteristics:

  • Static image or PDF-like view
  • Delivered on a schedule
  • Requires access to the content

When to use:

  • Executives who prefer email
  • Regular monitoring without logging into Power BI
  • Supplement to other methods

PL-300 tip:
Subscriptions do not replace apps or sharing for interactive analysis.

5. Embedding (Power BI Embedded / SharePoint / Teams)

What it is:
Integrating Power BI content into other platforms.

Key characteristics:

  • Seamless user experience
  • Can leverage existing authentication
  • Requires planning and licensing considerations

When to use:

  • Internal portals (SharePoint, Teams)
  • External applications (Power BI Embedded)
  • Centralized business platforms

PL-300 tip:
Understand the difference between secure embed and publish to web.

6. Publish to Web (Public Sharing)

What it is:
Making reports publicly accessible via a URL.

Key characteristics:

  • No authentication required
  • Data is publicly available
  • Cannot be secured

When to use:

  • Public or marketing data only
  • Non-sensitive datasets

PL-300 tip:
This method is not appropriate for confidential or internal data and is often disabled by organizations.

How to Choose the Right Distribution Method

When answering exam questions, evaluate:

ConsiderationBest Fit
Large business audiencePower BI App
Executive KPIsDashboard + App
CollaborationWorkspace access
Email deliverySubscriptions
External applicationPower BI Embedded
Public dataPublish to web

Exam-Focused Decision Guidance

  • Apps > Sharing for governed distribution
  • Sharing for quick, limited access
  • Workspaces for creators, not consumers
  • Publish to web only for non-sensitive data
  • Subscriptions for passive consumption

If a question mentions enterprise, controlled access, or production deployment, the correct answer is almost always Power BI App.

Key Takeaways

  • Distribution is about access, security, and user experience
  • Power BI offers multiple distribution options, each with trade-offs
  • The PL-300 exam emphasizes choosing the most appropriate method, not just knowing how they work
  • Apps are the recommended default for most organizational scenarios

Practice Questions

Go to the Practice Questions for this topic.

Business Intelligence, Data Visualization, Microsoft Certification, PL-300, Power BI

Create Dashboards (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%)
   --> Create and manage workspaces and assets
      --> Create Dashboards

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

In Power BI, dashboards provide a high-level, consolidated view of key metrics by displaying visuals from one or more reports on a single canvas. Unlike reports, dashboards are created only in the Power BI Service and are primarily designed for executive and operational monitoring.

For the PL-300 exam, you are expected to understand what dashboards are, how they are created, how they differ from reports, and how they are managed and shared within workspaces.

What Is a Power BI Dashboard?

A Power BI dashboard is:

  • A single-page canvas
  • Composed of tiles
  • Created by pinning visuals from reports or Q&A
  • Can display visuals from multiple datasets and reports

Dashboards are optimized for at-a-glance insights, not detailed analysis.

Dashboards vs Reports (Key Exam Distinction)

FeatureDashboardReport
PagesSingle pageMultiple pages
CreationPower BI Service onlyDesktop or Service
Data sourcesMultiple datasetsOne dataset
InteractivityLimitedFull
EditingPin/remove tilesFull design control

Exam tip:
If a question mentions multiple datasets on one page, the answer is almost always Dashboard.

Creating a Dashboard

Step 1: Publish a Report

Before creating a dashboard:

  • A report must be published to the Power BI Service
  • Dashboards cannot exist without reports

Step 2: Pin Visuals to a Dashboard

You can pin:

  • Individual visuals
  • Entire report pages (as a single tile)
  • Q&A results
  • Live pages (depending on visual type)

Pinned visuals become tiles on the dashboard.

Step 3: Arrange and Configure Tiles

On the dashboard canvas, you can:

  • Resize tiles
  • Reposition tiles
  • Set custom titles and subtitles
  • Add links to reports
  • Configure alerts (for supported visuals)

Types of Dashboard Tiles

Common tile types include:

  • Visual tiles (charts, tables, KPIs)
  • Text boxes
  • Images
  • Web content
  • Q&A tiles

Dashboards can combine data-driven visuals and static informational content.

Dashboard Data Behavior

Important behaviors to remember for the exam:

  • Dashboards do not store data
  • Data comes from the underlying datasets
  • Tile data updates when datasets refresh
  • Clicking a tile opens the source report

Dashboards reflect the current state of the data, not a snapshot.

Sharing and Accessing Dashboards

Dashboards can be:

  • Shared directly with users
  • Included in a workspace app
  • Viewed by users with appropriate permissions

Key exam concept:

  • Users need access to the underlying dataset to see dashboard data
  • Sharing a dashboard does not bypass security

Alerts and Monitoring

Dashboards support data alerts on certain tile types, such as:

  • KPI tiles
  • Card visuals
  • Gauge visuals

Alerts notify users when a value:

  • Exceeds
  • Falls below
  • Reaches a defined threshold

This makes dashboards ideal for operational monitoring scenarios.

Limitations of Dashboards

Dashboards:

  • Cannot be created in Power BI Desktop
  • Do not support drill-through
  • Have limited filtering and slicing
  • Cannot be versioned like reports

These limitations are often tested through scenario-based questions.

Common Exam Scenarios

You may see questions asking:

  • When to use a dashboard vs a report
  • How to display metrics from multiple datasets
  • How to create a single monitoring page
  • How dashboards behave when data changes
  • How dashboards are shared or included in apps

Best Practices to Remember for PL-300

  • Use dashboards for high-level summaries
  • Use reports for detailed analysis
  • Pin only important KPIs
  • Keep dashboards clean and minimal
  • Combine dashboards with workspace apps for distribution
  • Remember dashboards are Service-only

Summary

Creating dashboards is a core Power BI skill focused on monitoring, visibility, and executive reporting. For the PL-300 exam, ensure you understand:

  • How dashboards are created
  • How they differ from reports
  • How they interact with datasets
  • How they are shared and managed in workspaces

Mastering dashboards helps demonstrate your ability to deliver business-ready Power BI solutions.

Practice Questions

Go to the Practice Questions for this topic.