Microsoft PL-300: Manage and secure Power BI Practice Questions

Separate workspaces for Marketing and Finance with Contributor role for Marketing report authors satisfies requirements 1 and 2: Contributors can publish content independently without IT involvement, and separate workspaces provide independent management of semantic models per department. Enabling 'Workspace access' audit log events in the Microsoft 365 compliance center allows admins to audit user access across workspaces, satisfying requirement 3. A single shared workspace with RLS controls data visibility but does not achieve independent management of semantic models per department, and RLS does not control who can publish content. Using deployment pipelines restricts direct publishing to production, which contradicts requirement 1 (publishing without IT). Sensitivity labels classify and protect data but do not separate workspace management or satisfy the auditing requirement. Personal workspaces (My Workspace) are isolated to individual users and cannot be shared or governed as departmental workspaces, making them unsuitable for a team-based governance strategy.

The Viewer role allows users to view and interact with reports and dashboards in a workspace but does not grant permission to edit content or access datasets directly — exactly what is required here. Contributor allows users to publish and edit content, which exceeds the required permissions. Member includes all Contributor rights plus the ability to share items and manage app audiences, which is too permissive. Admin has full control over the workspace including adding/removing users, which far exceeds the requirement.

Member is correct because it allows publishing, editing, and overwriting content (reports, semantic models, dashboards) but does NOT grant the ability to add or remove workspace members — that capability is reserved for the Admin role. Admin is wrong because it would also allow managing workspace membership, which violates the requirement. Contributor is wrong because Contributors cannot overwrite/republish content published by others; they can only publish new content they own. Viewer is wrong because it only grants read access with no ability to publish or edit content.

Deployment rules in Power BI deployment pipelines allow administrators to define stage-specific overrides for data source connection strings and parameters, so that when content is deployed to a different stage, the correct data source is automatically applied. This is the designed solution for this exact problem. Using a Power BI parameter and updating it manually after each deployment would work but is a manual step that defeats the automation purpose, and the question asks how to do it 'without manually editing after every deployment.' Maintaining duplicate semantic models per stage creates management overhead and is an anti-pattern. There is no 'Automatic deployment' option that resolves data source differences — that is not a real Power BI feature.

Build permission on a semantic model is required to use features that interact with the underlying data, including Analyze in Excel, creating new reports, and exporting underlying data. Sharing a report directly grants the recipient view access to the report but does not automatically grant Build permission on the semantic model. The report owner must explicitly grant Build permission. The Viewer workspace role does grant Build permission by default in some scenarios, but direct report sharing does not — this is a common misconception. DirectQuery mode does work with Analyze in Excel; the mode of the model does not block this feature. Analyze in Excel is available to Pro and PPU users, but if the workspace is on Premium capacity, free users can view reports — however, the described issue is a permissions problem, not a licensing problem, since the user can already view the report.