Microsoft Power BI Quiz: Data Protection And Sensitivity Labels
10 questions · exam conditions
0:00
Data Protection And Sensitivity LabelsQuestion 1 of 10

A sales report contains data for several regions. Account managers must see only the rows assigned to their region. If report data is exported to a supported file format, the file must remain classified as Confidential and retain the organization's configured protection.

Which configuration best satisfies both requirements?

Apply a Confidential sensitivity label and grant account managers the Build permission on the semantic model.
Configure row-level security and apply a Confidential sensitivity label to the Power BI content.
Configure object-level security and certify the semantic model for use by account managers.
Place each region in a separate workspace and mark every workspace as highly promoted.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Data Protection And Sensitivity Labels

Practice Data Protection And Sensitivity Labels in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Data Protection And Sensitivity Labels, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A sales report contains data for several regions. Account managers must see only the rows assigned to their region. If report data is exported to a supported file format, the file must remain classified as Confidential and retain the organization's configured protection.

Which configuration best satisfies both requirements?

  1. Apply a Confidential sensitivity label and grant account managers the Build permission on the semantic model.
  2. Configure row-level security and apply a Confidential sensitivity label to the Power BI content. (correct answer)
  3. Configure object-level security and certify the semantic model for use by account managers.
  4. Place each region in a separate workspace and mark every workspace as highly promoted.
Explanation: When a Power BI question mentions both data access restrictions and export protection, you're being tested on two distinct security layers that must work together: row-level security (RLS) and sensitivity labels. RLS controls which rows of data a user can see within a report or semantic model. By configuring RLS roles mapped to each account manager's region, Power BI automatically filters the dataset so users only see their assigned data — exactly what the first requirement calls for. Sensitivity labels, when applied to Power BI content, travel with the data when it's exported to supported formats like Excel or PDF. This means the "Confidential" classification and its associated Microsoft Purview Information Protection policies persist in the exported file, satisfying the second requirement. Option B delivers both capabilities cleanly. Option A falls short because the Build permission allows users to create new content from the semantic model — it does not restrict which rows they can see. Without RLS, an account manager could access all regions. Option C introduces object-level security (OLS), which hides entire columns or tables, not specific rows by region. Certifying the semantic model also has nothing to do with export classification. Option D separating regions into workspaces might isolate data at a workspace level, but "highly promoted" is a discoverability endorsement, not a security control — and this approach doesn't address export labeling at all. Your study tip: on the Power BI exam, always map each requirement to a specific feature. RLS = row filtering, sensitivity labels = export protection. When a question has two requirements, look for the answer that addresses both, not just one.

Question 2

A report is labeled Confidential. The label is configured in Microsoft Purview with encryption that permits only employees to open protected files. An authorized employee exports the report to a supported PowerPoint format and sends the file to an external contractor who is not included in the label's permissions.

What should you expect when the contractor attempts to open the exported file?

  1. The contractor can open the file because Power BI export permission replaces the label's encryption permissions.
  2. The contractor can open the file read-only because sensitivity labels classify files but never encrypt them.
  3. The contractor is blocked because the exported file retains the label and its configured protection. (correct answer)
  4. The contractor is blocked only while the original report remains stored in the Power BI service.
Explanation: When you see questions about sensitivity labels in Power BI, the core concept to understand is that Microsoft Purview sensitivity labels travel with the data — they aren't just metadata tags that get stripped during export. The label, along with any encryption it carries, is applied directly to the exported file itself. In this scenario, the Confidential label is configured with encryption that restricts access to employees only. When an authorized employee exports the report to PowerPoint, Power BI inherits that protection and embeds it into the file. The contractor, who falls outside the label's permission scope, will be blocked by Microsoft's Information Protection encryption engine when attempting to open the file — regardless of who sent it or how. This makes C the correct answer. Choice A is wrong because export permissions in Power BI do not override or replace Purview label encryption. Exporting simply means you're allowed to create the file; what the file does once created is governed by the label's protection policy. Choice B reflects a common misconception — sensitivity labels can absolutely enforce encryption, not just classification. Classification-only labels exist, but this question explicitly states the label is configured with encryption. Choice D introduces a false dependency: the protection is embedded in the file itself and is enforced by Microsoft's rights management infrastructure, not by whether the original report is still in Power BI. The file is independently protected once exported. Your study tip: always ask yourself whether a label in a question is configured with encryption. If it is, that protection follows the file everywhere — export, email, USB drive — and is enforced against anyone outside the permitted group.

Question 3

Downstream sensitivity-label inheritance is enabled for the organization. An unlabeled report in the Power BI service uses a semantic model that is later labeled Highly Confidential. No workspace roles or sharing settings are changed.

Which result best describes the expected behavior?

  1. The report becomes inaccessible because inheriting a label automatically removes all existing workspace permissions.
  2. The semantic model loses its label because an upstream item cannot be more restrictive than a report.
  3. The report remains unlabeled because labels can propagate only from reports to semantic models.
  4. The report can inherit the label, but its existing Power BI access permissions are not automatically replaced. (correct answer)
Explanation: When you see a question about sensitivity labels in Power BI, focus on two separate systems: label inheritance (how confidentiality labels flow between items) and access permissions (workspace roles, sharing links, RLS). These two systems operate independently, and confusing them is the core trap in this question. When downstream sensitivity-label inheritance is enabled, Power BI can automatically propagate a label from a semantic model to dependent items like reports. So when the semantic model gets labeled Highly Confidential, the unlabeled report can inherit that label — this is exactly what the feature is designed to do. Critically, this inheritance only updates the metadata label on the report; it does not touch workspace roles, sharing settings, or any other permission configuration. Answer D captures this precisely: the report can inherit the label, but existing access permissions remain unchanged. Answer A is wrong because label inheritance has no mechanism to revoke workspace permissions — it is purely a metadata operation, not an access-control action. Confusing classification labels with security enforcement is a common misconception. Answer B reverses the logic of downstream inheritance entirely. Labels propagate downstream — from semantic models to reports, not the other way around. There is no rule preventing an upstream item from having a more restrictive label than a downstream one. Answer C gets the direction of propagation backwards. In Power BI, inheritance flows from semantic models (upstream) down to reports and dashboards, not from reports up to semantic models. Study tip: Always keep label inheritance and permission management in separate mental buckets — on the Power BI exam, questions often test whether you recognize that sensitivity labels classify data but do not automatically enforce access control.

Question 4

A report owner applies an External Confidential sensitivity label to a report and assumes that this action automatically gives a partner access to the report. The partner is not a guest in the tenant and has not received a sharing invitation.

What should the report owner do to provide access while maintaining appropriate protection?

  1. Replace the sensitivity label with a Promoted endorsement so that the partner can discover the report.
  2. Use an approved external-sharing method and verify that the label's protection permits the partner. (correct answer)
  3. Grant Build permission to the semantic model because a sensitivity label already authorizes report viewing.
  4. Remove the label before sharing because labeled Power BI content cannot be shared with external users.
Explanation: When you see a question mixing sensitivity labels with external sharing in Power BI, remember that these are two separate systems with distinct purposes. Sensitivity labels control protection and classification of content; they do not replace the tenant's sharing and access mechanisms. A sensitivity label like "External Confidential" classifies data and may apply encryption or usage restrictions through Microsoft Purview, but it does nothing to grant a partner login credentials, a sharing link, or permission within the Power BI workspace. The report owner must still use a legitimate external-sharing method — such as a guest invitation (Azure AD B2B) or a shareable link configured for external users — and then confirm that the label's protection settings actually permit that partner to open and interact with the content. That two-step thinking is exactly what B captures: share through an approved channel and verify the label allows it. A is wrong because endorsements (Promoted or Certified) are discoverability and quality signals, not access-control tools. A Promoted endorsement helps users find trusted content in the data catalog; it does not open a security boundary for external partners. C is wrong because sensitivity labels do not authorize viewing. Build permission on the semantic model gives users the ability to create new content from the dataset, and it still requires the partner to be in the tenant or properly invited — the label changes nothing about this requirement. D is wrong and dangerously so. Labeled Power BI content can be shared externally; the label's purpose is to travel with the data and enforce protection, not to block all sharing entirely. On this exam, treat sensitivity labels and Power BI permissions as parallel, independent layers — neither one substitutes for the other.

Question 5

A compliance team wants to identify Power BI semantic models that may contain passport numbers and notify owners when such data is detected. The team also wants owners to classify confirmed sensitive content appropriately.

Which approach best meets the requirements?

  1. Use Microsoft Purview data loss prevention detection and use sensitivity labels for classification and protection. (correct answer)
  2. Use sensitivity labels alone because every label automatically scans all model values for passport numbers.
  3. Use row-level security detection and use workspace roles to classify confirmed sensitive semantic models.
  4. Use semantic model certification because certification automatically detects and encrypts regulated identifiers.
Explanation: When a question asks about detecting sensitive data and classifying it in Power BI, you need to think about two distinct tools working together: something that actively scans for regulated content, and something that applies protective labels once confirmed. Microsoft Purview Data Loss Prevention (DLP) policies are designed exactly for proactive detection — they can scan Power BI semantic models for sensitive information types like passport numbers and automatically alert dataset owners when a match is found. Sensitivity labels then give those owners a structured way to classify and protect confirmed sensitive content, controlling access, encryption, and downstream usage. Answer A correctly combines both capabilities to satisfy both requirements: detection and classification. Answer B is a common trap. Sensitivity labels are classification and protection tools — they do not automatically scan model values for sensitive data types like passport numbers. Applying a label is a manual or policy-driven action, not a content-scanning engine. Answer C confuses access control with compliance workflows. Row-level security (RLS) restricts which rows a user can see; it has nothing to do with detecting sensitive content or notifying owners. Workspace roles govern what users can do in a workspace, not how sensitive data is identified or flagged. Answer D misrepresents certification entirely. Semantic model certification is a trust and endorsement feature — it signals that a dataset meets quality standards. It performs no automated scanning for regulated identifiers and provides no encryption tied to data classification. A useful study pattern: on Power BI governance questions, map each requirement to its dedicated tool. Detection → Purview DLP. Classification and protection → sensitivity labels. Mixing these up is exactly what the wrong answers are designed to exploit.

Question 6

A semantic model was labeled Highly Confidential because it included employee compensation data. The compensation columns are later removed, and the model is refreshed successfully. No user changes the label.

What is the most appropriate expectation after the refresh?

  1. The label is automatically removed because a successful refresh always reevaluates the business meaning of the data.
  2. The label changes to Public because deleting sensitive columns overrides the organization's label policy.
  3. The model becomes unlabeled temporarily and receives its previous label after the next scheduled refresh.
  4. The label remains until an authorized user or applicable policy changes the model's classification. (correct answer)
Explanation: When you encounter questions about sensitivity labels in Power BI, the key concept to anchor yourself to is label persistence: sensitivity labels, once applied, are sticky by design. They exist independently of the data's current contents and are not automatically reevaluated by system events like refreshes. In this scenario, the Highly Confidential label was assigned by a human (or policy) and reflects a classification decision — not a live scan of the data. When the compensation columns are removed and the model refreshes successfully, Power BI has no built-in mechanism to interpret why the data changed or whether those changes lower the sensitivity level. The label therefore remains exactly as it was. D is correct: only an authorized user or a configured label policy (such as Microsoft Purview's auto-labeling rules) can change the classification going forward. A is wrong because a successful refresh does not trigger any business-meaning reevaluation. Refresh is a data operation, not a governance operation — Power BI doesn't inspect column content to decide if a label still fits. B is wrong because deleting columns has no built-in override effect on labels; sensitivity labels don't cascade or downgrade based on schema changes alone. C is wrong because there is no "temporary unlabeled" state during refresh cycles — the label persists continuously and is never stripped and reapplied by the scheduler. A useful study tip: think of sensitivity labels like a physical stamp on a document. Erasing words inside the document doesn't remove the stamp — a person must consciously decide to re-stamp it. This analogy maps directly to how Power BI and Microsoft Purview handle label persistence.

Question 7

A workspace administrator wants to create a new organization-wide sensitivity label named Executive Restricted and make it available only to the executive group. The administrator can manage all content in the workspace but has no Microsoft Purview administrative role.

Which action is required?

  1. Create the label in the workspace settings and assign it through the workspace access list.
  2. Have an authorized administrator create and publish the label through Microsoft Purview to the executive group. (correct answer)
  3. Create a deployment pipeline stage named Executive Restricted and assign executives as pipeline viewers.
  4. Certify the workspace's semantic models and limit endorsement visibility to the executive group.
Explanation: Whenever you see a question about sensitivity labels in Power BI, remember that these labels are not managed within Power BI itself — they live in Microsoft Purview (formerly Microsoft Information Protection). This distinction is critical because it means Power BI workspace administrators, regardless of how much control they have over the workspace, cannot create or publish sensitivity labels on their own. Sensitivity labels must be created and published by someone with a Microsoft Purview administrative role (such as Compliance Administrator or Information Protection Administrator). Once created, labels are published to specific users or groups through Purview's label policies — which is exactly how you'd restrict a label like "Executive Restricted" to only the executive group. That's why B is correct: the workspace administrator must request that an authorized Purview admin create and scope the label appropriately. A is wrong because sensitivity labels cannot be created inside workspace settings at all. Power BI workspaces don't have a label-creation interface — that functionality simply doesn't exist there. C is a red herring that confuses sensitivity labels with deployment pipelines, which are entirely separate features used for promoting content across development, test, and production environments — not for data classification or access restriction. D conflates endorsement (certification/promotion of semantic models for discoverability) with sensitivity labeling; endorsement controls trust and visibility of assets but has nothing to do with creating or assigning sensitivity labels. A useful rule of thumb: if a question involves creating or publishing sensitivity labels, the answer will always point outside of Power BI to a Purview-level administrator. Power BI can apply labels but never create them.

Question 8

An organization requires newly created Power BI content to start with the Internal classification. Authors may select a more restrictive label, but they must not be able to save governed content without any sensitivity label.

Which policy configuration best addresses the requirement?

  1. Configure Internal as an endorsement and require every workspace to use deployment pipelines.
  2. Configure Internal as the only available label and disable report export throughout the tenant.
  3. Configure Internal as the default label and enable a mandatory labeling policy. (correct answer)
  4. Configure Internal as a workspace name prefix and require semantic model certification.
Explanation: When you see a question about sensitivity labels in Power BI, focus on two distinct policy levers: default labeling (what label is pre-applied) and mandatory labeling (whether users can save without any label at all). The requirement here has two parts — new content should start with "Internal," and users must not be able to save unlabeled content. That's precisely what option C delivers. Setting Internal as the default label means every new item is automatically tagged with Internal when created. Enabling a mandatory labeling policy then prevents users from removing all labels and saving — they must keep at least one label, though they can escalate to something more restrictive like Confidential or Highly Confidential. Together, these two settings satisfy both requirements cleanly. Option A confuses endorsement (a trust/quality feature for promoting datasets and reports) with sensitivity classification — these are entirely separate systems in Power BI, and endorsement has no bearing on data protection labels. Option B is overly restrictive and doesn't actually solve the problem; limiting to one label prevents users from choosing a more restrictive label, which violates the requirement that they may do so. Disabling export is also unrelated to labeling enforcement. Option D misapplies workspace naming conventions and semantic model certification — again, these are governance features unrelated to sensitivity label policies. A useful study tip: on Power BI governance questions, always separate the information protection plane (sensitivity labels via Microsoft Purview) from the content governance plane (endorsement, certification, deployment pipelines). Mixing them up is the most common trap in this category.

Question 9

An auditor asks two questions about a confidential executive report: where the report obtains its data and whether the report and its supporting semantic model are classified appropriately. The organization wants to use native Power BI governance capabilities.

Which combination should be used to address both questions?

  1. Use row-level security for data origin and workspace roles for item classification.
  2. Use endorsements for data origin and deployment pipelines for item classification.
  3. Use lineage information for data relationships and sensitivity labels for classification. (correct answer)
  4. Use sensitivity labels for data relationships and lineage information for encryption.
Explanation: When an auditor asks where data comes from and whether items are properly classified, you're being tested on two distinct Power BI governance tools that map directly to those two concerns: lineage and sensitivity labels. Lineage view in Power BI Service visually traces data relationships — from data sources through dataflows, datasets (semantic models), and reports. It answers the auditor's first question: "Where does this report get its data?" You can follow the chain upstream to see exactly which sources feed the model. Sensitivity labels (integrated via Microsoft Purview/Information Protection) let you tag reports and semantic models with classifications like "Confidential" or "Highly Confidential." They answer the auditor's second question by ensuring items are appropriately labeled, and those labels can enforce downstream protections like encryption. This makes C the correct combination. A is wrong because row-level security controls who sees which rows of data — it has nothing to do with documenting data origins. Workspace roles govern access permissions, not classification labels. B is wrong because endorsements (Certified/Promoted) indicate trustworthiness and quality, not data lineage. Deployment pipelines manage promoting content across dev/test/prod environments — they are not a classification mechanism. D reverses the tools entirely. Sensitivity labels handle classification (not data relationship mapping), and lineage is for tracing data origins (not encryption). Swapping their purposes makes this answer definitively wrong. Your study tip: memorize these pairings — lineage = data origin tracing, sensitivity labels = data classification. On the exam, auditor or compliance scenarios almost always point to these two features together.

Question 10

A data governance team wants users to distinguish between two characteristics of a semantic model: whether its data is trusted for enterprise reporting and whether its content is confidential.

Which configuration should the team use?

  1. Use certification to indicate trust and a sensitivity label to indicate confidentiality. (correct answer)
  2. Use a sensitivity label to indicate trust and certification to enforce confidentiality.
  3. Use promotion to enforce confidentiality and row-level security to indicate trust.
  4. Use workspace membership to indicate trust and an endorsement to encrypt exports.
Explanation: When you see a question about distinguishing data quality from data sensitivity in Power BI, think about two separate feature categories: endorsements (which communicate trustworthiness) and sensitivity labels (which communicate confidentiality). Power BI offers two levels of endorsement — promotion and certification. Certification is the higher-trust tier, typically granted by authorized administrators, signaling that a dataset is officially validated for enterprise reporting. Sensitivity labels, integrated through Microsoft Information Protection, classify content by confidentiality level (e.g., Public, Confidential, Highly Confidential) and can trigger protective actions like encryption on export. Answer A correctly pairs certification for trust with a sensitivity label for confidentiality — exactly what the governance team needs. Answer B reverses the tools entirely. Sensitivity labels don't convey trustworthiness; they flag confidentiality risk. Certification doesn't enforce confidentiality — it signals quality. Swapping them produces a configuration that misleads users on both dimensions. Answer C introduces row-level security (RLS) and promotion, neither of which fits here. RLS restricts which data rows a user can see — it's an access control tool, not a trust indicator. Promotion is a lower-tier endorsement that any workspace member can apply; it doesn't enforce confidentiality. Answer D confuses workspace membership (an access management concept) with endorsement, and incorrectly describes endorsements as encrypting exports — that's actually a behavior tied to sensitivity labels, not endorsements themselves. A useful memory anchor: endorsements = trustworthiness, sensitivity labels = confidentiality. On the exam, any answer that swaps or conflates these two distinct systems is a distractor.