Manage and secure Power BI Study Guide — PL-300

Manage and Secure Power BI

This domain covers the administrative and governance layer of Power BI: how workspaces are structured, how content moves from development to production, how data refreshes are managed, how data is classified and protected, and how access is controlled at every level. At 20% of the exam, it is the second-largest domain in PL-300 and consistently contains questions that require precise knowledge of role names, tier requirements, and default behaviors—not just conceptual understanding.

Workspaces: Roles, Apps, and Audiences

Workspace Basics

A workspace in Power BI service is a shared environment for collaborating on reports, dashboards, semantic models, and dataflows. Every workspace except "My Workspace" is a v2 workspace (collaborative workspace). My Workspace is personal and cannot be shared or used for deployment pipelines.

Workspace Roles

There are four workspace roles. The exam tests their exact permission boundaries.

Key precision points:

• Contributor can publish reports but cannot share content or publish apps.
• Member can publish apps and share items but cannot change workspace settings or manage roles.
• Only Admin can add/remove other Admins and delete the workspace.
• Viewers can consume content in the workspace directly but cannot use it as a source for new reports (they need Build permission on the semantic model separately).

Apps and Audiences

A Power BI app is a packaged, read-only distribution mechanism for workspace content. Apps are published from a workspace and distributed to users or security groups.

• Only Admin or Member can publish an app.
• App audiences allow a single app to serve different groups with different content visibility. Each audience sees only the pages and items assigned to it.
• An app has its own permission set separate from the workspace—a user can have access to the app without having any workspace role.
• Apps do not auto-update; the publisher must explicitly update the app after workspace content changes.

Common traps:

• Confusing workspace access with app access—they are independent. Giving someone Viewer on the workspace does not give them the app, and vice versa.
• Assuming app consumers see all reports in the workspace—they only see what is included in the app and assigned to their audience.
• Thinking Contributors can publish apps—they cannot.
• Mixing up "sharing a report link" (direct access) with publishing an app (managed, read-only bundle).

Worked scenario: A team needs contractors to see a sales report but not access any other workspace content or be able to re-share. Solution: Publish an app with only that report included, grant contractors access to the app. Do not add them to the workspace.

Deployment Pipelines (Dev / Test / Prod)

Pipeline Structure

Deployment pipelines automate promotion of Power BI content through Development → Test → Production stages. This is a managed CI/CD mechanism within Power BI service.

Requirement: The workspace at each stage must be on a Premium capacity, Premium Per User (PPU), or Fabric capacity. Free and Pro workspaces cannot be used in deployment pipelines.

Mermaid diagram — Deployment pipeline flow:

How content moves through a three-stage deployment pipeline.

Roles and Rules

• A pipeline Admin controls the pipeline itself (assigns workspaces, deploys).
• Deploying to a stage requires the user to be at least a Member of the target workspace.
• Deployment rules allow overriding data source connections and parameters per stage (e.g., dev DB vs. prod DB) without modifying the report file.
• Items that can be deployed: reports, dashboards, semantic models, dataflows, paginated reports, and (in Fabric) additional item types.
• Deployment is item-level—you can choose to deploy only selected items rather than the entire workspace.

What Does NOT Carry Over

• Scheduled refresh settings do not move between stages—you must reconfigure them in each stage.
• Semantic model permissions (like Build permission grants) do not propagate.
• App audiences and configurations are stage-specific.

Common traps:

• Assuming a Pro license is sufficient for pipeline stages—it is not.
• Expecting refresh schedules to copy automatically—they must be manually set in each workspace.
• Confusing the pipeline Admin role with workspace Admin role—they are separate.
• Thinking deployment replaces content destructively—existing reports in the target stage are overwritten only for deployed items; undeployed items remain.

Worked scenario: A developer wants to promote a report from Dev to Test but the Test workspace is on Pro capacity. The exam answer is: assign the Test workspace to a Premium or PPU capacity first—only then can it participate in the pipeline.