Manage compliance by using Microsoft Purview practice questions

Create a sensitivity label with the desired protection settings

Why it fails: A sensitivity label defines the protection outcome—such as encryption and permissions—but it does not scan content or evaluate conditions on its own. The label must exist before you configure auto-labeling, yet creating it is only a foundational step, not the mechanism that triggers automatic application. The actual labeling is performed by an auto-labeling policy that references this label.

Configure a data loss prevention (DLP) rule

Why it fails: Configuring a DLP rule addresses the prevention of sensitive data loss—blocking, restricting, or alerting on content—not the assignment of sensitivity metadata. DLP actions operate on the outbound data path (Exchange, Teams, endpoints, etc.) and cannot stamp a sensitivity label on the source document. To automatically label content based on SIT conditions, Purview requires a separate auto-labeling policy, not a DLP rule.

Retention label applied automatically

Why it fails: A retention label applied automatically controls how long content is kept and when it should be deleted, but it does not lockdown the item during the retention period. Unless the label is configured as a regulatory record or has locked disposition, users with edit permissions can still modify the document, and the label only prevents permanent deletion until the retention period expires. Therefore, it does not meet the requirement to preserve documents in their current state for legal purposes.

Data loss prevention policy

Why it fails: A data loss prevention (DLP) policy is designed to inspect content and block sensitive information from being shared outside the organization, such as credit card numbers or PII. While it can restrict actions like sending or copying data, it does not create a preserved snapshot nor lock the document from editing within the tenant. DLP operates at the transport and sharing layer, not at the storage layer, so it cannot prevent a user from modifying or deleting a document in place.

Sensitivity label with encryption

Why it fails: A sensitivity label with encryption primarily provides access controls by restricting who can open, read, or edit a document based on permissions. Even though encryption prevents unauthorized access, a user with the 'Co-Author' or 'Owner' permission can still modify the content, and encryption does not block deletion by an authorized user. This option protects confidentiality but does not satisfy the requirement to preserve documents in a legally immutable state for compliance.

Litigation Hold

Why it fails: Litigation Hold is a mailbox-level setting in Exchange Online that preserves all mailbox content in place, including deleted items, changed messages, and original versions, for the duration of the hold. It is designed to suspend any permanent deletion or modification of a user's email and, when enabled alongside OneDrive, also protects the user's documents and files. This is the correct tool because a compliance administrator can simply enable the hold on a user without needing to define a search query or associate it with a case, ensuring that every communication is retained while allowing the user to continue working normally.

Retention policy

Why it fails: A Microsoft Purview retention policy is a lifecycle-management rule that applies to an entire location, such as 'all mailboxes' or 'all OneDrive accounts,' and cannot be narrowly scoped to just one user's full mailbox and OneDrive for legal purposes. Even when using adaptive policy scopes, the selection is based on organizational attributes (e.g., department, country) rather than a direct mapping to preserve a specific individual's communications indefinitely. Because the administrator's requirement is to preserve all communications for a particular user without affecting other users, a retention policy is not the precise or appropriate mechanism.

Data Loss Prevention (DLP) policy

Why it fails: Data Loss Prevention (DLP) policies scan outbound and internal messages and files for sensitive data patterns such as credit card numbers or social security numbers, and then apply enforcement actions like blocking the transmission or notifying the user. These policies are reactive and focus on preventing data leakage, not on preserving or holding existing content for compliance or legal scenarios. A DLP policy cannot retain copies of deleted items or keep a static snapshot of a user's communications, so it is entirely unsuited to the stated need.

Retention label policy

Why it fails: A retention label policy manages the lifecycle of content by determining how long items are retained and whether they should be disposed of at the end of that period. Retention labels do not have the intrinsic capability to classify content as confidential or to assign sensitivity-based protection; they operate in the records management and data lifecycle governance realm, not in information protection classification. Because the requirement is to automatically apply a confidentiality label based on sensitive content, a retention label policy is incorrect for this task.

Microsoft Purview Information Protection scanner

Why it fails: The Microsoft Purview Information Protection scanner is a Windows Server service designed to discover, classify, and protect files residing in on-premises file shares, SharePoint Server, and Windows file servers. It cannot connect to SharePoint Online cloud locations, so it is unable to automatically apply sensitivity labels to documents stored in a Microsoft 365 cloud environment. Therefore, it does not satisfy the officer's need for automatic labeling within SharePoint Online.

Microsoft Purview Message Encryption

Why it fails: Microsoft Purview Message Encryption (OME) is a licensing-based feature that is automatically enabled for all Office 365 tenants and does not require separate administrative configuration. It provides the underlying encryption capability used by other methods, but it is not a policy component that can be configured to react to data classification conditions like PCI detection. Simply having OME enabled does not ensure all emails containing sensitive data are encrypted unless a separate policy actively triggers it.

Transport rule with encryption

Why it fails: Exchange transport rules (mail flow rules) can apply OME-based encryption by matching message conditions and assigning rights protection, but this is a legacy approach that relies on the transport pipeline at runtime. Unlike DLP with sensitivity labels, transport rules do not natively integrate with the broader Purview information protection ecosystem and are less flexible across Outlook on the web, mobile, or other endpoints. While technically feasible, Microsoft recommends the DLP-plus-sensitivity-label combination as the modern, streamlined method for email encryption.

Sensitivity label with auto-labeling based on credit card numbers.

Why it fails: Sensitivity labels can encrypt but auto-labeling for email is not as straightforward as DLP for outbound mail; DLP is the recommended approach.

Retention policy for Exchange Online.

Why it fails: Retention policies preserve or delete email, they do not encrypt content.

eDiscovery case for content search.

Why it fails: eDiscovery is used for legal discovery, not for automatic encryption of outgoing emails.

sensitivity label configured with a retention marking

Why it fails: A sensitivity label with a retention marking is incorrect because sensitivity labels are designed for classification and protection—they apply encryption, permissions, or visual headers/footers/watermarks, not lifecycle retention. There is no concept of a 'retention marking' in sensitivity labels; any markings are visual, and sensitivity labels cannot schedule deletion or archive actions. Furthermore, even if a sensitivity label automatically classifies content, it cannot trigger a retention label or retention event. Retention behavior is exclusively controlled by retention labels and policies, not by sensitivity labels.

Data Loss Prevention (DLP) policy with a condition matching 'Project Alpha'

Why it fails: A Data Loss Prevention (DLP) policy with a condition matching 'Project Alpha' is incorrect because DLP policies are enforcement mechanisms that detect sensitive data and prevent unauthorized sharing—for instance, blocking email transmission or restricting external sharing—not tooling for retention lifecycle management. DLP rules can include conditions like keywords, but their actions are limited to alerts or restrictions; they cannot assign retention labels or enforce deletion/archival schedules. Applying retention requires a retention label with an action and an auto-apply policy, not a DLP rule. DLP and retention are complementary but operate in different compliance domains.

eDiscovery hold (Core or Advanced)

Why it fails: An eDiscovery hold in Purview (Core or Advanced) preserves content that matches a specific search query or is associated with an eDiscovery case, not an entire mailbox. It allows you to target specific mailboxes, dates, or keywords, but it requires case management and does not automatically apply a blanket hold to all mailbox items. For a simple, whole-mailbox hold on a single departing user, an eDiscovery hold is more complex and less direct than Litigation Hold.

retention policy with 'Preserved forever' state

Why it fails: A retention policy applied to a mailbox may preserve items, but it applies to all mailboxes in the scope and is less granular for individual legal holds. Litigation Hold is designed specifically for individual mailbox holds.

In-Place Hold (Exchange Online)

Why it fails: In-Place Hold is a legacy hold mechanism inherited from on-premises Exchange Server and has been deprecated in Exchange Online; it is not available through current admin portals. It used the same underlying technology as Litigation Hold but lacked the simplicity and cloud-managed experience of the modern hold option. Administrators should use Litigation Hold or eDiscovery holds instead, making this a non-viable choice.

B: Information Protection (sensitivity labels)

Why it fails: Sensitivity labels are used to classify and protect emails with encryption, permissions, and visual markings, but they do not automate time-based retention or deletion. While labels can be configured to apply a retention label in some cases, that is a different feature and not the label itself; the label alone has no deletion timer. Therefore, sensitivity labels do not meet the requirement for automatic email lifecycle management.

C: Data Loss Prevention (DLP policy)

Why it fails: Data Loss Prevention (DLP) policies inspect email content to detect sensitive information such as credit card numbers or social security numbers and then take actions like blocking or warning the sender. These policies act at the moment of transmission and have no mechanism to schedule later retention or deletion of messages. DLP is an inappropriate choice for enforcing email retention schedules.

D: eDiscovery (content search)

Why it fails: eDiscovery (content search) is designed to search for, place holds on, and export content for legal or regulatory investigations. A hold actually prevents deletion of content, so it works in opposition to the requirement to automatically delete emails after a period. Content search does not provide any automatic retention-then-deletion behavior based on time.

A: Sensitivity label with a retention period of 5 years.

Why it fails: Sensitivity labels with retention can be removed or overwritten by users; they do not guarantee that deletion is blocked.

C: DLP policy to prevent deletion of documents.

Why it fails: DLP policies are not designed to block deletion; they protect data from being shared externally.

D: eDiscovery hold on the site.

Why it fails: eDiscovery holds are for legal preservation and are not intended for routine retention; they also don't automatically delete after 5 years.

Microsoft Purview Data Loss Prevention (DLP) policy

Why it fails: A Microsoft Purview DLP policy is the correct choice because it can continuously scan SharePoint sites for sensitive info types (e.g., credit card numbers) using built-in or custom data loss prevention rules. By setting the action mode to 'Audit only,' the policy identifies and logs matches to the Purview audit log and can raise alerts, without blocking access, copying, or applying any protective action—satisfying the requirement to merely identify documents for review.

Microsoft Purview eDiscovery content search

Why it fails: eDiscovery content search is wrong because it is a manual, on-demand tool: an administrator must construct a KQL query (e.g., for credit card numbers) and run it, after which results are exported or added to a review set. It does not continuously monitor SharePoint to automatically identify new or existing sensitive documents on an ongoing basis, and it is designed for legal discovery and investigations rather than routine compliance identification. Thus it fails the 'automatic identification' requirement stated in the question.

Microsoft Purview Records Management retention label

Why it fails: A Records Management retention label is incorrect because it is designed to govern information lifecycle—specifically how long content is kept and when it is deleted or declared a record—not to detect or flag sensitive data like credit card numbers. Retention labels do not inspect document content for sensitive info types; they only apply classification metadata based on a label policy or user action. Therefore, using a retention label would neither identify the presence of sensitive data nor support a review workflow for such content.

Data loss prevention (DLP) policies and retention labels

Why it fails: DLP policies can detect credit card numbers and block or warn on sharing, but they do not apply sensitivity labels that encrypt documents; retention labels govern lifecycle, not encryption. The pairing is tempting because DLP also scans SharePoint content automatically, yet the requirement is label-driven encryption, needing a sensitivity label and auto-labeling policy.

Sensitivity labels and retention policies

Why it fails: Retention policies govern how long content is kept, deleted or preserved, and never apply encryption. Pairing them with sensitivity labels is tempting because both are Purview information-governance features that act on SharePoint content automatically, but encryption on credit-card detection needs a sensitivity label combined with an auto-labeling policy, not retention settings.

Auto-labeling policies and communication compliance policies

Why it fails: Communication compliance policies detect inappropriate or regulatory-risky communications in Teams, Exchange and Viva Engage, and cannot apply sensitivity labels or encryption to SharePoint documents. They are tempting because both features scan content for sensitive data, but auto-labeling requires a sensitivity label plus an auto-labeling policy, not communication monitoring.

Data Lifecycle Management

Why it fails: Data Lifecycle Management manages retention and disposition, not content discovery and review.

Records Management

Why it fails: Records Management is used to declare items as records and apply retention, not for discovery without protection.

Information Protection

Why it fails: Information Protection labels can be auto-applied and may apply encryption; it is not designed for passive discovery only.

Retention policy

Why it fails: A retention policy applies retention rules to locations but does not declare individual items as records.

Sensitivity label

Why it fails: Sensitivity labels classify and protect data with encryption but do not provide permanent record immutability.

eDiscovery hold

Why it fails: An eDiscovery hold preserves content for legal purposes but does not prevent editing; items can be modified while on hold.

DLP policy and retention label

Why it fails: DLP policies detect sensitive content and can block or restrict sharing, but they do not apply sensitivity labels or trigger encryption; retention labels govern lifecycle, not classification. This pairing is tempting because DLP does detect credit card numbers, yet auto-labeling requires an auto-labeling policy bound to a sensitivity label.

Sensitivity label and DLP policy

Why it fails: A sensitivity label supplies the encryption, and a DLP policy can detect credit card numbers, but DLP alone cannot apply the label automatically in SharePoint Online without user interaction. It is tempting because both components are involved in protection, yet client-side auto-labeling requires an auto-labeling policy.

Auto-labeling policy and retention label

Why it fails: Retention labels control how long content is kept or deleted; they neither classify nor encrypt, so the credit card condition cannot drive label application. The pairing is tempting because auto-labeling policy is genuinely required, but it must be paired with a sensitivity label, not a retention label.

Create a Data Loss Prevention (DLP) policy with the action 'Encrypt email messages'

Why it fails: DLP's 'Encrypt email messages' action relies on Azure Rights Management templates (typically Encrypt-Only or a custom RMS template), which grant read access to the entire organization but do not apply a user-driven 'Do Not Forward' restriction that prevents viewers from forwarding or copying the email. While DLP can trigger encryption based on sensitive content, it cannot attach a sensitivity label containing the specific Do Not Forward action, so it falls short of the compliance requirement.

Create a retention label that encrypts the email

Why it fails: Retention labels are fundamentally a lifecycle management feature: they tag content for retention rules, deletion periods, and disposition review, but they do not have any encryption or Rights Management actions. Applying a retention label to email neither encrypts the message nor restricts forwarding, so it cannot fulfill the compliance officer's need to automatically encrypt and apply a 'Do Not Forward' restriction.

Create a retention label and publish it to the site via auto-labeling policy.

Why it fails: Retention labels do not support automatic classification based on sensitive info types; they are for retention actions.

Use a Data Loss Prevention (DLP) policy to apply the label and configure the policy to block removal.

Why it fails: DLP policies can apply labels but cannot enforce user justification for label removal; that is a label setting.

Deploy the Azure Information Protection scanner to scan SharePoint Online documents.

Why it fails: Azure Information Protection scanner is designed for on-premises file shares and does not integrate with SharePoint Online auto-labeling.

Create a retention label with the action to retain for 5 years then delete, and apply it to the site via auto-labeling.

Why it fails: Auto-labeling applies a retention label to documents that match the conditions in the label, but it does not automatically cover every document in a SharePoint site unless specifically configured with broad conditions, and it still acts on individual items rather than the site container. Since the compliance officer must ensure all documents, including future ones, are retained and deleted, an item-level label cannot guarantee complete site coverage, and it does not provide a preservation hold to protect content that is edited or deleted during the period.

Create a sensitivity label with encryption and set an expiration date for 5 years.

Why it fails: Sensitivity labels are designed for information protection—they classify content and control access through encryption, and an expiration date in the encryption settings only restricts user access after five years, it does not remove the document from the site. Retention and disposition actions are not part of sensitivity labels, so this approach would leave the document in place indefinitely while simply revoking permissions; it also fails to delete content from storage and does not meet the legal retention requirement.

Place the site on an eDiscovery hold with a custom retention period.

Why it fails: An eDiscovery hold is a legal preservation mechanism that suspends all deletion of content—including content that would otherwise expire from a retention policy—and it cannot be configured with a 'custom retention period' to automatically delete after a fixed number of years. Holds are applied to preserve evidence indefinitely or until an administrator explicitly releases the hold, so placing the site on an eDiscovery hold would actually block the desired five-year deletion rather than cause it. Thus it is not a disposition solution.

sensitivity label with auto-labeling for SharePoint and a policy tip

Why it fails: Incorrect. A sensitivity label with auto-labeling for SharePoint is valid, but a policy tip is a DLP feature, not used for sensitivity label override. The override with justification is part of the sensitivity label policy configuration, not a policy tip.

data loss prevention (DLP) policy and a retention label

Why it fails: Incorrect. A DLP policy detects and protects sensitive data but does not apply sensitivity labels automatically. A retention label is for retention, not sensitivity.

default sensitivity label and a compliance tag

Why it fails: Incorrect. There is no 'compliance tag' in Microsoft Purview; sensitivity labels are used. A default sensitivity label applies a label by default but does not auto-detect PII.

5 years

Why it fails: Choosing 5 years reflects only the container-level retention policy and ignores the retention label applied to the documents. In Microsoft Purview, when a label and a policy apply to the same content, the effective retention period is the longest of the two settings. The label's 7-year requirement therefore takes precedence, making 5 years an incomplete answer.

The documents are retained indefinitely due to conflict

Why it fails: Overlapping retention settings do not create a conflict that would cause indefinite retention; Microsoft Purview has a deterministic rule for this situation. The system preserves the content according to the longest retention period and will proceed with a deletion or review at the end of that period. Since 7 years is longer than 5, the documents will be disposed of after 7 years, not kept forever.

The documents are retained for 5 years and then archived

Why it fails: Retention policies and labels do not perform archiving; they either retain or delete content based on the configured period. A document retained for 5 years would not be automatically moved to an archive at that point. Furthermore, the document is actually subject to the label's 7-year period, so the 5-year mark has no operational significance in this scenario.