- What should the report owner do to provide access while maintaining appropriate protection?
Answer: Use an approved external-sharing method and verify that the label's protection permits the partner.
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.
- Which configuration best satisfies both requirements?
Answer: Configure row-level security and apply a Confidential sensitivity label to the Power BI content.
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.
- Which result best describes the expected behavior?
Answer: The report can inherit the label, but its existing Power BI access permissions are not automatically replaced.
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.
- Which approach best meets the requirements?
Answer: Use Microsoft Purview data loss prevention detection and use sensitivity labels for classification and protection.
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.
- What should you expect when the contractor attempts to open the exported file?
Answer: The contractor is blocked because the exported file retains the label and its configured protection.
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.
- Which policy configuration best addresses the requirement?
Answer: Configure Internal as the default label and enable a mandatory labeling policy.
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.
- Which action is required?
Answer: Have an authorized administrator create and publish the label through Microsoft Purview to the executive group.
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.
- What is the most appropriate expectation after the refresh?
Answer: The label remains until an authorized user or applicable policy changes the model's classification.
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.
- Which configuration should the team use?
Answer: Use certification to indicate trust and a sensitivity label to indicate confidentiality.
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.
- Which combination should be used to address both questions?
Answer: Use lineage information for data relationships and sensitivity labels for classification.
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.
