Manage and secure Power BI practice questions

The dashboard owner has not granted the user 'Build' permission on the dataset.

Why it fails: Incorrect — 'Build' permission controls whether a user can build new reports from the dataset, not whether sensitivity labels are detected on existing content. The warning banner appears for all viewers (subject to label policy) regardless of their Build permission, because it is a server-side check of the label's classification level, not a permission gate. In fact, even if Build permission were granted, the warning would still appear.

RLS is incorrectly configured and allowing users to see data they should not.

Why it fails: Incorrect — row-level security (RLS) filters which rows a user can see based on roles, and a misconfigured RLS could expose too much data, but it cannot produce the 'Sensitive data detected' warning. That warning is generated solely by the presence of a sensitivity label applied to the content, which overrides RLS in terms of classification warnings. If no label exists, RLS issues will still not trigger such a banner.

The user is viewing the dashboard in a browser that does not support sensitivity labels.

Why it fails: Incorrect — the warning originates from the Power BI service reading the label stored in the dataset's metadata, not from the client browser's ability to render or recognize the sensitivity label. Even in older or unsupported browsers, the service still sees the label and shows the warning; the browser at most affects visual display of the label pill, not the server-side detection logic.

The workspace has data classification set to 'General'.

Why it fails: The workspace's data classification property is exposed in the admin settings and is shown as 'Confidential', not 'General'. A 'General' classification would indicate no sensitivity labeling, whereas 'Confidential' is a higher-level label used to signal that report content requires restricted handling. Because the exhibit clearly displays 'Confidential', the statement that it is set to 'General' is factually incorrect.

The workspace uses a customer-managed encryption key.

Why it fails: The workspace's encryption property is set to 'ServiceManaged', which means Microsoft-managed encryption keys protect the data at rest. A customer-managed key (CMK/BYOK) would require a 'CustomerManaged' property value and an Azure Key Vault configuration, not show 'ServiceManaged'. Since the exhibit indicates service-managed encryption, this option is false.

The workspace allows data sources from SharePoint Online.

Why it fails: The allowedDataSources property in the workspace settings is a whitelist of data source types users are permitted to connect to from datasets in this workspace. SharePoint Online is not present in that list in the exhibit, so the workspace cannot be said to allow SharePoint data sources. Another data source, such as Azure SQL Database, may be listed, but SharePoint Online is not among them.

Set the 'Maximum number of workspaces a user can create' to 0 for all security groups.

Why it fails: The 'Maximum number of workspaces a user can create' field is a quota control, not a kill switch. It limits how many new workspaces an individual can create, but it must be applied through security-group assignment, and any user not in those groups is unaffected. Setting it to 0 may stop new creation for covered users, yet it neither revokes the underlying 'Create workspaces' tenant permission nor covers every identity, so it is not a reliable tenant-wide block.

Remove the 'Create workspace' button from the Power BI navigation pane using custom branding.

Why it fails: Custom branding in Power BI only changes visual identity elements such as logos, colors, and theme; it does not alter the Power BI service's navigation or remove functional buttons. Even if the button were somehow hidden from a user's UI, the underlying workspace-creation capability would remain enabled through the service and APIs. Therefore, branding is purely cosmetic and cannot satisfy a security or policy requirement.

In the Power BI admin portal, disable 'Use workspaces' for all users.

Why it fails: 'Use workspaces' is a separate tenant setting that governs whether users can access and use any workspace, not just whether they can create one. Disabling it for all users would revoke access to existing workspaces and their reports, dashboards, and apps, causing a major disruption to collaboration. Since the requirement is only to prevent creation, turning off 'Use workspaces' is far too broad and is therefore incorrect.

The dashboard owner does not have a Power BI Pro license.

Why it fails: For direct sharing, the owner must have a Power BI Pro or Premium Per User (PPU) license, but that only affects their ability to share, not whether the recipient can see the dashboard after it's shared. Once the dashboard is shared, the recipient's visibility is determined by the recipient's own license and the sharing settings, not the owner's license status. Since the dashboard is already shared, the owner's license being inactive or basic would not make it invisible to the user.

The user is signed in with the wrong Microsoft Entra ID account.

Why it fails: Signing in with a different Microsoft Entra ID account would indeed hide any dashboard shared to your primary account, but this is a less likely root cause because the user would typically notice they are in the wrong account (different tenant, different organization) and the symptom would affect all shared content. The report focuses on a single dashboard missing, which points to a workspace or sharing location issue rather than an identity mismatch. Also, if the user is a member of the correct security group and the dashboard is shared directly, the wrong account would be a secondary possibility, not the primary diagnosis.

The dashboard has not been shared with the user's security group.

Why it fails: Since the dashboard was already shared directly with the user's account, the lack of a security group sharing assignment is irrelevant; the direct share grants the user access regardless of group membership. Even if the dashboard is also shared with a security group, that group sharing only affects group members, not the direct share. The user's inability to see it, therefore, cannot be blamed on the security group not being included, because the direct share is the mechanism in play.

Microsoft Purview data classification policies.

Why it fails: Microsoft Purview data classification policies are focused on data governance, specifically classifying and labeling sensitive data across the enterprise with sensitivity labels and data loss prevention rules. These policies do not ingest or analyze the Power BI activity logs that record user actions like viewing or exporting reports. Purview is about protecting data through classification, not detecting real-time security threats, so it cannot stream activity to a SIEM for monitoring.

Microsoft Foundry AI models.

Why it fails: Microsoft Foundry (Azure AI Foundry) is a cloud-based platform for developing, training, and deploying custom AI models, not a security monitoring solution. It has no built-in connectors to ingest Power BI activity logs or pre-built analytics rules for detecting suspicious user behavior. While you could feed logs into a custom AI model to find anomalies, Foundry would not provide the operational integration, alerting, and incident management required for this security monitoring use case.

Microsoft Intune device compliance policies.

Why it fails: Microsoft Intune device compliance policies govern device enrollment, encryption, and OS patching to control access to corporate resources. These policies do not capture or analyze user behavior within Power BI, such as report views or data exports, nor do they ingest Microsoft 365 audit logs. Intune is endpoint management, while Power BI threat monitoring requires a SIEM or cybersecurity analytics platform that processes activity logs.

Apply row-level security (RLS) and use Microsoft Intune for conditional access

Why it fails: Row-level security (RLS) limits query results to only the rows a user is allowed to see, but it does nothing to protect the underlying data at rest or while it travels. Microsoft Intune conditional access governs device health and compliance, not cryptographic protection or identity verification. Neither mechanism addresses the encryption at rest/in transit or the strong identity proof that a complete security design requires, so this combination leaves data exposed to unauthorized access at the storage layer.

Use Microsoft Purview for encryption and Microsoft Intune for identity

Why it fails: Microsoft Purview is a data governance and cataloging service—it discovers, classifies, and tracks data lineage, but it does not perform cryptographic encryption. Microsoft Intune manages devices and applications through mobile device/application management, not user identity; identity verification is handled by Microsoft Entra ID. Choosing Purview and Intune for encryption and identity misunderstands the distinct security roles of each service, so this option fails to deliver any actual encryption or identity verification for Power BI reporting.

Enable Power BI encryption settings and configure SharePoint permissions

Why it fails: Power BI does not expose a native 'encryption settings' toggle—encryption for datasets is inherited from the underlying Azure infrastructure, such as Azure Storage and Azure SQL Database. SharePoint permissions control access to documents and lists, but they are not a substitute for identity validation when connecting to Power BI semantic models or to backend data sources. Relying on SharePoint permissions would neither encrypt data nor verify the end user's identity in a way that integrates with Power BI's authentication chain, leaving the solution incomplete.

Use the on-premises data gateway (standard mode) and store the connection string in the gateway

Why it fails: Storing a connection string in the gateway is a conceptual mistake: the gateway does not hold connection strings—it retrieves all connection metadata from the Power BI dataset or data source definition, and simply uses the stored credentials or SSO mechanism to access the source. Even in standard mode, merely having a connection string in the gateway would not enable SSO; Kerberos constrained delegation must be explicitly configured on the gateway and the data source. Thus, this option fails to address the core authentication requirement and mischaracterizes the gateway's role.

Use the on-premises data gateway (personal mode) and store the Windows credentials in the gateway

Why it fails: The personal-mode gateway is designed for single-user, self-service scenarios and operates with a fixed Windows account, caching that user's credentials for all data refreshes. Because it cannot impersonate the actual Power BI viewer via Kerberos delegation, it forces every refresh to run under one stored identity, breaking fine-grained permissions and making SSO impossible. Moreover, storing Windows credentials in the personal gateway is a security risk and is not supported in enterprise shared datasets, so this option is unsuitable for the organization's needs.

Use the virtual network (VNet) gateway and configure a service principal

Why it fails: The virtual network (VNet) gateway is intended for connecting to cloud data sources hosted inside Azure virtual networks, not for on-premises environments, so it cannot reach the on-premises SQL Server. Configuring a service principal (SPN) provides Microsoft Entra ID-based authentication, which is inappropriate for Windows Kerberos delegation to on-premises sources; the SPN would authenticate as an application, not as the individual user. Since the requirement involves on-premises Windows authentication with user-level SSO, this option is fundamentally misaligned.

The streaming dataset is not supported for dashboards. Use a push dataset instead

Why it fails: The streaming dataset is not supported for dashboards. Use a push dataset instead. This statement is incorrect because streaming datasets are fully supported for dashboard tiles and are specifically designed for real-time scenarios. A push dataset would only allow data to be inserted manually via API, but it would not change the dashboard's tile refresh behavior. Since the dashboard already uses a streaming dataset, the issue lies with the tile cache, not with dataset type support.

Enable automatic page refresh on the dashboard and set it to 1 minute

Why it fails: Enable automatic page refresh on the dashboard and set it to 1 minute. Automatic page refresh is a feature for Power BI reports, not for dashboards. In a dashboard, you cannot set a page-level refresh interval because dashboards are composed of tiles that are cached independently. Instead, you control tile freshness by adjusting the cache settings or refreshing the underlying dataset. Therefore, this option is not applicable to dashboards and would not solve the staleness problem.

The refresh interval in the dataset is set to 30 minutes. Change it to 1 minute

Why it fails: The refresh interval in the dataset is set to 30 minutes. Change it to 1 minute. Streaming datasets do not have a refresh interval in the traditional sense; they receive data continuously via the API as it is pushed, so no periodic refresh is needed. Changing a non-existent or ignored refresh interval will have no effect on the dashboard tile staleness. The actual delay is due to the tile caching mechanism, not the dataset refresh schedule.

Reassign the dataset ownership to another user in the workspace settings

Why it fails: Workspace settings in the Power BI service do not include a 'reassign ownership' control for datasets; ownership is a dataset-level property, not a workspace-level setting. Even if you could push ownership to another user, that action would not clear or update the cached data source credential that is causing the refresh failure—the new owner would still have to manually update credentials under the dataset's data source settings. In practice, 'Take over' is the only supported way to transfer ownership, and it must be initiated from the dataset context menu, not from workspace settings.

Create a new dataset and link the report to it

Why it fails: Recreating the dataset and pointing the report at it is an unnecessarily destructive workaround: every table, relationship, measure, and visual field mapping would need to be redeployed, and the report's bound objects would have to be re-associated to the new dataset. The original connectivity problem would also persist on the new dataset, because it would still require a valid user identity and data source credentials stored with the dataset. This approach should be reserved for cases where the old dataset is corrupted, not when the only issue is an expired credential.

Reconfigure the gateway to use a service principal

Why it fails: Changing the gateway to a service principal is a shift in the authentication identity for the gateway cluster, but the dataset's data source credentials are still stored separately within the dataset (or in the gateway's data source entry) and remain the same invalid credentials that refresh fails on. The gateway merely provides the transport path between the Power BI service and the data source; it does not override or reauthenticate the stored dataset credentials each time. Unless the data source itself is configured to accept that service principal and you also update the dataset's data source settings accordingly, this step alone cannot fix the refresh error.

Configure the Excel workbook to inherit the label from Power BI

Why it fails: Configuring the Excel workbook to inherit a label from Power BI is inaccurate because sensitivity labels are applied by Power BI itself to its artifacts, not inherited by an external workbook through a setting. When content is exported to Excel, Power BI applies the label to the file based on the dataset's label, but there is no configuration in the workbook that causes inheritance. The labeling flow always originates from Power BI's label policy, so this option misplaces the control.

Use row-level security to restrict access to sensitive data

Why it fails: Row-level security (RLS) restricts which rows of data a user can view within a dataset or report, but it does not assign or manage sensitivity labels on the underlying content. RLS is a data-access control that filters records per user, while sensitivity labeling is a classification mechanism that describes the confidentiality of the whole artifact. Implementing RLS would not automatically apply a label to the dataset, dashboard, or exported file, so it does not meet the labeling requirement.

Require users to manually apply a sensitivity label before exporting

Why it fails: Requiring users to manually apply a sensitivity label before exporting is not the solution because the requirement calls for automatic labeling, not a manual step that can be forgotten or bypassed. Moreover, manual enforcement only affects the exported file, leaving the source report or dataset without a label and failing to protect content within Power BI. An automatic policy-based approach is necessary to ensure consistent classification and protection across the entire lifecycle.

Verify that the users have Power BI Pro or Premium Per User licenses assigned

Why it fails: A missing or invalid Power BI Pro or Premium Per User (PPU) license would typically block the user from signing in or render the entire service unusable, not produce a report-level 'content not found' error. Since the report is already listed and accessible in the workspace, the user clearly has a valid license; the ticket's root cause lies in the capacity hosting the workspace, not in license assignment.

Confirm that the report is published to the correct workspace

Why it fails: If the report were in the wrong workspace, users would not see it listed in their workspace at all. The fact that the report is visible and attempt to open it fails indicates the publication location is correct; the error is occurring during the load/render phase. Therefore, verifying the workspace path is a red herring and does not address the capacity problem described in the ticket.

Check if row-level security (RLS) is blocking access to the underlying data

Why it fails: Row-level security (RLS) is a filtering mechanism that runs against the data model after the report is loaded; it does not prevent the report itself from opening. If RLS were blocking access, the user would see the report and visuals, but tables and visuals would render empty or with only permitted rows. Since the support ticket describes an inability to access the report content entirely, RLS is not the cause.

Power BI usage metrics report

Why it fails: The Power BI usage metrics report provides aggregate, report-level statistics—like total views, unique viewers, and how many times a report was opened—rather than a chronological log of individual user activities. It answers questions like 'which report is popular?' but does not identify which specific user performed which action, nor does it capture events such as permission changes or data exports. As a dashboard-centric summary, it lacks the granular event-level detail needed for full activity monitoring.

Power BI capacity metrics app

Why it fails: The Power BI capacity metrics app is designed to monitor the health and performance of Power BI Premium capacities, surfacing metrics like CPU consumption, memory pressure, and query durations. It does not track discrete user actions such as viewing, exporting, or sharing, so it cannot satisfy the requirement to monitor all Power BI activities. Its focus is on infrastructure scalability and performance tuning, not on an audit or activity trail.

Microsoft 365 audit log

Why it fails: The Microsoft 365 audit log is a platform-wide log that records events from many services, and Power BI events are only one segment of its schema. While it can capture Power BI activities (when the unified audit log is enabled with the appropriate license), it is not specific enough for an administrator whose focus is solely on Power BI, and it requires additional filtering and setup to isolate Power BI data. The Power BI activity log in the admin portal is the more targeted, ready-to-use tool for this exact requirement, making the broader M365 log a less direct choice.

Power BI Premium capacity assigned to the workspace

Why it fails: Labels are supported in Pro and Premium workspaces.

Power BI Pro license for all users

Why it fails: Labels work with any license if enabled by admin.

Column-level security (CLS)

Why it fails: Column-level security (CLS) is a feature of Microsoft SQL Server, not a component within Power BI. Power BI does not natively intercept column-level data; you can only hide columns in the report view, which doesn't prevent a user with dataset access from querying those columns via DAX or Report Builder. Therefore, CLS cannot be used to restrict access in Power BI.

Bookmark-based filtering

Why it fails: Bookmark-based filtering is a user-interface navigation feature that captures the current state of filters, slicers, and visual visibility for a report page. It is designed for storytelling and presentation, not for data security—users can open other bookmarks or manually change filters to see data they are permitted to query. Because it provides no enforcement at the dataset backend, bookmark-based filtering cannot restrict data access.

Object-level security (OLS)

Why it fails: Object-level security (OLS) controls access to entire tables or columns by hiding them from select users, but it does not filter individual rows. In Power BI, OLS is implemented using object-level permissions in tabular models and must be combined with row-level security (RLS) to enforce row-level restrictions. Since the scenario requires restricting access to specific rows, OLS alone is insufficient and thus not the correct answer.

Dashboard-level permissions

Why it fails: Dashboard-level permissions govern who can view, share, or manage a dashboard as an artifact, but they do not control the underlying data rows. In Power BI Service, a dashboard tile may display aggregated data, and row-level security is applied separately to the dataset at query time. Simply changing dashboard permissions does not filter rows; it only manages access to the dashboard surface.

The Marketing workspace should be moved to Premium capacity to avoid contention

Why it fails: Moving Marketing to Premium capacity would worsen the problem rather than fix it. If the Sales dataset already exhausts Premium resources, placing the Marketing dataset on that same capacity would force both workloads to compete for the same scarce memory and CPU, increasing throttling. The correct remedy is to optimize the Sales data model, reduce dataset size, or schedule refreshes during off-peak hours, not to relocate the Marketing workspace.

Both workspaces are on the same shared capacity node, and the Sales dataset refresh consumes node resources, slowing Marketing

Why it fails: This option is false because the Sales workspace resides on Premium capacity, which is a dedicated set of resources, while the Marketing workspace runs on shared capacity with a completely separate node. A Premium dataset refresh consumes the Premium node's memory and CPU, not the shared node's resources, so it cannot directly cause same-node contention. The observed slowdown is due to Premium capacity throttling affecting the broader Power BI platform, not to both workspaces racing for the same shared node.

The Marketing dataset requires a Pro license, which is not assigned

Why it fails: This is incorrect because the symptom is performance degradation during a dataset refresh, not an access or licensing error. A missing Pro license for the Marketing dataset would produce a 'You need a Pro license' message when attempting to open the report, or block access to the workspace entirely. In contrast, the scenario describes a slow report caused by resource contention from the Sales Premium dataset, which is unrelated to license assignment.

The SalesRep role is not assigned to any users

Why it fails: The SalesRep role not being assigned to any users would mean that the RLS filter does not apply to anyone, so all users would see all data (or data they have permission to via other roles) without restriction. If users are seeing no data at all, an unassigned role cannot be the cause; in fact, the absence of an assigned role would typically expose more data, not less. The symptom of no data is consistent with a filter that evaluates to false or an error, such as a column name mismatch, not with an unused role.

The filter expression uses a comparison operator that is not supported in RLS

Why it fails: The comparison operator '>' is fully supported in DAX and in RLS role filters. RLS allows all standard DAX comparison operators: =, <>, >, <, >=, <=, plus logical functions like AND and OR. Therefore, using '>' is not the source of the problem. If the filter appears syntactically correct, any 'no data' symptom must stem from a different issue, such as a column name mismatch or an incorrectly filtered column value range.

The RLS role uses a filter on a measure, not a column

Why it fails: Row-Level Security filters are designed to restrict rows at the table level by evaluating a Boolean expression against column values in a table. Measures, on the other hand, are calculated aggregations built on top of tables and are not evaluated per row in the same way. If an RLS role attempts to reference a measure instead of a column, the filter will not behave as a row-level restriction and may lead to unexpected results, but the described issue of 'no data' with a column name in the filter suggests the actual error is a mismatched column name, not the use of a measure.

Row-level security (RLS) is not configured on the AAS model.

Why it fails: RLS is optional and not related to the connection error.

The data source credentials are stored in the dataset.

Why it fails: SSO does not store credentials; it passes the user's identity.

The service principal used for authentication has expired.

Why it fails: SSO uses the user's Microsoft Entra identity, not a service principal.

Assign the security group the Viewer role on the workspace.

Why it fails: Assigning the Viewer role on the workspace grants users access to all content within that workspace, not just the single dashboard you want to restrict. Since the Viewer role is workspace-scoped, it cannot differentiate between dashboards, so any member of the security group would be able to see every report and dashboard in that workspace, including potentially sensitive content meant for other audiences. This is overly broad and does not satisfy the requirement of limiting access to only the specific dashboard.

Configure row-level security on the underlying dataset to filter by user.

Why it fails: Row-level security (RLS) filters the data rows a user sees within a dataset, but it does not control who can open or view the dashboard itself. Even if you configure RLS to return zero rows for unauthorized users, those users would still be granted access to the dashboard and would see blank tiles or errors, which is not a proper access-denial experience. RLS is a data-level security measure, not a content-level access-control mechanism, so it cannot be used to restrict dashboard visibility.

Share the dashboard directly with the security group.

Why it fails: Sharing a dashboard directly with a security group does grant members access, but it lacks the audience-based control that an app provides and can be easily over-permissioned. With this method, you rely on the share dialog's settings to prevent resharing, and you cannot bundle the dashboard with related reports or enforce a consistent access boundary. Moreover, sharing is a one-off grant that is not tied to a security group's lifecycle unless you manually manage updates, so it is less secure and harder to maintain than using an app audience.

Use data loss prevention (DLP) policies in Microsoft Purview.

Why it fails: Incorrect. Data loss prevention (DLP) policies in Microsoft Purview help prevent data leaks but do not automatically apply sensitivity labels to exported data.

Set a default sensitivity label on the report.

Why it fails: Incorrect. There is no concept of a default sensitivity label on a report; labels are applied at the dataset level and inherited by downstream items.

Enable 'Apply sensitivity labels to exported data' in the Power BI admin portal.

Why it fails: Incorrect. The 'Apply sensitivity labels to exported data' admin setting is used when the data source lacks a label, but automatic inheritance from a labeled dataset takes precedence and does not require this setting to be enabled.

Configure the dataset to use SSO in the Power BI service.

Why it fails: Configuring the dataset to use SSO in the Power BI service is a connection-level option that tells the gateway to impersonate the viewer for DirectQuery or Analysis Services, but it does not restrict how the data source can otherwise be accessed. Users or administrators can still choose Basic or other authentication methods when setting up the data source, so SSO remains optional. The dataset setting is therefore a prerequisite for SSO in some scenarios, not an enforcement mechanism that blocks other methods.

Enable the 'Allow data sources to use SSO' tenant setting.

Why it fails: Enabling the 'Allow data sources to use SSO' tenant setting simply grants permission for SSO to be used across the organization; it is an enable switch rather than a restrictive policy. This setting does not affect the availability of other authentication methods, so users may continue to authenticate with Basic or non-OAuth methods for the same data sources. As a result, SSO can be used, but it is not guaranteed or enforced, which fails the requirement to block other methods.

Create a security group for SSO-enabled data sources and assign it to the workspace.

Why it fails: Creating a security group for SSO-enabled data sources and assigning it to the workspace only controls who is allowed access to the workspace and its artifacts, not how users authenticate to the underlying data source. Security groups are membership-based containers for permissions and do not alter the authentication protocol used by the gateway or the data source. Even if a security group includes only SSO-enabled data sources, an individual user could still authenticate using legacy methods if those methods are enabled at the tenant level.