Manage and secure Power BI practice questions

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

Why wrong: 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 wrong: 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 wrong: 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.

Enable 'Microsoft Purview Information Protection' file encryption settings.

Why wrong: Microsoft Purview Information Protection file encryption settings govern encryption of files via Azure Information Protection, but they operate independently of Power BI's export pipeline. These settings protect Office and line-of-business document encryption rules, not the metadata stamping that occurs during a Power BI export. Enabling them alone does not cause a Power BI report's sensitivity label to appear in the resulting Excel, PowerPoint, or PDF file.

Set the default sensitivity label for the workspace to 'Confidential'.

Why wrong: Workspace default sensitivity labels only apply to newly created items within that workspace, such as reports or dashboards, and do not retroactively label exports. At export time, Power BI uses the label on the underlying report item; if that item has no label, the exported file is unlabeled regardless of the workspace default. Therefore, this action has no direct effect on the exported file's protection.

Configure a Microsoft Purview auto-labeling policy for Power BI reports.

Why wrong: A Microsoft Purview auto-labeling policy scans and recommends or applies sensitivity labels to items stored in SharePoint, OneDrive, and Power BI when they are created or modified. This occurs inside the online service and is triggered by content inspection, not by a user's explicit export action. As such, it can ensure reports are labeled in the service, but it does not apply labels to files being exported outside of Power BI.

Disable 'Create workspaces' in the tenant settings.

Why wrong: Turning off 'Create workspaces' stops users from creating new app workspaces, which are the containers for organizing dashboards, reports, and datasets. However, external sharing is controlled by a dedicated tenant-level switch that determines whether users can invite outside email addresses to view content. Existing workspaces and already-published dashboards remain shareable to external users, so this option does not achieve the intended restriction.

Disable 'Export data' in the tenant settings.

Why wrong: Disabling 'Export data' in the tenant settings only restricts users from exporting report visuals to CSV, Excel, or connected data sources. It has no effect on how dashboards are accessed by external users, because export and sharing are governed by separate security controls. Therefore, this setting cannot prevent external users from being granted dashboard access via sharing invitations.

Disable 'Featured tables' in the tenant settings.

Why wrong: The 'Featured tables' setting controls the promotion of certified datasets for data discovery in Excel and Power BI, enabling users to find curated tables quickly. It is unrelated to access control or sharing mechanics for dashboards. Disabling it only removes a data catalog convenience feature and does nothing to prevent external users from being added to dashboard shares.

Row-level security (RLS) is misconfigured.

Why wrong: Row-level security (RLS) filters data for report viewers based on their identity after the data has been loaded and refreshed. It is a query-time restriction that does not interact with authentication or refresh operations. Since the issue affects only scheduled refresh and not manual refresh, RLS cannot be the root cause.

The on-premises data gateway is offline.

Why wrong: The on-premises data gateway is used to connect to on-premises data sources or to bridge VNet connections. The data source in this scenario is cloud-based, meaning the refresh activity runs entirely in the Power BI service without needing a gateway. Therefore, an offline gateway would be irrelevant, and gateway status would not explain why only automatic refresh fails.

The dataset exceeds the refresh limit for the assigned capacity.

Why wrong: Capacity refresh limits govern how many times a dataset can be refreshed per day and apply equally to manual and scheduled refreshes. If the limit were exceeded, even manual refreshes would fail with a quota error, not an authentication failure. The symptom of automatic refresh only failing suggests an expired token that is silently used by the scheduler, not a capacity constraint.

The workspace has data classification set to 'General'.

Why wrong: 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 wrong: 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 wrong: 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.

Reshare

Why wrong: Reshare is an additive right that allows the recipient to share the dataset with other users, but it does not itself include authoring or reading capabilities. Granting Reshare alone would not let the sales user build a new report; moreover, it would permit the user to expand access beyond the original group. To meet the requirement, Reshare would need to be combined with Build, so it is not the correct selection.

Write

Why wrong: Granting Write permission gives the recipient the ability to change the dataset itself—for example, modifying queries, measures, or scheduled refresh settings—and potentially publish a slightly updated dataset definition. The sales department user only needs to create new reports, not alter the underlying data model. Assigning Write would exceed the minimum privilege needed and introduces unnecessary risk of unintended changes to a shared semantic model.

Read

Why wrong: Read permission only allows a user to view and interact with existing reports or dashboards that use the dataset; it does not include the ability to build new content or connect to the dataset as a data source in Power BI Desktop. Since the user's requirement is to create a new sales report, Read lacks the essential authoring capability that Build provides. Without Build, any attempt to create a report would be blocked by the service.

Use the Microsoft Purview compliance portal to search for 'Export' events.

Why wrong: The Microsoft Purview compliance portal provides an audit log search for eDiscovery and compliance scenarios, but it is not the primary interface for querying Power BI's activity stream. Power BI-specific export events are captured in the unified audit log, which is more directly and comprehensively queried through the Microsoft 365 Defender portal's audit log search. Purview lacks the Power BI-specific filtering and operational context needed to isolate per-user export actions.

Check the report's usage metrics report for export counts.

Why wrong: The report's usage metrics report in Power BI displays aggregated telemetry such as total views, unique viewers, and average time spent, but it does not include a detailed, per-user export trail. Usage metrics are designed for adoption and workload analysis, and they do not log individual actions like a user clicking 'Export to Excel' on a specific report. Consequently, it cannot be used to determine which users exported data or when the export occurred.

Review the 'Export to Excel' metrics in the Azure Monitor for Power BI Premium.

Why wrong: Azure Monitor for Power BI Premium publishes capacity-level metrics such as CPU utilization, memory pressure, and query durations, which are intended for performance monitoring of Premium infrastructure. It does not emit or retain per-user security events like report exports, nor does it cover non-Premium workspaces. The 'Export to Excel' term appears nowhere as a user-action metric in Azure Monitor, making this option fundamentally mismatched for user-specific audit requirements.

Delete the report immediately.

Why wrong: Deleting the report immediately is premature and destructive: it removes the evidence of the potential violation from the workspace, and more importantly, it does nothing to change the user's access to the underlying SalesDataset. If the user truly lacks authorization, revoking their dataset permissions or workspace role is the corrective action. A hasty deletion also destroys the audit trail artifact that a compliance investigation would need to analyze.

Change the sensitivity label on the report to 'General'.

Why wrong: Changing the sensitivity label to 'General' only alters classification metadata; it neither grants nor removes access to the SalesDataset, because sensitivity labels in Power BI are not an access control mechanism. The user would still be able to create confidential reports if their dataset permissions are invalid. Further, mislabeling confidential data as general could itself cause a compliance violation, since the label is used for protection policies and downstream tracking.

Ignore the event because the report creation is logged but not necessarily a violation.

Why wrong: Ignoring the event because it is logged fails to recognize that the audit log exists specifically to facilitate post-hoc detection of security incidents, not to validate their legitimacy. A logged report creation can be the first indicator of data exfiltration, especially when a Confidential label is applied by a user without a need to know. Proper governance requires reviewing the event in context with the user's role and permissions rather than dismissing it outright.

In the Power BI admin portal, configure the 'Allow users to access Power BI' setting to specify the security groups.

Why wrong: This tenant-level switch in the Power BI admin portal is a global master toggle that either enables Power BI for the entire organization or disables it for everyone; it does not expose a field to select security groups for this particular setting. While many other tenant settings support scoping to specific groups, 'Allow users to access Power BI' only allows an all-or-nothing approach, so it cannot implement the requirement to grant access solely to approved security groups.

Configure the 'B2B guest user settings' to allow only specific domains.

Why wrong: B2B guest user settings control how external collaborators are invited and whether certain domains are allowed for guest accounts, but they have no effect on the sign-in access of employees from your own tenant. Restricting allowed domains in B2B configuration would block external users from those domains, yet your internal allowed security groups would remain unaffected, and non-members from your organization could still access Power BI.

Modify the workspace access permissions to include only the allowed security groups.

Why wrong: Workspace permissions like Viewer, Contributor, or Member define what users can do with content inside a specific app workspace, not whether they can sign in to the Power BI service. Even if you remove a user from all workspace access lists, they can still launch Power BI, create their own workspaces, and see their My Workspace, because authentication and general access are governed at the tenant level, not per workspace.

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

Why wrong: 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 wrong: 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 wrong: '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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Configure a Microsoft Purview auto-labeling policy for the workspace.

Why wrong: A Microsoft Purview auto-labeling policy is designed to inspect and label documents sent to cloud storage services using sensitive data classification, but it is not scoped to a single Power BI workspace. Power BI content is not scanned by such policies in the same way, and the policy would not apply only to your target workspace. Therefore it fails the 'all reports in this workspace' requirement.

Set the default sensitivity label for the entire Power BI tenant.

Why wrong: Configuring a tenant-wide default sensitivity label would apply the label to every new item in every Power BI workspace, including ones that should remain unlabeled, creating compliance/governance issues. The requirement is scoped to reports in one workspace, so a broader tenant-level setting is over-intrusive and not the correct granular action.

Instruct all users to manually apply the sensitivity label when creating reports.

Why wrong: Asking users to manually apply the label during report creation is not an automatic enforcement mechanism; it depends on user compliance and can easily be forgotten, leading to unlabeled reports. Administrators need a deterministic, label-based policy to ensure all reports are labeled, not a training-based approach.

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

Why wrong: 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 wrong: 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 wrong: 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.

Deploy Microsoft Purview to scan the reports and enforce access policies

Why wrong: Microsoft Purview is a data governance and catalog service that scans and classifies sensitive data across the estate, but it does not enforce real-time access control for Power BI reports. Access to reports is governed by Azure AD Conditional Access, workspace permissions, and app-level settings. While Purview can apply data policies at the source, it cannot evaluate device compliance or training completion before a user opens a report. Therefore, it is not the appropriate tool for this requirement.

Use row-level security (RLS) to filter data based on user training status

Why wrong: Row-level security (RLS) restricts which rows of data a user sees within a report by applying DAX filters after the user has already accessed the report. It does not control whether that user can open the report in the first place, nor can it inspect device compliance or verify that the user completed required training. RLS relies solely on the signed-in user's identity and role mappings, so it cannot enforce the external conditions described. Thus, RLS is a data-level filter, not an access-control mechanism for the report itself.

Apply sensitivity labels to the reports and require MFA

Why wrong: Sensitivity labels, powered by Microsoft Information Protection, classify and encrypt content to prevent unauthorized sharing or handling of the report data. While labels and MFA add security, neither can evaluate whether the user's device is compliant or whether the user has completed training. MFA only proves something about the user's identity, and sensitivity labels protect the content regardless of the user's context. These measures complement Conditional Access but do not replace it, so they cannot satisfy the specific enforcement requirements.

Row-level security (RLS) is preventing the user from seeing the data

Why wrong: Row-level security (RLS) operates exclusively on data retrieval: it applies filtering predicates at query runtime so users only ever see rows they're authorized for, but it does not govern who can publish, edit, or otherwise manage content in a workspace. The inability to publish is a metadata/management permission issue handled by workspace roles, not by row-level restrictions on the semantic model. Therefore, even if RLS is configured, it wouldn't suppress the Publish button or generate an 'insufficient permissions' error on publication.

The user does not have a Power BI Pro license

Why wrong: Cannot publish to Power BI service without a Pro (or PPU) license is a real prerequisite, but this error is not describing a license failure; if licensing were the issue, the user would typically see a license-prompt or upgrade message, not a workspace-role permission denial. The reported problem stems from the user's role in the target workspace being Viewer, which blocks the publish action regardless of whether they hold a Pro license. In short, licensing answers 'may I use the service?' while the workspace role answers 'may I write to this container?'; the latter is what failed here.

The .pbix file is stored on a network share that restricts write access

Why wrong: The physical location of the .pbix file on a network share is unrelated to the Power BI service publishing pipeline. Publishing sends a copy of the desktop file's model and visuals up to the service through the cloud; whether that share permits write access only determines if you can save local changes back to the original file. If the user has rights to open and publish, a restrictive share permission would manifest as a save-as error, not as a denial from the service when Publish is clicked.

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

Why wrong: 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 wrong: 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 wrong: 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 Azure AD-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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.