Free practice questions

SC-401 practice questions, with full explanations

75 free SC-401 (Administering Information Security in Microsoft 365) questions, each with the correct answer, a breakdown of why every other option is wrong, a memory hook, and the Microsoft Learn reference. Prefer to be quizzed? Take the interactive SC-401 quiz, which scores you by topic and points you to the guide that fits your weak spots.

Sensitivity Labels and Data Classification (10 questions)

Go deeper on this topic in Sensitivity Labels and Data Classification with Microsoft Purview.

You are configuring client-side auto-labeling for a sensitivity label. You want to use an Exact Data Match (EDM) sensitive information type as the only detection condition. After saving the label configuration, no auto-labeling fires on documents that clearly match the EDM SIT. What is the most likely cause?

Correct answer: C. Configuring only an EDM-based SIT as the condition causes the auto-labeling setting to be silently turned off. At least one non-EDM SIT must also be included.

EDM-based custom SITs can be used in label auto-labeling conditions, but Purview silently turns off the auto-labeling setting if an EDM SIT is configured as the only condition with no accompanying non-EDM SIT. A built-in SIT (such as Credit Card Number) must also be included in the label's auto-labeling conditions alongside the EDM SIT.

Why the other options are wrong:

  • A. EDM SITs are supported as auto-labeling conditions, but they cannot be used alone. At least one non-EDM SIT must accompany them, or the auto-labeling setting is silently disabled.
  • B. The encryption model on the label does not affect whether auto-labeling fires based on EDM conditions. The silent disable behavior is specific to EDM-only conditions, not related to encryption settings.
  • D. There is no client restriction that limits EDM-based auto-labeling to Outlook only. The restriction is the requirement for a non-EDM companion SIT, not an app restriction.

Memory hook: EDM SIT alone = auto-labeling silently off. Must pair EDM with at least one non-EDM SIT. Easy to miss because there's no error. It just stops.

Microsoft Learn: https://learn.microsoft.com/purview/apply-sensitivity-label-automatically#how-to-configure-auto-labeling-for-office-apps

A sensitivity label policy is configured with a default label of 'General' and mandatory labeling is also enabled. A licensed user creates a new Word document. Which behavior correctly describes what happens in supported Office versions?

Correct answer: D. The General default label is applied quietly without a prompt, satisfying the mandatory labeling requirement before the user is asked.

When a default label is configured alongside mandatory labeling, the default label takes priority over the mandatory labeling prompt in supported Office versions. The default is applied automatically, satisfying the mandatory requirement, so the user never sees the mandatory labeling dialog. Mandatory labeling without a default generates a prompt; with a default, it is silently satisfied.

Why the other options are wrong:

  • A. There is no double-prompt behavior. The default label is applied before any mandatory labeling dialog would fire.
  • B. Mandatory labeling takes priority only when there is no default label configured. When a default label is present, supported Office clients apply it automatically, and the mandatory labeling requirement is already met.
  • C. These two settings do not conflict. Microsoft documents that the default label takes priority over the mandatory labeling prompt and both can coexist productively.

Memory hook: Default beats mandatory. Set both: quiet coverage. Set mandatory alone: users get a dialog on every file.

Microsoft Learn: https://learn.microsoft.com/purview/sensitivity-labels#what-label-policies-can-do

You are reviewing sensitivity label configurations with a new compliance analyst. They state: 'Once we apply the Confidential label to a file, the label protects the file from being opened by unauthorized users.' Which clarification is most accurate?

Correct answer: B. The label protects the file only if encryption was configured on that label; a label without encryption is metadata that marks but does not restrict access.

A sensitivity label is metadata: it identifies and classifies content. Only if the label is configured with encryption does it actually restrict who can open the file. Encryption is the only label action that genuinely controls access; headers, footers, watermarks, and the label stamp itself are marking and signaling tools, not access controls.

Why the other options are wrong:

  • A. Enabling sensitivity labels for SharePoint and OneDrive allows those services to process labeled content, but the access restriction for a given file comes from the label's encryption settings, not from that service opt-in.
  • C. The license tier governs who can apply labels, not whether an already-applied label with encryption enforces access control. Consumption of encrypted content has a lower license floor.
  • D. The label metadata and encryption travel with the file, but the label itself does not restrict access unless encryption is configured. A plain label with no protection settings is just a sticker.

Memory hook: Label = stamp. Protection = optional. Only encryption restricts. The rest informs.

Microsoft Learn: https://learn.microsoft.com/purview/sensitivity-labels#what-sensitivity-labels-can-do

You are configuring a service-side auto-labeling policy to apply an encrypting label to documents in SharePoint. The label's encryption is configured with dynamically assigned permissions and a 30-day access expiry. When you try to include this label in the auto-labeling policy, you find it cannot be selected for SharePoint and OneDrive locations. What is the reason?

Correct answer: D. Service-side auto-labeling in SharePoint and OneDrive requires labels whose encryption uses 'Assign permissions now' with access set to 'Never expires.' Dynamically assigned or expiring permissions disqualify a label for these locations.

Service-side auto-labeling in SharePoint and OneDrive has specific encryption requirements. The label's encryption must use 'Assign permissions now' and user access must not expire (set to Never). Dynamically assigned permissions (Let users assign permissions) and expiring access are not supported for SPO and OneDrive auto-labeling. Exchange-only policies are more flexible on this requirement.

Why the other options are wrong:

  • A. Service-side auto-labeling supports encryption labels in SharePoint and OneDrive, subject to the 'Assign permissions now, Never expires' requirement. It is not limited to non-encrypting labels.
  • B. The label must be published to at least one user as a prerequisite, but that does not explain why a label with dynamic permissions fails to appear. The disqualifying factor is the encryption configuration.
  • C. Encryption labels can be used with service-side auto-labeling, but only when they meet the specific requirements: Assign permissions now and Never expires. The restriction is not on all encryption, only on certain encryption configurations.

Memory hook: SPO/OneDrive auto-labeling + encryption = must be Assign permissions now + Never expires. Dynamic or expiring = disqualified.

Microsoft Learn: https://learn.microsoft.com/purview/apply-sensitivity-label-automatically#how-to-configure-auto-labeling-policies-for-sharepoint,-onedrive,-and-exchange

A user applies a sensitivity label to a .txt file using the Microsoft Purview Information Protection client on Windows. The label is configured with encryption. After applying the label, the user reports the .txt file now has a .ptxt extension and will only open in a viewer application, not in Notepad. What is the correct explanation?

Correct answer: B. This is expected behavior. The client applies native encryption to text files, which changes the extension (.txt to .ptxt) and requires the Information Protection viewer to open them.

When the Information Protection client encrypts standalone file types like .txt with native encryption, the file extension changes: .txt becomes .ptxt, .png becomes .ppng, and so on. These files must be opened in the Information Protection viewer rather than their native applications. This is documented behavior and is operationally relevant: firewalls, proxies, and DLP tools that key on file extensions can break when they encounter these renamed files.

Why the other options are wrong:

  • A. The extension change is intentional and documented, not a bug. Office formats (like .docx) retain their extensions after native encryption, but standalone file types like .txt, .png, and others change extensions.
  • C. Generic encryption produces a .pfile extension on files it cannot natively encrypt. The .ptxt extension is specific to native encryption of .txt files, which retains the capability to enforce usage rights.
  • D. Double Key Encryption does not change file extensions. Extension changes occur with native encryption on non-Office standalone file types regardless of the key management approach.

Memory hook: .txt becomes .ptxt, .png becomes .ppng. Native encryption on standalone types changes the extension. Proxies and DLP that key on extensions will choke. Check before deploying.

Microsoft Learn: https://learn.microsoft.com/purview/information-protection-client#supported-file-types

You are evaluating whether to enable co-authoring for files encrypted with sensitivity labels in your tenant. Before flipping this setting, which of the following consequences must you evaluate and plan for?

Correct answer: B. Enabling co-authoring changes the labeling metadata format for Word, Excel, and PowerPoint, which can cause apps, scripts, or tools reading from the old metadata location to misread labels or show unencrypted files as unlabeled.

Enabling co-authoring for files with sensitivity labels changes the labeling metadata format and its storage location in Word, Excel, and PowerPoint files. Any app, script, or tool in the tenant that reads labeling metadata from the old location will misread it after the change: it may see labeled files as unlabeled or display stale label names. This is effectively a one-way change: disabling it is PowerShell-only and can lose new-format labeling metadata for unencrypted files.

Why the other options are wrong:

  • A. Co-authoring cannot be reversed through a portal toggle. Disabling requires PowerShell (Set-PolicyConfig -EnableLabelCoauth:$false) and can lose new-format labeling metadata for unencrypted files. It is effectively one-way.
  • C. Co-authoring does not remove or change encryption from existing files. It changes the metadata format only, and encrypted files remain encrypted. Co-authoring of encrypted files requires cloud key, 'Assign permissions now,' and 'Never expires' access.
  • D. Co-authoring is available to Microsoft 365 Apps across licensing tiers, subject to minimum version requirements per platform. There is no restriction to Business vs Enterprise.

Memory hook: Co-authoring on = metadata format change. Old-format readers break. One-way: disable is PowerShell-only and lossy. Inventory tooling FIRST.

Microsoft Learn: https://learn.microsoft.com/purview/sensitivity-labels-coauthoring#metadata-changes-for-sensitivity-labels

You are designing a label taxonomy for a first deployment. Microsoft recommends a specific maximum number of top-level labels beyond which user effectiveness drops noticeably. What is that recommended maximum?

Correct answer: C. 5 top-level labels

Microsoft's own taxonomy guidance states that effectiveness drops noticeably past five top-level labels and five sublabels per top-level label. The technical ceiling is much higher (1,000+ labels in a tenant), but the practical ceiling that preserves user accuracy is five top-level labels. Microsoft's published recommendation is no more than five top-level parent labels, each with five sublabels, for 25 total. Treat 25 as the recommended maximum wall, not the target.

Why the other options are wrong:

  • A. Twenty-five is Microsoft's published recommended total maximum (5 top-level x 5 sublabels), not the recommended count of top-level labels. The practical recommendation is five or fewer top-level labels.
  • B. Ten top-level labels is well beyond what Microsoft recommends. At that count, users struggle to distinguish between labels and classification accuracy degrades.
  • D. Three top-level labels is viable and often sufficient, but Microsoft does not cite 3 as the published maximum. The documented guidance sets the upper bound at 5, not 3.

Memory hook: 5 top-level, 5 children each, 25 total recommended wall. Treat 25 as the guideline limit, not the target.

Microsoft Learn: https://learn.microsoft.com/compliance/assurance/assurance-data-classification-and-labels#what-is-a-data-classification-framework

Your tenant has two label priority orders that interact: file-scoped labels (Personal=0, Public=1, General=2, Confidential=3, Highly Confidential=4) and a container-scoped label (Confidential Sites=5). A user uploads a document labeled Highly Confidential (priority 4) to a SharePoint site labeled with Confidential Sites (priority 5). What happens?

Correct answer: C. No event is generated - the mismatch event fires only when the document's label is MORE sensitive (higher priority) than the site's label; here the document (priority 4) is less sensitive than the site (priority 5), so no event is raised.

The 'Detected document sensitivity mismatch' event fires when a document with a higher-priority label is uploaded to a site with a lower-priority label, not the other way around. If the document label is HIGHER priority than the container label, SharePoint is concerned the sensitive document may be in a less-protected container. In this scenario, the container label has priority 5 and the document has priority 4, meaning the container's priority is higher than the document's. No mismatch event fires because the document is in a more-sensitive-or-equal container.

Why the other options are wrong:

  • A. Documents are never automatically upgraded or downgraded to match container labels. Container and item labels are independent; no inheritance or promotion occurs.
  • B. Uploads are not blocked by label priority mismatches. The SharePoint behavior is to audit and notify, not to block. There is no requirement that document label priority must equal or exceed the container label.
  • D. This answer reverses the mismatch direction. A mismatch event fires when the document's label priority exceeds the container's. Here the container's priority (5) is higher than the document's (4), so there is no event.

Memory hook: Mismatch fires when the DOCUMENT label is higher priority than the CONTAINER label (sensitive doc in a low-security site). Reverse direction = no event. Container higher = fine.

Microsoft Learn: https://learn.microsoft.com/purview/sensitivity-labels-teams-groups-sites

You have two label policies assigned to the same user. Policy A (order 0, lowest priority) has mandatory labeling ON and a default label of General. Policy B (order 1, highest priority) has mandatory labeling OFF and a default label of Confidential. The user creates a new document. What is the effective behavior?

Correct answer: C. The user sees all labels from both policies (union); mandatory labeling is OFF (Policy B wins the conflict); default label is Confidential (Policy B wins).

When a user is in scope of multiple label policies, they receive the union of all labels from all their policies. For setting conflicts, the policy with the highest order number (highest priority) wins for each individual setting. Policy B has the highest order number, so its settings (mandatory labeling OFF, default label Confidential) take precedence over Policy A's settings.

Why the other options are wrong:

  • A. Labels are not exclusive to one policy: the user gets the union of all published labels from all policies. Lowest-priority policy settings do not win over highest-priority settings.
  • B. Labels come from all policies the user is in, not just the highest-priority one. Only settings conflicts resolve to the highest priority policy.
  • D. There is no 'stricter security wins' rule in Purview label policy conflict resolution. The highest-order-number policy wins for each setting, regardless of which is stricter. This is a common misconception.

Memory hook: Labels UNITE across policies. Settings FIGHT: highest order number wins. No 'stricter wins' rule.

Microsoft Learn: https://learn.microsoft.com/purview/sensitivity-labels#what-label-policies-can-do

You configure a service-side auto-labeling policy for SharePoint and OneDrive in simulation mode. After the simulation completes, the admin does not act on the results. What happens to the policy if left untouched?

Correct answer: C. The policy can auto-enable after a set number of days following its last edit (commonly 7 days), effectively turning on without admin action.

If a simulated auto-labeling policy is left untouched after simulation, it can auto-enable itself after a set number of days following the last edit (commonly 7 days; default auto-labeling policies for new customers have a different initial window of 25 days before simulation starts, then 7 after editing). Admins who plan to simulate and decide later may find the policy has turned itself on. The safe approach is to choose 'Leave policy turned off' explicitly if not ready to enforce.

Why the other options are wrong:

  • A. Policies do not expire and do not require recreation. The concern is that they auto-enable, not that they disappear.
  • B. Auto-labeling policies do not wait indefinitely in simulation mode. Microsoft documents that they can auto-enable after a set number of days if left untouched, making inaction a potential unintended decision.
  • D. There is no 'Audit mode' transition for auto-labeling policies. The transition is from simulation to enabled (live labeling), not to an audit state.

Memory hook: Simulation + inaction = policy may auto-enable in ~7 days. Don't 'simulate and decide later.' Choose 'Leave policy turned off' if not ready.

Microsoft Learn: https://learn.microsoft.com/purview/apply-sensitivity-label-automatically#how-to-configure-auto-labeling-policies-for-sharepoint,-onedrive,-and-exchange

Data Loss Prevention (11 questions)

Go deeper on this topic in Data Loss Prevention with Microsoft Purview.

An Endpoint DLP policy is configured to Block the 'Copy to clipboard' activity for files matching a Confidential SIT. A user copies text from a protected Word document. The Block fires. The user waits 30 seconds without clicking Allow. What happens next?

Correct answer: B. For Print, Copy to USB, and Copy to network share, the user has 30 seconds to Allow after the popup; for all other activities including clipboard, the user must redo the action after clicking Allow.

Block with override behaves differently by activity type, and that split is the trap here. Print, Copy to USB, and Copy to network share give the user a 30-second window to click Allow after the popup; clipboard is not on that list. For clipboard, the user must click Allow and then redo the copy action, and nothing auto-proceeds on a timeout.

Why the other options are wrong:

  • A. The user can still proceed by clicking Allow and redoing the copy. The block is not permanent; it is a gate requiring intentional bypass.
  • C. Network quarantine is not triggered by a DLP clipboard block. That is a separate Defender for Endpoint isolation action.
  • D. Clipboard does not auto-proceed after any timeout. The user must actively click Allow and redo the action.

Memory hook: Clipboard Block = active bypass required. User must click Allow and redo the copy; no auto-proceed.

Microsoft Learn: https://learn.microsoft.com/purview/endpoint-dlp-learn-about#endpoint-activities-you-can-monitor-and-take-action-on

You configure Adaptive Protection and an associated DLP policy. A user who is currently at Elevated insider risk level is attempting to share a Confidential-labeled document externally. The DLP policy is set to block sharing of Confidential-labeled documents when the Insider risk level for Adaptive Protection is Elevated. The policy has been enabled for 24 hours. The block is not firing. What is the most likely cause?

Correct answer: D. Adaptive Protection risk levels take up to 36 hours after being turned on before they begin driving DLP enforcement. The policy may simply not have finished activating.

After enabling Adaptive Protection, it can take up to 36 hours before risk levels begin applying and actions take effect. The full quick-setup pipeline can take up to 72 hours. A policy enabled for only 24 hours may not have fully activated. The recommendation is to tune the underlying IRM policy before enabling Adaptive Protection and to account for the 36-72 hour window before expecting blocks to fire.

Why the other options are wrong:

  • A. The 'Insider risk level for Adaptive Protection' condition is supported in Exchange, Teams, and Devices; SharePoint is absent from the documented list. But the scenario never says the sharing happened from SharePoint, so the 36-72 hour activation window remains the far more likely root cause.
  • B. Risk levels in Adaptive Protection are automatically assigned by Insider Risk Management based on user activity. No manual analyst escalation is required for the DLP condition to evaluate the risk level.
  • C. There is no mandatory 7-day audit period before an Adaptive Protection-integrated DLP policy can block. The auto-created DLP policies from quick setup begin in audit mode, but an admin can switch to block without waiting 7 days.

Memory hook: Adaptive Protection: 36 hours minimum before risk levels drive enforcement. Full pipeline can take 72 hours. Tune IRM first, then enable. Don't test same-day.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-adaptive-protection#configure-adaptive-protection

An administrator turns on a new DLP policy with 'Turn it on right away' and immediately sends a test email containing a credit card number. The policy shows no match after five minutes. What is the most likely explanation?

Correct answer: B. Policy activation takes 'as soon as an hour' after creation; the test was run inside the propagation window.

Microsoft Learn states explicitly: 'In general, policies take effect about an hour after being turned on.' The DLP policy reference also says you can run the policy 'as soon as an hour after it's created' by selecting Turn it on right away. Testing within the first few minutes means the policy has not yet propagated across the service.

Why the other options are wrong:

  • A. OCR extends classifiers to images. A plain-text credit card number in an email body does not need OCR.
  • C. Exchange DLP has no business-day restriction. Once the propagation window clears (typically within an hour), evaluation is continuous.
  • D. The administrator selected 'Turn it on right away,' not simulation mode. Simulation would show activity in the simulation dashboard, not produce no result.

Memory hook: DLP has a one-hour patience tax. Any negative test result inside that window is meaningless. Wait, then retest.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-learn-about-dlp#dlp-lifecycle

Your endpoint DLP rollout covers Windows 10/11 devices. Users browse in Microsoft Edge, Google Chrome, and Mozilla Firefox. You need endpoint DLP to monitor and block sensitive uploads to restricted cloud-service domains across all three browsers. What must you deploy, and what is the platform constraint?

Correct answer: D. The Microsoft Purview extension for Chrome and the Microsoft Purview extension for Firefox; Edge needs no extension. The extensions are supported on Windows 10/11 devices only.

Edge is instrumented for endpoint DLP natively and needs no add-on. To extend endpoint DLP activity monitoring and protective actions (upload to a restricted service domain, print, copy to clipboard / removable storage / network share) to Chrome and Firefox, you install the Microsoft Purview extension for Chrome and the Microsoft Purview extension for Firefox respectively. Per Learn, these extensions are for Windows 10/11 devices. Where the extension is installed, it bypasses the unallowed-browser and unallowed-app restrictions for that browser, so monitoring works instead of a hard block.

Why the other options are wrong:

  • A. Adding Chrome/Firefox to the Unallowed browsers list forces users to Edge; it does not give you monitoring within those browsers. Installing the extension is what enables in-browser monitoring, and it bypasses the unallowed lists where installed.
  • B. There is no single universal package. Chrome and Firefox each have their own dedicated Microsoft Purview extension; Edge needs none.
  • C. Endpoint DLP does not natively instrument Chrome and Firefox the way it does Edge. Without the Purview extensions, those browsers are treated as unsupported (and can be redirected to Edge or blocked).

Memory hook: Edge is built in. Chrome and Firefox each need their own Purview extension, and only on Windows. The extension is what turns a hard block into actual monitoring.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-chrome-learn-about

Your organization uses Microsoft Purview DLP. You want to block files shared externally from SharePoint that contain sensitive data, but allow internal users to continue accessing them. Which action should you choose?

Correct answer: B. Restrict access: Block only people outside the organization

The SharePoint/OneDrive 'Restrict access or encrypt content in Microsoft 365' action has sub-options. 'Block only people outside the organization' preserves internal user access while preventing external sharing, exactly matching the requirement. 'Block everyone' removes access for all including internal users and owners.

Why the other options are wrong:

  • A. Block everyone removes access even from internal users and the file owner, which violates the requirement to keep internal access.
  • C. Forward for approval is an Exchange-specific mail flow action. SharePoint does not support message-routing actions.
  • D. Hosted quarantine is an Exchange-specific mail flow action, not a SharePoint content action.

Memory hook: SharePoint block has two modes: nuclear (everyone) and surgical (external only). Match the action to what 'external' means in your requirement.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-policy-reference#rules

An administrator configures a Microsoft Defender for Cloud Apps (MDCA) file policy that targets Box and removes external collaborators from files containing sensitive information. The policy fires as expected on a file owned by an internal user. The same policy is later tested against a file stored in the same Box environment but owned by an external partner who shared it inward. The policy produces no match. What explains the behavior?

Correct answer: A. Files owned by external parties in Box, Google Drive, and Dropbox are invisible to MDCA because those providers treat them as the external party's private data and do not expose them via API.

This reflects a documented MDCA/SaaS connector limitation: externally-owned files in Box, Google Drive, and Dropbox are treated as the external party's private data and are not exposed to the organization's MDCA tenant via API. Unlike OneDrive (which re-assigns an internal owner to externally-dropped files), Box and Dropbox do not expose external-owner files. This is a provider API constraint, not a configuration issue.

Why the other options are wrong:

  • B. Near-real-time scanning affects how quickly files are evaluated, not whether external-owner files are accessible at all.
  • C. There is no 'Include external owners' checkbox. This is a fabricated control. The limitation is a provider API constraint.
  • D. Box is one of the supported MDCA connectable SaaS apps. File policies targeting Box are fully supported for internally-owned files.

Memory hook: Box/Dropbox/Google Drive: externally-owned files are a black box. OneDrive is the exception: it re-assigns ownership and exposes the file.

Microsoft Learn: https://learn.microsoft.com/defender-cloud-apps/protect-box

Two DLP policies are enforced on an endpoint device. Policy ABC: blocks Print and audits all other activities. Policy MNO: blocks Copy-to-USB and audits all other activities. A file matching both policies is opened on the device. A user tries to print the file and simultaneously copy it to a USB drive. What does Endpoint DLP enforce?

Correct answer: A. Print is blocked (from Policy ABC) AND Copy-to-USB is blocked (from Policy MNO). Endpoint DLP aggregates the most restrictive action per activity across matching policies.

Microsoft Learn confirms: 'Endpoint DLP applies the aggregate or sum of most restrictive actions.' Each egress activity is resolved independently using the most restrictive action across all matching policies. Policy ABC contributes a Print block; Policy MNO contributes a USB block. The device enforces both restrictions simultaneously: one per activity, each contributing its restriction.

Why the other options are wrong:

  • B. Conflicting policies do not cancel each other out. The most restrictive action per activity is applied. No conflict produces an 'allow everything' outcome.
  • C. The same one-policy-wins error as option D: Policy MNO's priority does not suppress Policy ABC's Print block.
  • D. Endpoint DLP does not use a 'one policy wins' model. It resolves each egress activity independently using the most restrictive action across all matching policies.

Memory hook: Endpoint = additive. Each egress channel gets the worst (most restrictive) action from all policies that apply. Two policies, two different blocks, and both land.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-policy-reference#rules

You configure an Adaptive Protection DLP policy for Exchange and Teams. The policy uses the 'Insider risk level for Adaptive Protection is Elevated risk level' condition to block external sharing. A compliance analyst asks whether the same condition can be added to a SharePoint-scoped DLP rule to block sensitive document downloads by elevated-risk users. What is the correct answer?

Correct answer: C. No, Adaptive Protection's DLP condition is supported for Exchange, Teams, and Devices, but not for SharePoint or OneDrive.

Microsoft Learn's DLP policy reference confirms: 'When configured in insider risk management, the Insider risk level for Adaptive Protection is will show up as condition for Exchange Online, Devices, Teams, and unmanaged cloud apps locations.' SharePoint and OneDrive are explicitly not in this list. The Adaptive Protection condition cannot be used to protect SharePoint or OneDrive data directly via DLP.

Why the other options are wrong:

  • A. Microsoft 365 group scoping is the requirement for channel message protection in Teams DLP. It is unrelated to Adaptive Protection location support.
  • B. SharePoint and OneDrive are not supported for the Adaptive Protection condition per Microsoft Learn. Admins routinely assume coverage extends there, which is exactly why this gap catches them.
  • D. Advanced classification scanning enables cloud classifiers on endpoints. It has no bearing on whether the Adaptive Protection condition is available for SharePoint.

Memory hook: Adaptive Protection DLP = Exchange, Teams, Devices, and unmanaged cloud apps. NOT SharePoint. NOT OneDrive.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-policy-reference#rules

You are writing a DLP rule for Exchange Online. The rule includes a 'Block with override' action and a user notification. You want users who believe the match is incorrect to be able to flag it for review, but you do not want to require a written justification from users who simply need to send the email for business reasons. Which override configuration achieves this?

Correct answer: C. Notify + Block + Allow override + Allow false-positive report

Microsoft Learn documents two distinct override mechanisms: 'WithoutJustification' (override without requiring a reason) and 'FalsePositives' (allows the user to report it as a false positive). Option C combines them: users can bypass the block with no written justification AND get a structured channel to flag incorrect matches. A bare no-justification override (option D) allows the bypass but throws away the false-positive signal.

Why the other options are wrong:

  • A. Notify only with no block does not trigger an override at all. There is nothing to override if no restriction is applied.
  • B. Require business justification forces users to explain why they are overriding, which the question specifies should not be required for routine business sends.
  • D. Allow override without justification lets users proceed but provides no false-positive reporting channel. The question specifically asks for a way to flag incorrect matches.

Memory hook: Two override signals: justification (why am I sending this?) vs. false-positive report (the detection is wrong). Pick the one that matches your operational question.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-use-notifications-and-policy-tips#options-for-configuring-policy-tips

Your organization wants to detect sensitive content inside images on Windows endpoints (for example, credit card numbers photographed and saved as JPG files). Which prerequisite must be met beyond the standard Endpoint DLP configuration?

Correct answer: A. Enable OCR (Optical Character Recognition) at the tenant level and configure pay-as-you-go billing backed by an Azure subscription.

Microsoft Learn confirms: OCR scanning is an optional feature enabled at the tenant level. It requires pay-as-you-go billing set up via Microsoft Syntex billing in Azure. Once enabled, 'all sensitive information types and trainable classifiers can detect characters that are in images', so you do not need separate image classifiers. Learn also confirms OCR works on Windows endpoints and the default bandwidth limit is 1,024 MB per device per day.

Why the other options are wrong:

  • B. The browser extension enables egress controls in Chrome and Firefox. It is not related to image content classification on endpoints.
  • C. Microsoft Purview Message Encryption applies to Exchange email encryption, not to image content detection on endpoints.
  • D. OCR works by extracting text from images, which is then evaluated by existing classifiers. You do not need a separate image-specific classifier.

Memory hook: Images are invisible by default. OCR = pay-as-you-go Azure billing switch that makes all classifiers see into images tenant-wide.

Microsoft Learn: https://learn.microsoft.com/purview/ocr-learn-about

A DLP policy scoped to OneDrive has an include list containing Security Group B plus one individually listed user, User A. User C is a member of Security Group B but is not individually listed in the policy. According to the policy-scoping behavior described in the manuscript, is User C in scope?

Correct answer: B. No. When you mix individual users and groups in the same include list, DLP scopes the policy to the intersection: the union of the listed groups' members overlapped with the union of the individually listed users. User C is in Security Group B but is not individually listed, so User C falls out of scope.

Microsoft Learn's DLP policy reference explicitly documents this intersection trap: 'when users and groups are mixed in the scoping configuration,' DLP 'only scopes policies to users to the intersection of the listed groups and users.' Learn's worked example shows that with Group1, Group2, User3, and User4 in the include list, only User3 ends up in scope, because User3 is the only user that appears in both the union of group members and the union of listed users. Here the include list mixes Security Group B with individually listed User A, so the intersection rule applies. User C is in the group union through Security Group B but is not in the user union, so User C falls outside the intersection and out of scope.

Why the other options are wrong:

  • A. The group type (mail-enabled vs. Microsoft 365) affects other scoping behaviors (like Teams channel protection) but the mixed-user-and-group intersection trap applies regardless of group type.
  • C. Individual user listings do not override group listings to produce a union. Mixing creates an intersection, which typically produces a much smaller in-scope set than expected.
  • D. The union behavior applies when you list only groups (no individual users). Once you mix individual users and groups, the behavior switches to intersection. This policy's include list contains an individually listed user (User A), so the groups-only union rule does not apply.

Memory hook: Mixed include = intersection. Groups only = union. The instant you add an individual to a group-based include list, you switch from OR to AND and start dropping members.

Microsoft Learn: https://learn.microsoft.com/purview/dlp-policy-reference#policy-scoping

Data Lifecycle and Records Management (10 questions)

Go deeper on this topic in Data Lifecycle and Records Management with Microsoft Purview.

The compliance team needs to verify which retention policies and label policies are applied to a specific SharePoint site. Which tool in the Microsoft Purview portal provides this information, and what is its key limitation?

Correct answer: A. Policy lookup: returns retention policies and label policies for an exact URL or email address, but does NOT surface eDiscovery holds.

Policy lookup, available in Data Lifecycle Management or Records Management in the Purview portal, returns the retention policies and retention label policies assigned to a specific user, site, or Microsoft 365 group. It requires exact identifiers (precise URL or email, no wildcards). Its key limitation is that it does not surface eDiscovery holds. To find those you must check separately using Get-Mailbox (InPlaceHolds) and Get-CaseHoldPolicy in Security & Compliance PowerShell.

Why the other options are wrong:

  • B. The file plan manages retention label definitions and metadata. It is not a tool for showing which policies are assigned to specific SharePoint sites.
  • C. Content Explorer shows labeled content and sensitive info by location; it is not a tool for showing which policies are applied to a location, and it does not surface eDiscovery holds.
  • D. Activity Explorer tracks labeling and sensitivity-label activity events. It does not provide a policy assignment inventory for a given location.

Memory hook: Policy lookup = retention policies + label policies for an exact location. Does NOT show eDiscovery holds. Check holds separately.

Microsoft Learn: https://learn.microsoft.com/purview/retention

Your organization needs to keep all Exchange email for five years and then permanently delete it. Which of the three retention actions should you configure?

Correct answer: B. Retain-then-delete

The Purview retention engine has exactly two primitive actions (retain and delete), yielding three configurable settings: retain-only (prevent deletion for a set period), delete-only (purge after a set age), and retain-then-delete (hold for a period then permanently dispose). 'Keep for five years, then delete' is the classic retain-then-delete pattern and the one most regulators require. Retain-forever is not a distinct setting in the product; it is expressed as retain-only with an unlimited duration.

Why the other options are wrong:

  • A. Delete-only purges content after a set age with no retention period beforehand. It cannot enforce 'keep for five years' because there is no retain component.
  • C. Retain-only preserves the content but never triggers automatic deletion. You would keep it indefinitely, which violates the 'then permanently delete' requirement.
  • D. Retain-forever is not one of the three distinct settings in the Purview retention engine. It is a duration choice (Unlimited) within retain-only, but it also does not satisfy the automatic deletion requirement.

Memory hook: Regulator wants five years then purge? That's always retain-then-delete. The name spells out both halves.

Microsoft Learn: https://learn.microsoft.com/purview/retention

Which two workloads can only be covered by retention policies and NOT by retention labels?

Correct answer: B. Teams messages and Viva Engage messages

Retention labels do not apply to Teams messages or Viva Engage messages. For those workloads, retention policies are the only option, and the retention period always starts from when the message was created. Exchange mailboxes, SharePoint, OneDrive, and Microsoft 365 Groups all support retention labels for item-level retention in addition to policies. This means any retention design that includes Teams or Viva Engage messaging must use at least some policies regardless of the overall labeling strategy.

Why the other options are wrong:

  • A. Half right, which is the trap. Exchange public folders are indeed label-excluded per the Microsoft Learn capability table (learn.microsoft.com/purview/retention#compare-capabilities-for-retention-policies-and-retention-labels), but OneDrive fully supports retention labels, so the pair fails.
  • C. Exchange mailboxes and SharePoint sites both support retention labels at the item level. Labels are a valid (often preferred) mechanism for both.
  • D. OneDrive accounts and Microsoft 365 Group sites both support retention labels. They are not label-restricted workloads.

Memory hook: Teams and Viva Engage = policies only. No labels for messages in those apps.

Microsoft Learn: https://learn.microsoft.com/purview/retention#compare-capabilities-for-retention-policies-and-retention-labels

An adaptive scope for a retention policy was created yesterday targeting the Finance department. An engineer adds a new employee to the Finance group in Entra and expects the policy to apply to that user immediately. How long should the engineer realistically wait before the user is covered?

Correct answer: B. Up to 5 days for the scope query to populate, plus up to 7 more days for the policy to distribute, potentially over a week total.

Adaptive scope queries run daily, but it can take up to five days for a new or changed query to fully populate and for the scope-details member list to reflect added or removed members. After the scope picks up the change, distribution of the policy itself can take up to seven more days. The total realistic end-to-end lag for 'I changed an Entra attribute, when is this user covered' is up to 12 days in a worst-case scenario. If a compliance deadline depends on a specific user being covered immediately, a static scope naming them explicitly is more reliable.

Why the other options are wrong:

  • A. 24 hours would be the minimum if the query happened to run right after the attribute change. The documented maximum for scope population alone is five days, and distribution adds another seven.
  • C. Adaptive scope queries run daily, not hourly. Even the daily cadence does not guarantee instant coverage.
  • D. The scope and policy have separate timers. The scope can take up to five days, and policy distribution adds up to seven days on top of that.

Memory hook: Adaptive scope lag stack: up to 5 days (scope refresh) + up to 7 days (distribution) = wait over a week for new members in the worst case.

Microsoft Learn: https://learn.microsoft.com/purview/purview-adaptive-scopes#configure-adaptive-scopes

An admin publishes a new retention label for Exchange. A user reports the label is not visible in Outlook four days after publication. Should the admin escalate to Microsoft support?

Correct answer: C. No, published Exchange labels can take up to seven days to appear in apps; the admin should wait out the full window before acting.

Published Exchange labels can take up to seven days to surface in Outlook. Four days is still within the normal propagation window. The admin should wait for the full seven-day window before checking the label policy status for an '(Error)' state and only then run Set-RetentionCompliancePolicy -RetryDistribution. Escalating to support at day four for a functioning distribution would be premature.

Why the other options are wrong:

  • A. Published retention labels do appear in Outlook. In the desktop client, users find them via 'Assign Policy' in the ribbon; in Outlook on the web, via right-click, then Advanced actions, then Assign policy.
  • B. The seven-day window is the normal expectation, not a 24-hour one. A distribution error would be visible in the policy status flyout, not inferred from timing alone.
  • D. Four days is within the documented up-to-seven-day window. Escalation before the window expires is premature and wastes support time.

Memory hook: Seven-day clock, not same-day. Don't escalate before the timer expires.

Microsoft Learn: https://learn.microsoft.com/purview/create-apply-retention-labels#when-retention-labels-become-available-to-apply

A retention label is configured to start the retention period 'when an event occurs.' The label has been applied to 200 employee records. An HR administrator accidentally creates an event of the matching event type without specifying any asset IDs or keywords. What is the impact?

Correct answer: B. The retention period starts for all 200 employee records simultaneously, not just the intended individual.

If you create an event without specifying asset IDs or keywords, the retention period triggers for all content carrying that event type's label, not the intended subset. This is documented as an explicit warning in the retention guidance: it is unlikely to be what you intended. The result is that the disposal clock starts for every item with that label, potentially causing premature disposal of records that should not have started their retention period yet.

Why the other options are wrong:

  • A. The system does not block events with no asset ID. You can save them, and they will affect all labeled content. That is why the docs warn against it.
  • C. There is no 30-day rolling window for event-based retention scope. Unscoped events affect all matching labeled content.
  • D. Events do not sort by recency. An event with no scoping applies uniformly to all items carrying the matching label regardless of creation date.

Memory hook: Event with no asset ID = fires for ALL content with that label. Always scope events to the right asset IDs.

Microsoft Learn: https://learn.microsoft.com/purview/retention

Content in a SharePoint site has had its retention period expire. The compliance team wants to permanently delete it as quickly as possible. They run the retention policy delete action, wait 15 days, then check and the content is gone from the main library but still showing up in a site collection admin's Recycle Bin view. Why, and what is the correct expectation?

Correct answer: B. After the Preservation Hold library cleanup phase (up to 37 days), expired content moves to the second-stage Recycle Bin, not immediate permanent deletion. A single 93-day window spans both stages before permanent deletion. The content being visible at day 15 is expected.

Microsoft no longer hard-deletes content directly from the Preservation Hold library. Instead, expired content moves to the second-stage Recycle Bin to prevent accidental loss, where it waits for the remainder of a 93-day window that spans both first- and second-stage bins. At day 15, if cleanup has just processed the PHL (and the content sat there 30+ days), it would only now be arriving in the second-stage Recycle Bin. The 93-day window is still running. This is expected and not a bug. The content is not searchable by eDiscovery while in the Recycle Bin because it is not indexed there.

Why the other options are wrong:

  • A. Content in the Recycle Bin is not indexed, so eDiscovery searches cannot find it and cannot place it on a new hold. This is a hard limitation of the Recycle Bin: it is outside the searchable index.
  • C. The second-stage Recycle Bin is not a system copy separate from retention cleanup. It is part of the documented deletion path for expired retention content. Manual admin emptying would break the 93-day safety window.
  • D. If no new policy was applied, nothing would reinitiate a hold on the expired content. The scenario describes standard post-expiry behavior, not a new hold.

Memory hook: 93-day window = both Recycle Bin stages combined. Content goes from the PHL to the second-stage bin (not hard-delete). Bin content is unindexed, so eDiscovery can't hold it.

Microsoft Learn: https://learn.microsoft.com/purview/retention-policies-sharepoint#how-retention-works-for-sharepoint-and-onedrive

A retention policy uses a static scope with 'All mailboxes' selected for the Exchange location. A new employee's mailbox is created two weeks after the policy was configured. Is the new mailbox covered by the policy?

Correct answer: D. Yes. Org-wide static scopes automatically include any new mailbox created after the policy is applied.

When a static scope is configured as org-wide (All mailboxes, All sites, etc.), new instances created after the policy is applied are automatically included. This is documented as the default 'sticky' behavior for org-wide static scopes. The manual maintenance burden arises only when you switch to specific includes or excludes. At that point you must hand-curate the list. The RetryDistribution cmdlet fixes stuck distributions; it is not a prerequisite for new mailbox coverage.

Why the other options are wrong:

  • A. Adaptive scopes do also pick up new members automatically, but they are not the only mechanism. Org-wide static scopes have the same property.
  • B. Manual list maintenance is required only for static scopes that use specific includes. An org-wide scope automatically picks up new mailboxes.
  • C. RetryDistribution is used to unstick a policy with a distribution error. A correctly distributed policy applies to new mailboxes automatically without needing a retry.

Memory hook: Org-wide = auto-include all new instances. The scope is a net over the whole org, not a named list.

Microsoft Learn: https://learn.microsoft.com/purview/retention-settings#scopes---adaptive-and-static

A document in a SharePoint site is subject to three retention settings simultaneously: a policy that retains content for 7 years (retain-only), a policy that deletes content after 4 years (delete-only), and a retention label that retains for 5 years then deletes (retain-then-delete). Applying the four principles of retention in order, when is the document permanently deleted?

Correct answer: B. After 7 years: the longest retention wins, and the label's delete fires at that point.

Principle 1: retention wins over deletion. The 7-year retain and 5-year retain both suspend all delete actions while they are active. Principle 2: longest retention period wins. The 7-year retain-only policy wins retention. The document is retained until year 7. Principle 3: at the deletion stage, the label's delete action (explicit) beats the 4-year policy's delete action (implicit). The label's delete fires at year 7, not year 5, because principle 1 held the document until retention ended. The 4-year delete-only cannot fire while retention is active.

Why the other options are wrong:

  • A. Retain-only with a 7-year period does have an end date: 7 years from creation. After that retention lapses, the label's delete action fires.
  • C. The label's delete action would fire at year 5 if nothing retained the document past that point. But the 7-year retain-only policy keeps the document alive until year 7. The label wins the 'which delete' contest at principle 3, but principle 1 holds it until year 7.
  • D. Principle 1 prevents any delete action from firing while retention is active. The 4-year delete cannot fire during the 7-year retention period.

Memory hook: Retention beats deletion (P1). Longest wins (P2). At P3, label delete beats policy delete. But P1 still controls WHEN: delete waits until ALL retention expires.

Microsoft Learn: https://learn.microsoft.com/purview/retention#the-principles-of-retention,-or-what-takes-precedence

A colleague insists that turning on a retention policy is a backup solution for SharePoint because 'it keeps copies of everything.' Which misconception does this reflect, and what is the correct statement?

Correct answer: B. Retention only copies content when in-scope items are edited or deleted. It is not a point-in-time backup and does not protect against tenant compromise.

Retention preserves a copy only when in-scope content is edited or deleted. It does not create an initial snapshot, does not protect against tenant compromise, does not give point-in-time restore, and does nothing for data outside the instrumented workloads. The Preservation Hold library stores copies of individual changed/deleted items, not full site snapshots. Retained content stays in the same tenant, within the same storage quotas. Retention and backup are different products solving different failure modes.

Why the other options are wrong:

  • A. Retention has no integration with Azure Backup. Preserved content stays within the same SharePoint site infrastructure, counting against the site's own storage quota.
  • C. Retention does not copy anything on the day the policy is applied. Content stays in place; copies only appear when items are subsequently edited or deleted.
  • D. The Preservation Hold library stores copies of individual items that were edited or deleted, not full site snapshots. It cannot restore an entire site to a point in time.

Memory hook: Retention = compliance net. Backup = time machine. Needing one never buys you the other.

Microsoft Learn: https://learn.microsoft.com/purview/retention-policies-sharepoint#how-retention-works-for-sharepoint-and-onedrive

Insider Risk Management (11 questions)

Go deeper on this topic in Insider Risk Management with Microsoft Purview.

An IRM case investigator wants to take an action that sends the user an email informing them of the policy concern, with the intent of deterring inadvertent future policy violations. Which case action supports this?

Correct answer: A. Send email notice to user: uses a pre-configured notice template and adds the notice to the case notes queue.

Microsoft Learn's IRM cases documentation describes 'Send email notice to user' as one of the case actions, used to send a notice from a pre-configured notice template. Sending a notice does not close the case. It adds the notice to the case notes queue and provides documentation that the user was informed. This is appropriate for inadvertent or accidental cases where deterrence and documentation are the goals. Option B resolves and closes the case. Option C is for legal escalation. Option D's Power Automate template notifies the manager, not the user, and has operational limitations when anonymization is on.

Why the other options are wrong:

  • B. 'Resolve as benign' closes the case. It is not the 'send a warning notice' action. A test-taker who wants to 'resolve and notify' might conflate these two actions.
  • C. Escalation to eDiscovery is appropriate when investigation exceeds the analyst's scope and requires legal review or preservation. Sending a deterrence notice to the user is a much lighter-touch action.
  • D. The Power Automate template for manager notification goes to the user's manager, not the user. Additionally, anonymization limitations affect this template's operation.

Memory hook: Four case actions: notice (to user), resolve benign, share/ServiceNow, escalate to eDiscovery. A notice is not a resolution: the case stays open after you send it.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-cases

What is the maximum activation window (forward scoring period after a triggering event) that an IRM policy can be configured to use? A. 7 days B. 14 days C. 30 days D. 90 days

Correct answer: B. 30 days

Microsoft Learn confirms: 'Activation window is the number of days that the window activates after a triggering event. The window activates for 1 to 30 days after a triggering event occurs for any user assigned to the policy.' The 90-day figure is the past activity detection look-back for non-email signals, not the forward activation window. 7 days is the default risk-level reset timeframe for Adaptive Protection, a different concept. The activation window is configurable from 1 to 30 days on the Policy timeframes page in IRM settings.

Why the other options are wrong:

  • A. 7 days is the default duration for Adaptive Protection risk level assignments, not the activation window. A test-taker who has read the Adaptive Protection chapter and conflates its timeframes with policy activation windows might select this.
  • C. 14 days is not a documented limit for any IRM window. This is a plausible-sounding midpoint distractor.
  • D. 90 days is the past activity detection (look-back) window for SharePoint, OneDrive, and device signals. A test-taker who remembers '90 days' from the scoring chapter but misremembers which timeframe it applies to would select this.

Memory hook: Two timeframes to keep separate: activation window = 1–30 days FORWARD. Past activity detection = up to 90 days BACKWARD (10 days for email).

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-settings-policy-timeframes

You have just created a Data Theft by Departing Users IRM policy. Two weeks later, no alerts have been generated even though several employees have resigned. What is the most likely reason?

Correct answer: C. No user has hit a triggering event: either the HR Connector has not imported resignation dates, or the Entra account-deleted trigger has not fired.

Without a trigger, a user's activity is observed but does not produce alerts. The Data Theft by Departing Users template requires either an HR Connector resignation date or an Entra account-deleted triggering event; if neither has fired for the departing users, the policy is healthy but dormant. This is the most common new-administrator misconception: 'I configured a policy and nothing happened.' The distractors fail on facts: IRM policies do not have a simulation mode the way DLP does, there is no mandatory 30-day baseline requirement, and Priority User Groups are only required for the Priority Users variant.

Why the other options are wrong:

  • A. DLP policies have a test/simulation mode; IRM policies do not have an equivalent. A test-taker who conflates DLP and IRM configuration might select this. The concept simply does not apply here.
  • B. Priority User Groups are an optional configuration that applies only to the 'Data Leaks by Priority Users' template variant. The base Departing Users template applies to any scoped user who hits a trigger, not just priority group members.
  • D. IRM does use cumulative exfiltration detection that compares against baselines, but there is no documented 30-day mandatory waiting period before a policy can generate any alert. A test-taker who has read about the scoring model's baseline behavior might invent this constraint.

Memory hook: Trigger = the on switch. No trigger, no alerts: the policy is dormant no matter how much activity the user generates.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-settings-policy-indicators#types-of-events-and-indicators

Your legal team asks you to preserve the visual forensic-evidence clips tied to an insider-risk case before they age out, so the footage can be entered as evidence in a proceeding six months from now. You confirm the forensic-evidence add-on was configured and capturing before the incident. Which statement about the captured clips is correct and should drive your preservation plan?

Correct answer: A. Captured forensic-evidence clips are retained for 120 days after ingestion; to keep them past that window you must export or transfer them before deletion.

Microsoft Learn states the system retains ingested forensic evidence for 120 days, and you can export the forensic evidence if needed after the 120-day retention period. The clock starts at ingestion (capture), not at case resolution, and it is not tied to whether the case is active. Because your proceeding is six months out, 120 days is not enough; you must export or transfer the clips before they are deleted. Investigators and admins can also delete clips, so a deliberate, governed export is the only defensible way to keep footage long-term.

Why the other options are wrong:

  • B. The 120-day-from-resolution window applies to RESOLVED CASES and their artifacts (and to Needs review / Dismissed alerts and user activity reports), not to forensic clips. Clips run 120 days from INGESTION. The two 120-day numbers are easy to swap, which is exactly the trap.
  • C. Active cases and their associated IRM artifacts (alerts, insights, activities) are retained indefinitely, but forensic-evidence CLIPS are governed by their own 120-day-from-ingestion clock regardless of case status. A test-taker who generalizes the active-case retention rule to clips will pick this and lose the footage.
  • D. Forensic-evidence clips are a paid IRM add-on with their own 120-day retention, not unified-audit-log records. The one-year audit retention for Entra/Exchange/SharePoint/OneDrive applies to audit events, not to captured video clips. This distractor mixes two different retention systems.

Memory hook: Forensic clips: 120 days from CAPTURE (ingestion), not from case close. Need them longer? Export before the clock runs out.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-forensic-evidence-manage#viewing-captured-clips

An IRM alert has been generated for a user who resigned two months ago. The alert severity is High and the primary indicator is a large SharePoint download. The case investigator wants to know how far back IRM looked at the user's activity to include in the risk score. What is the correct answer?

Correct answer: D. IRM looks back a maximum of 90 days for SharePoint signals, but only 10 days for Exchange email signals.

Microsoft Learn's Limits in Insider Risk Management page confirms: 'Lookback period limits (Exchange Online): 10 days. Lookback period limits for all other signals: 90 days.' The policy timeframes page also confirms: 'For activities in the audit log, the window activates for 0 to 90 days before a triggering event occurs for any user assigned to the policy. Note: For email activities, the past activity detection period is 10 days.' SharePoint is one of those 'all other signals', so the large SharePoint download can be scored up to 90 days before the triggering event. However, if the user's email exfiltration happened more than 10 days before the trigger, that email activity would not be scored retroactively.

Why the other options are wrong:

  • A. 30 days is the maximum activation window (forward scoring period), not the look-back. Conflating these two distinct timeframes is the core trap in this question.
  • B. 10 days is the look-back limit for Exchange email only. Applying this limit universally would cause a test-taker to underestimate IRM's look-back capability for non-email signals.
  • C. IRM's past activity detection is explicitly designed for retroactive scoring. The scenario where a user downloads files before their resignation date is exactly the use case for past activity detection.

Memory hook: SharePoint/OneDrive/device look-back = 90 days. Email look-back = only 10 days. Email evidence ages out faster, so export early.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-limits

You are designing an IRM deployment for a multinational organization with employees in Germany, where works council agreements require that no employee's activity be viewable by analysts outside Germany. You configure Administrative Unit scoping for the German analyst team. What additional step is critical to ensure the privacy boundary actually holds?

Correct answer: C. Confirm that each analyst in the scoped German role group does NOT also hold a broader Microsoft Entra role (such as Global Reader or Compliance Administrator), and validate effective access using a test account before treating the AU scope as the privacy boundary.

Microsoft Learn's permissions documentation confirms that members of Microsoft Entra ID Global Administrator, Compliance Administrator, Purview Organization Management, and Purview Compliance Administrator have the same permissions as IRM Admins and can see all data regardless of AU scoping. When a user holds a broader Entra or Purview role alongside a scoped AU role group assignment, the broader role takes precedence and bypasses the AU scope. The validation step (testing with a clean account that holds only the scoped assignment) is critical before relying on AU scoping as an enforceable privacy boundary.

Why the other options are wrong:

  • A. The Investigator role does not override AU scoping. The override mechanism is broader Microsoft Entra roles (Global Reader, Compliance Administrator), not IRM-specific roles like Investigators.
  • B. Pseudonymization is a tenant-wide switch; Learn confirms it applies to 'all users with current and past policy matches.' No per-user or per-group scoping of the setting is documented, so it cannot be enabled for German users only.
  • D. Policy scoping and analyst visibility are separate concerns. An IRM policy scoped to German users determines whose activity gets scored. It does not prevent an analyst with tenant-wide role access from viewing all users' alerts. Analyst visibility is governed by role group and AU scoping, not policy user-scope configuration.

Memory hook: AU scoping only holds if no broader Entra role exists on the same user. Validate with a clean test account before telling the works council it's enforced.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-permissions

An IRM Analyst role group member opens a confirmed insider risk case that has been active for 20 days. They need to read the actual contents of the SharePoint files tied to the case alerts. They find the Content Explorer tab in the case shows 'Nothing to display.' What are the two most likely reasons?

Correct answer: A. Content has not been downloaded into the case (content download may be off or requires triggering 'Add content'), OR the investigator is in the Analyst role group only: Analysts cannot access Content Explorer in cases; that requires the Investigator or IRM (all-in-one) role group.

There are two independent reasons IRM case Content Explorer shows nothing. First, content download: by default, content may need to be added to the case via the 'Add content' action, and there is a maximum number of cases that can hold downloaded content simultaneously. Second, role: IRM Analysts cannot access Content Explorer or forensic evidence in cases. Only IRM Investigators or the all-in-one IRM role group can open Content Explorer. A case with only Analyst-role members can be built but cannot be fully examined, a critical gap.

Why the other options are wrong:

  • B. The opposite is true: Content Explorer stops reflecting NEW activity after a case is 30 days old. It does not require 30 days to become available.
  • C. Files are copied into the case from SharePoint. They don't require local download by the investigator first. The issue is either the 'Add content' step not being triggered or the role missing.
  • D. IRM case Content Explorer access is gated on role group assignment, not on the investigator's own E5 license or Audit Premium status.

Memory hook: IRM case Content Explorer empty: TWO reasons. (1) content not added to case, (2) analyst-only role. Investigators see content; Analysts don't. Analyst-only case = never fully examinable.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/insider-risk-management-content-explorer

Which Microsoft 365 license tiers include Insider Risk Management as of June 2026? Select the best answer.

Correct answer: A. Microsoft 365 E5, Microsoft Purview Suite (formerly E5 Compliance add-on), Microsoft 365 E5 Insider Risk Management standalone SKU, A5, Purview Suite FLW, and G5.

The licensed tiers are Microsoft 365 E5, Microsoft Purview Suite (formerly Microsoft 365 E5 Compliance), the Microsoft 365 E5 Insider Risk Management standalone SKU, Microsoft 365 A5, Microsoft Purview Suite FLW (renamed from F5 Compliance in October 2025), and Microsoft 365 G5. E5 is the most common path, but organizations on E3 can reach IRM through the Purview Suite add-on or the standalone IRM SKU. Microsoft 365 E3 alone does not include IRM, and Defender for Endpoint licensing is unrelated to IRM entitlement. The Microsoft Learn service description confirms IRM is included in 'Microsoft 365 E5/A5/G5, Microsoft Purview Suite/EDU/GOV/FLW and Microsoft Defender + Purview Suite FLW, and Microsoft 365 E5/A5/F5/G5 Insider Risk Management.'

Why the other options are wrong:

  • B. Defender for Endpoint is a separate product licensed separately. IRM does consume Defender alerts as a signal when integrated, but DfE licensing is not what gates IRM entitlement.
  • C. E5 is the most commonly cited path and a test-taker who memorized only that might stop there, missing the education, government, frontline, and add-on SKUs that also carry IRM.
  • D. E3 does not include IRM on its own. A test-taker who knows that E3 includes 'some Purview features' might guess it includes all of them. The more advanced Purview features, including IRM, require E5 or an add-on.

Memory hook: IRM lives at E5 and above, or via the Purview Suite add-on on top of E3. E3 alone leaves you without it.

Microsoft Learn: https://learn.microsoft.com/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-purview-service-description#microsoft-purview-information-protection-sensitivity-labeling

You are configuring IRM for the first time and want to see device-level indicators (USB copies, prints, cloud-sync copies) working in your trial tenant. You have completed the policy configuration and enabled Device indicators globally. After 24 hours, no device-level activity appears. What is the first thing to verify?

Correct answer: A. That at least one Windows device has been onboarded to Microsoft Purview via Device onboarding (Settings, then Device onboarding), and activity was performed from that device.

Device indicators flow through Purview device onboarding (the same channel as Endpoint DLP), not through DLP policy alert severity settings or Defender for Endpoint alert sharing. Without an onboarded device, device-class indicators (USB copy, file print, file copy to cloud sync) never fire. This is the documented first check for missing device activity in IRM. Priority User Group membership is not a prerequisite for device activity to be scored. It is a risk score booster, not a signal prerequisite.

Why the other options are wrong:

  • B. Defender for Endpoint integration feeds the Security Policy Violations template with security alerts. Device-class activity indicators (USB, print, cloud-sync) are not fed through the Defender integration. They come from the Purview device onboarding channel.
  • C. DLP policy severity settings affect the DLP-alert trigger path for Data Leaks policies. Device-level IRM indicators flow through the device onboarding channel, not through DLP alerts. These are two separate signal paths.
  • D. Priority User Groups affect risk score boosters and template scoping, but device-level activity appears for any in-scope user with an onboarded device. Group membership is not a prerequisite for device signals to flow.

Memory hook: Device indicators need device onboarding first. DLP severity, Defender integration, and Priority Groups are all different plumbing, not the device signal path.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-policy-templates#policy-template-limits

An administrator asks how many active cases IRM can hold at one time. What is the limit documented in the manuscript?

Correct answer: D. 100 active cases

Microsoft Learn's Limits in Insider Risk Management page confirms: 'Maximum number of active cases: 100.' This is a genuine operational planning constraint. Active cases are retained indefinitely (they never expire), which makes hitting the 100-case ceiling a real risk for high-volume environments that do not close cases promptly.

Why the other options are wrong:

  • A. Active cases do have a hard limit, and assuming there is none is the kind of error that causes operational problems during a large incident response.
  • B. 500 is not a documented IRM limit for any specific item. It is the items-per-global-exclusion-list limit (domains, sites, file paths, keywords, file types), which a test-taker might conflate.
  • C. 1,000 is a plausible-sounding larger number. The alerts and users export limit is 1,000 per export, which a test-taker might misremember as a case limit.

Memory hook: 100 active cases MAX. Keep cases closed or escalated. Hoarding active cases hits the ceiling.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-limits#other-policy-limits

Your IRM deployment has been running for six weeks. During an investigation you notice that a user's risk score seems unexpectedly high for what appears to be routine activity. Which of the following is the LEAST reliable method for explaining why the score is elevated?

Correct answer: C. Using the absolute numeric risk score to determine exactly which activity contributed the most weight.

Microsoft does not publish the exact base-score formula, the precise weighting per indicator, or the decay model within the activation window. The portal exposes alert severity (Low, Medium, High); the underlying score-to-severity boundary is not documented as a fixed band. The model is adaptive and Microsoft does not document how it is trained. As a result, the absolute numeric risk score cannot be used to determine exactly which activity contributed the most weight. It is a directional signal, not an auditable calculation. Options A, B, and D are all documented investigative inputs: sequence detection (B) is visible in the User Activity timeline; Priority User Group membership and high-impact user detection (D) are documented risk score boosters; cumulative exfiltration detection (A) is a documented ML model input.

Why the other options are wrong:

  • A. Cumulative exfiltration detection is a documented ML model input that identifies when a user is sharing more than their peers. Checking whether it fired is a valid investigation step.
  • B. The User Activity timeline is explicitly recommended as the investigative source of truth. Sequence detection is documented and visible in the timeline. This is a reliable method.
  • D. Priority User Group membership and high-impact user detection are documented risk score boosters. Checking these is a legitimate and reliable diagnostic step.

Memory hook: The absolute risk score is a black box: Microsoft doesn't publish the formula. Trust the activity timeline; use the score as a directional signal only.

Microsoft Learn: https://learn.microsoft.com/purview/insider-risk-management-policies#cumulative-exfiltration-detection

Audit, Alerts, and Investigation (11 questions)

Go deeper on this topic in Audit, Alerts, and Investigation with Microsoft Purview.

DSPM for AI activates a one-click collection policy named 'DSPM for AI - Detect sensitive info shared with AI via network.' Compliance reviewers complain that activity explorer shows the detection but never the actual prompt and response text. What is the correct reason and fix?

Correct answer: D. This collection policy is created without the capture-content option selected; edit the policy and enable content capture to include prompts and responses

For collection policies, no prompt or response is displayed if the content-capture option is not selected. The one-click policy 'DSPM for AI - Detect sensitive info shared with AI via network' does not select that option when it is automatically created, but you can manually edit the policy afterward and enable content capture. That is the documented fix for seeing prompt and response text from this policy.

Why the other options are wrong:

  • A. While reading prompt/response content does require a content-viewing role, the symptom here is that the text is never captured by this policy at all. Granting a role does not display text that the policy did not capture; the capture-content option must be enabled.
  • B. Auditing controls Microsoft 365 Copilot interaction capture. For this network collection policy, the missing text is due to the unselected content-capture option, not disabled auditing.
  • C. Collection policies can capture prompts and responses when the content-capture option is selected; they are not inherently incapable of it.

Memory hook: Network one-click collection policy ships with content capture OFF. See detections but no text? Edit the policy and turn content capture on.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/dspm-for-ai-considerations#activity-explorer-events

Which of the following is required to see the actual text of a Microsoft 365 Copilot prompt and response inside DSPM for AI's Activity Explorer?

Correct answer: A. Content Explorer Content Viewer role group, or the Purview Data Security AI Content Viewer role group.

Reading the actual prompt and response text inside AI Interaction events requires either the Content Explorer Content Viewer or the Purview Data Security AI Content Viewer role group. Standard admin roles (including Entra Compliance Administrator, Entra Global Administrator, and the Purview Compliance Administrator role group) can run DSPM for AI, create policies, and read reports, but the Microsoft Learn DSPM for AI permissions table explicitly marks both Global Administrator and Compliance Administrator as not sufficient for 'View the prompts and responses within AI Interaction events from activity explorer.'

Why the other options are wrong:

  • B. The investigating user does not need a Copilot license to read captured prompts. Copilot licenses are required for users whose interactions are being captured, not for investigators reading those captures.
  • C. Audit Manager grants audit log search and export permissions. It does not grant the ability to read Copilot prompt/response content in DSPM for AI. Those are separate role groups.
  • D. Global Administrator is explicitly listed as NOT being sufficient to read prompt/response content in DSPM for AI per the Learn permissions table. This is a deliberate separation of duties.

Memory hook: DSPM for AI prompt content = Content Explorer Content Viewer OR Data Security AI Content Viewer. Admin roles, even Global Admin, don't crack open prompts.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/ai-microsoft-purview-permissions

A compliance analyst needs to answer two different questions: (1) 'In which SharePoint and OneDrive locations across the tenant do documents containing the Credit Card Number SIT currently reside?' and (2) 'Over the last week, which users downgraded a Confidential label to General, and from which device?' Which Microsoft Purview data-classification tool answers each question?

Correct answer: C. Content Explorer answers question 1 (where sensitive content currently resides); Activity Explorer answers question 2 (what was done to labeled content, sourced from the unified audit logs over ~30 days).

These are the two distinct lenses of data classification. Content Explorer provides a snapshot of where sensitive information currently resides: it indexes items across supported workloads and lets you filter by SIT or label to find their locations. Activity Explorer instead provides a historical view of what is being done with labeled content: label applied/changed/downgraded, DLP matches, endpoint egress, and so on. Activity Explorer's data comes from the Microsoft 365 unified audit logs and reports on up to 30 days of activity, including device name for endpoint events. A label downgrade by a specific user on a specific device is an activity, so it belongs to Activity Explorer.

Why the other options are wrong:

  • A. Activity Explorer is a 30-day historical activity timeline, not a location map. It does not tell you where all current Credit Card content resides across SharePoint and OneDrive.
  • B. Content Explorer shows where sensitive content resides (a snapshot of location), not a timeline of user actions. It cannot tell you who downgraded a label last week.
  • D. This reverses the two tools. Content Explorer = where content lives; Activity Explorer = what was done to it (label downgrades, with the device name filter).

Memory hook: Content Explorer = a map (WHERE is it now). Activity Explorer = a logbook (WHAT happened, last 30 days). Location vs. timeline.

Microsoft Learn: https://learn.microsoft.com/purview/data-classification-activity-explorer

During a compromised-account investigation, an analyst needs to determine whether an attacker read specific emails in the victim's mailbox using a mail client (not just that the email arrived). Which audit event provides this evidence, and what property distinguishes 'desktop Outlook pulled down a whole folder' from 'individual messages were opened'?

Correct answer: A. MailItemsAccessed event; the MailAccessType property: Sync means a client pulled down a whole folder (assume all items compromised), Bind means individual messages were accessed and each is identified by InternetMessageId.

MailItemsAccessed is the audit event that records when mail data is accessed via mail protocols and clients (POP, IMAP, MAPI, EWS, Exchange ActiveSync, REST). Microsoft Learn confirms it is part of Audit (Standard) functionality and is enabled by default for users assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 license. The MailAccessType property distinguishes two access patterns: Bind means individual messages were opened (each identified by InternetMessageId, aggregated in 2-minute windows); Sync means a desktop Outlook client pulled down a folder. Microsoft's guidance: if a Sync occurred in the session context of the suspicious activity, assume every item in that folder was compromised.

Why the other options are wrong:

  • B. MessageReceived (or variations) tells you mail arrived, not that it was read. MailItemsAccessed was designed to close this gap: knowing mail arrived is a notification event, not a breach-scope event.
  • C. The Send event records outbound message activity useful for reconstructing exfiltration and impersonation. It does not record read access to messages in the mailbox.
  • D. SearchQueryInitiated records what the user searched for in Exchange or SharePoint: what they were hunting, not what they read. The SensitivityLabel is a property available on MailItemsAccessed records for users with Audit (Premium), not a property of SearchQueryInitiated.

Memory hook: MailItemsAccessed: Bind = individual message opened (per InternetMessageId). Sync = whole folder pulled by Outlook = ASSUME ALL ITEMS COMPROMISED. Available for E3/E5 users by default (Audit Standard).

Microsoft Learn: https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts

During an investigation of a potentially compromised service account, a security analyst discovers that Get-MailboxAuditBypassAssociation returns True for the account in question. What are the full implications of a MailboxAuditBypassAssociation set to True for a service account?

Correct answer: D. The service account's own mailbox actions, its delegate actions on OTHER users' mailboxes (including shared mailboxes), and admin actions performed by that account are all unlogged, regardless of where they occur.

Microsoft Learn confirms: 'When you configure a user or computer account to bypass mailbox audit logging, access or actions taken by the user or computer account to any mailbox isn't logged.' The specific listing: (1) Mailbox owner actions that the bypassed users perform aren't logged; (2) Delegate actions that the bypassed users perform on other users' mailboxes (including shared mailboxes) aren't logged; (3) Admin actions that the bypassed users perform aren't logged. This is a complete audit blackout for that account. Organizations should audit the bypass list at regular intervals.

Why the other options are wrong:

  • A. The bypass is not mailbox-location-specific. Archive mailboxes, shared mailboxes, and primary mailboxes are all affected when the account has a bypass association.
  • B. The bypass applies to all mailbox actions, not just the account's own mailbox actions. Delegate actions on OTHER mailboxes are also unlogged for a bypassed account.
  • C. The bypass is not operation-specific: read, send, delete, move, and delegate actions all go unlogged. There is no partial bypass by operation type.

Memory hook: MailboxAuditBypassAssociation = True means a COMPLETE audit blackout for that account: own mailbox, delegate access to ALL other mailboxes, admin actions. Nothing logs, anywhere. Check this list regularly.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/audit-mailboxes#bypass-mailbox-audit-logging

A security engineer is automating large-scale audit log extraction and writes a script using Search-UnifiedAuditLog with a single SessionId. After retrieving 43,000 records in the first few pages, the engineer switches the -SessionCommand from ReturnLargeSet to ReturnNextPreviewPage on subsequent calls to get sorted results. The final result set has exactly 10,000 records. What happened?

Correct answer: D. Mixing ReturnLargeSet and ReturnNextPreviewPage against the same SessionId caps output at 10,000 records. The engineer should pick one command per session and stay with it: ReturnLargeSet for volume (up to 50,000, unsorted), ReturnNextPreviewPage for preview (up to 5,000, sorted).

Microsoft Learn explicitly documents this: 'Always use the same SessionCommand value for a given SessionId value. Don't switch between ReturnLargeSet and ReturnNextPreviewPage for the same session ID. Otherwise, the output is limited to 10,000 results.' ReturnLargeSet handles up to 50,000 records but returns unsorted results; ReturnNextPreviewPage handles up to 5,000 records with sorted results. To get sorted results from a large dataset, collect with ReturnLargeSet and sort the assembled collection afterward in PowerShell.

Why the other options are wrong:

  • A. ReturnNextPreviewPage has a 5,000-record maximum (not 10,000) per session. The 10,000 cap the engineer hit is specifically caused by mixing the two session commands.
  • B. There is no 10,000-record daily throttle for Search-UnifiedAuditLog in the tenant. The 10,000 outcome is the documented consequence of mixing SessionCommand values in a single session.
  • C. The 10,000 cap is not RecordType-specific. It occurs when any session mixes ReturnLargeSet and ReturnNextPreviewPage, regardless of which record types are being searched.

Memory hook: NEVER mix ReturnLargeSet and ReturnNextPreviewPage in the same SessionId. Mixing = 10,000 record cap. Pick one: ReturnLargeSet (volume, unsorted, 50k max) OR ReturnNextPreviewPage (preview, sorted, 5k max).

Microsoft Learn: https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/search-unifiedauditlog?view=exchange-ps

An organization's audit log retention policy configuration has the following custom policies in place: Policy A (priority 5): retain Exchange records for 7 years; Policy B (priority 3): retain Exchange records for 30 days. The Premium default policy retains Exchange/SharePoint/OneDrive/Entra records for 1 year. An Exchange audit record is generated today for an E5 user. Which policy applies and why?

Correct answer: A. Policy B (30 days) applies because it has the lower priority number (3) which means highest priority, and any custom policy outranks the built-in default.

Audit retention policy priority rules: (1) lower priority NUMBER = higher priority (wins); (2) any custom policy always outranks the Premium built-in default policy. Policy B has priority 3, Policy A has priority 5, so Policy B wins. Microsoft Learn confirms: 'All custom audit log retention policies (created by your organization) take priority over the default retention policy.' Therefore Policy B (30 days) applies to this Exchange record for the E5 user. The result is 30-day retention despite the Premium default and the 7-year custom policy also matching.

Why the other options are wrong:

  • B. This is the opposite of how it works. Custom policies ALWAYS outrank the Premium built-in default. Built-in defaults are the lowest priority, never the highest.
  • C. Recency of creation has no bearing on audit retention policy priority. The priority NUMBER is the only determinant, with lower numbers winning.
  • D. The 'retention wins over deletion' principle applies to MRM retention labels and retention policies on content, not to audit log retention policy priority. Audit retention policy priority is a pure priority-number contest.

Memory hook: Audit retention priority: lower number = WINS. Custom ALWAYS beats built-in default. Priority 3 beats priority 5 beats the default. Short custom policy can silently cut retention you thought you had.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies

Activity Explorer shows data for which maximum time window, and where does it pull its data from?

Correct answer: B. 30 days; sourced from the Microsoft 365 unified audit log, transformed and surfaced in its own UI.

Activity Explorer reports on up to 30 days of data. That 30-day ceiling is not configurable. Its data is sourced from the unified audit log: Activity Explorer transforms and surfaces audit data in its own UI. Because it draws from the same pipeline, it shares the audit log's ingestion latency. For anything older than 30 days, the audit log itself (or a SIEM fed from the Management Activity API) is the correct tool.

Why the other options are wrong:

  • A. Activity Explorer covers more than just DLP: it surfaces label changes, endpoint DLP file operations, and more. Its data source is the unified audit log, not just DLP alert policies.
  • C. Content Explorer is a snapshot of currently classified content, not a source for Activity Explorer. The 90-day figure is not Activity Explorer's window.
  • D. Advanced Hunting in Defender XDR does provide up to 30 days of data for some tables, but Activity Explorer draws from the unified audit log, not Defender's hunting tables.

Memory hook: Activity Explorer = 30 days, from the audit log. Not configurable. Not 90, not 180. When you need older, go to the audit log directly.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/data-classification-activity-explorer

In DSPM for AI activity explorer, you want to confirm a specific Microsoft 365 Copilot interaction was flagged because it contained a credit card number, even though no active policy targeted it. Which activity explorer event, and under what condition, surfaces that detection?

Correct answer: D. The Sensitive info types event, which for Microsoft 365 Copilot requires auditing to be on but does not require any active policy

For Microsoft 365 Copilot and Copilot Chat, the Sensitive info types event (sensitive information types found while a user interacted with a generative AI site) requires auditing to be turned on but does not require any active policy. That is exactly the case described: a credit card SIT is surfaced from a Copilot interaction purely on the strength of auditing, with no DLP rule needed.

Why the other options are wrong:

  • A. The AI website visit event records that a user browsed to a generative AI site; it does not report which sensitive information types were present in an interaction.
  • B. For Microsoft 365 Copilot and Copilot Chat, the AI interaction event (prompt/response detail) requires auditing; the collection-policy-with-content-capture requirement applies to Copilot in Fabric, Security Copilot, and non-Copilot AI apps, not standard Microsoft 365 Copilot.
  • C. A DLP rule match event only fires when a data loss prevention rule is matched, which requires an active DLP policy. The scenario specifies no policy targeted the interaction.

Memory hook: Sensitive info types from Copilot = audit-only, no policy needed. DLP rule match = needs an active DLP policy.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/data-security-posture-management-considerations#activity-explorer-events-in-data-security-posture-management

A Contoso administrator creates a 10-Year Audit Log Retention add-on retention policy for all Exchange records, assigns the add-on licenses to the relevant users, and believes records from the past 3 years are now covered under the 10-year policy. The administrator is wrong. Why?

Correct answer: A. Audit log retention policies are not retroactive. The expiry of an audit record is set when it is ingested into the pipeline. Records already committed under a shorter retention window keep that shorter lifetime regardless of subsequent policy or license changes.

Microsoft Learn is explicit: 'The audit item lifetime for data is determined when you add it to the auditing pipeline and is based on the licensing defaults or applicable retention policies. Any changes to licensing or applicable retention policies change the expiration time of the audit data after updating. These changes don't affect any previously committed items.' Also: 'This policy isn't retroactive and can't retain audit logs that were generated before the 10-year audit log retention policy was created.' Records already committed under shorter lifetimes keep those lifetimes regardless of subsequent changes.

Why the other options are wrong:

  • B. The 10-Year add-on applies to any workload covered under a matching retention policy, including Exchange. The limitation is not which workload it covers but when it applies.
  • C. There is no support-case mechanism to retroactively extend record lifetimes. Once records expire and are deleted, they cannot be recovered.
  • D. There is no fiscal year boundary rule for audit retention. The policy applies from the date the policy is created and add-on licenses are assigned, going forward.

Memory hook: Audit retention: FORWARD ONLY. Records stamped at write time. Changing policy today changes tomorrow's records, not yesterday's. No retroactive recovery.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/audit-log-retention-policies

After activating DSPM for AI default policies, an admin checks back almost immediately and sees empty Reports and an empty activity explorer. Microsoft 365 Copilot is licensed and auditing is on. What is the most likely explanation?

Correct answer: D. Newly created policies need time (allow at least 24 hours / about a day) to collect data before results appear

Microsoft documents that you should allow at least 24 hours for new DSPM for AI policies to collect data and display results, and to reflect changes you make to default settings. The walkthrough similarly notes you need to wait at least a day for the Reports to be populated. So an immediate empty view with auditing on and Copilot licensed is expected timing, not a misconfiguration.

Why the other options are wrong:

  • A. Viewing the Reports graphs is supported by the standard admin and view-only roles; the Content Viewer role is needed to read prompt/response content, not to render report graphs.
  • B. Activity explorer has an AI activities view and shows AI interaction events such as AI website visits, DLP rule matches, and sensitive info types. It is not limited to audit logs.
  • C. DSPM for AI automatically runs a weekly data risk assessment for top SharePoint sites with no activation, and Reports populate from the default policies. A manual custom assessment is not required for reports to appear.

Memory hook: Empty DSPM reports right after setup usually just means 'give it a day.' Allow ~24 hours for collection.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/dspm-for-ai#how-to-use-data-security-posture-management-for-ai

eDiscovery (11 questions)

Go deeper on this topic in eDiscovery with Microsoft Purview.

A production must deliver RMS-protected (rights-managed) email in a decrypted, readable form to opposing counsel's review platform. You already hold the RMS Decrypt role. In the export settings, which export format choice actually delivers the decrypted messages?

Correct answer: B. Export the search results as individual messages (.msg): decryption of RMS-protected messages on export requires exporting as individual messages; the PST option can leave rights-protected mail still encrypted.

Holding the RMS Decrypt role (assigned to the eDiscovery Manager role group by default) is necessary but not sufficient: the export FORMAT determines whether decryption actually lands. Microsoft Learn states that to enable decryption of RMS-protected messages when you export them, you must export the search results as individual messages (.msg). The 'Create PSTs for messages' option can leave rights-protected mail still encrypted in the PST. So for any production that must deliver decrypted protected mail, choose individual messages, not PST out of habit. (Decryption happens on the way into preview/export, and only Microsoft encryption technologies such as Azure RMS and sensitivity labels are supported; S/MIME, DKE, HYOK, and on-premises RMS are not.)

Why the other options are wrong:

  • A. Decryption is not a download-time, format-agnostic step; it depends on the export format, and only individual-message (.msg) export reliably decrypts RMS-protected mail.
  • C. 'Export item report only' produces CSVs with no native files and no message bodies, so it cannot deliver decrypted messages; its string fields are also truncated to 255 characters.
  • D. PST is the wrong choice for decryption; it can leave rights-protected messages encrypted. Individual .msg export is what decrypts them.

Memory hook: Decrypt RMS mail on export = individual .msg, NOT PST. The RMS Decrypt role alone won't do it; PST can ship still-encrypted.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-decryption#decrypting-rms-protected-email-messages-and-encrypted-file-attachments-by-using-premium-ediscovery-features

An engineer is told to preserve a departing employee's mailbox for a matter. The plan is to delete the employee's account first, then place an eDiscovery hold on the resulting inactive mailbox. Why is this plan wrong, and what is the correct sequence?

Correct answer: A. eDiscovery hold policies aren't supported for inactive mailboxes; you must place the hold on the active mailbox before the account is deleted, which converts it to a preserved inactive mailbox.

Hold policies aren't supported for inactive mailboxes; Microsoft's guidance is that you must place holds on active mailboxes before the mailbox is deleted. When a mailbox that already has an active eDiscovery hold is deleted, its content is preserved as an inactive mailbox and stays searchable and exportable for as long as the hold or case remains active. Placing the hold first (and confirming it applied) is the whole mechanism that turns a departing user's mailbox into a preserved inactive mailbox. Do it in the reverse order and no inactive mailbox is created; the data is gone.

Why the other options are wrong:

  • B. Deleting an account does not auto-apply a hold. Without a hold applied beforehand, the mailbox data is retained only ~30 days as a recoverable soft-deleted account and is then permanently removed. No inactive mailbox is created.
  • C. The leading-dot syntax is for searching an already-inactive mailbox (with -AllowNotFoundExchangeLocationsEnabled $true), not for holding one. You still cannot place a new hold on an inactive mailbox regardless of the address syntax.
  • D. Litigation Hold has the same constraint: it must be enabled on the active mailbox before deletion to make the mailbox inactive. You cannot apply any new hold to a mailbox that is already inactive.

Memory hook: Can't newly hold an inactive mailbox. Hold the ACTIVE mailbox first, THEN delete the account. Reverse order = evidence gone.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-data-sources#add-data-sources-to-searches-and-holds

Counsel wants to preserve only documents that mention 'Project Falcon' across several custodians, so you build a query-based hold using a keyword condition. Some of those custodians' mailboxes contain sensitivity-label-encrypted attachments and other partially indexed files that are central to the matter. What is the defensibility risk, and what does Microsoft recommend?

Correct answer: B. Keyword or path conditions may not apply to encrypted or partially indexed items, so those items might not be preserved; limit query-based hold conditions to Date, Participants, and Type, or use a location-based (infinite) hold.

Microsoft Learn warns that query-based holds using conditions beyond Date, Participants, or Type (such as keywords or paths) might not apply to encrypted or partially indexed items, because that content couldn't be indexed to evaluate against the query. The result is a hold that can silently fail to preserve exactly the items most likely to matter. Microsoft's guidance is to limit query-based hold conditions to Date, Participants, and Type, or apply a location-based (infinite) hold to guarantee coverage. When broad, complete preservation is the legal obligation, a location-based hold is the defensible default; a keyword query-based hold is only safe when counsel agrees the narrowed scope is genuinely acceptable.

Why the other options are wrong:

  • A. The opposite is true: keyword/path conditions may fail to evaluate against encrypted or partially indexed content, risking non-preservation of precisely those items.
  • C. You don't need to (and can't practically) decrypt attachments before holding; the recommended fix is to constrain conditions to Date/Participants/Type or use a location-based hold. A query-based site hold actually preserves all deleted items briefly, then culls non-matches on a timer.
  • D. Query-based eDiscovery holds have no 30-day cap and don't need conversion to retention; they preserve until released. The 30-day figure is the delay-hold grace period after a hold is removed, not the hold's lifetime.

Memory hook: Query hold on encrypted/partially-indexed content = silent gaps. Stick to Date/Participants/Type, or go location-based (infinite). Keywords can't reach unindexed content.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-ref-partially-indexed-items#more-information-about-partially-indexed-items

A litigation matter was run entirely by one eDiscovery Manager who was the sole member of the case. That person has left the company and their account is deleted. Legal now needs the case's holds and review sets. A colleague who is also in the eDiscovery Manager role group cannot see the case at all, and the Organization Management admin also cannot open it. Who can regain access to the stranded case, and how?

Correct answer: C. An eDiscovery Administrator, because that role can view every case in the tenant and can add themselves or another manager as a member of the case.

Case membership is the access boundary in eDiscovery: you can only open a case you created or were added to. When the only member of a case is offboarded, the case becomes a black box. Microsoft states this explicitly: no one, including Organization Management or another eDiscovery Manager, can access such a case because they aren't a member. The single escape is an eDiscovery Administrator, who is the one role that can view and access every case in the organization and can add themselves (or another manager) as a member to recover it. This is exactly why you keep at least one standing eDiscovery Administrator and never create single-member cases.

Why the other options are wrong:

  • A. Microsoft's documentation names Organization Management specifically as unable to access a case they aren't a member of. There is no 'take ownership' path for Organization Management on an orphaned case.
  • B. Global Administrator (an Entra role) does not carry eDiscovery case membership. Case access is scoped by membership plus the eDiscovery role groups, not by tenant admin rights, so a Global Admin cannot simply open an orphaned case.
  • D. An ordinary eDiscovery Manager can only see cases they created or were added to. They cannot even see another manager's case, so they cannot add themselves to it. Only an eDiscovery Administrator has org-wide visibility.

Memory hook: Solo-member case + owner gone = black box. Only an eDiscovery Administrator sees ALL cases and can add themselves back in. Not Global Admin, not Org Management.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-permissions#ediscovery-roles-and-role-groups

Counsel wants a query-based eDiscovery hold that preserves only content matching specific keywords, to save storage. The custodians' mailboxes contain many encrypted and partially indexed items that are likely central to the matter. What is the correct guidance?

Correct answer: D. Keyword or path conditions may not evaluate against encrypted or partially indexed items, so the hold could silently fail to preserve them; limit query-based conditions to Date, Participants, and Type, or use a location-based (infinite) hold.

Query-based holds are unreliable for exactly the content most likely to matter. Microsoft warns that queries using conditions beyond dates, participants, and item types (such as keywords or paths) might not apply to encrypted or partially indexed items, so the hold may not preserve them as intended. To ensure coverage, limit query-based hold conditions to Date, Participants, and Type, or apply a location-based (infinite) hold. Two related nuances: a query-based hold always includes the partially/unindexed items in a held location (it can't evaluate them, so it keeps them), and it won't cull non-matching content at all if more than five holds of any type sit on a location. When broad preservation is the obligation, location-based is the defensible default.

Why the other options are wrong:

  • A. The opposite is true: a query-based hold always includes the partially/unindexed items in a held location, because the system can't confirm whether they match. You don't need to export them first.
  • B. A location-based (infinite) hold preserves everything in the location regardless of encryption or indexing state; it's the safe choice. Encryption doesn't exclude items from holds; it only defeats query evaluation.
  • C. This is the exact misconception the guidance corrects. Keyword (and path) conditions aren't reliably evaluated against encrypted or partially indexed content, so keyword scoping risks under-preservation.

Memory hook: Query-based holds go blind on encrypted/partially indexed items: narrow only by Date, Participants, Type, else hold the whole location.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-hold-create

You are collecting Teams content for a case. You need (1) the messages from a Teams group chat among four people, and (2) the files that were shared inside a private channel of a team. Which content locations must you search for each?

Correct answer: B. Group-chat messages: search each chat participant's mailbox. Private-channel files: search the private channel's own dedicated SharePoint site.

Teams content is journaled to Exchange and SharePoint locations that depend on the conversation type. Messages in 1:1 and group (1:N) chats are stored in the Exchange Online mailbox of every participant, so you search each participant's mailbox. Files shared in a private channel are stored in a dedicated SharePoint site that is separate from the parent team's site, so you must identify and search that channel's own site. Missing either location silently loses evidence: one side of a conversation, or every file in the private channel.

Why the other options are wrong:

  • A. Group chats are not stored in the team mailbox at all (they're in participants' mailboxes), and private-channel files are in a dedicated SharePoint site, not a mailbox. This collapses several distinct locations into one wrong place.
  • C. The participant-mailbox part is right, but files shared in a 1:1 or group chat go to the sharer's OneDrive, whereas files shared in a private channel go to that channel's dedicated SharePoint site. This option applies the chat-file rule to a private channel.
  • D. The parent team's group mailbox holds standard channel messages, not group-chat messages (those are in participants' mailboxes). And private-channel files live in the channel's own dedicated SharePoint site, not the parent team's site.

Memory hook: Group chat = every participant's mailbox. Private-channel files = the channel's OWN dedicated SharePoint site (not the team's).

Microsoft Learn: https://learn.microsoft.com/purview/edisc-search-teams#where-teams-content-is-stored

You're collecting Microsoft Teams content for a case. A custodian participated in a 1:N group chat, posted messages in a standard channel, and shared a file in a private channel. Which set of locations must you search to capture all three?

Correct answer: B. Each group-chat participant's mailbox for the chat, the parent team's mailbox for the standard-channel messages, and the private channel's own dedicated SharePoint site for the shared file.

Teams content is journaled to different locations by conversation type, and collecting the wrong one silently drops evidence. Messages in 1:1 and group (1:N) chats are stored in the Exchange mailbox of every participant, so you search each participant's mailbox. Standard channel messages are stored in the mailbox associated with the parent team. Files shared in a private (or shared) channel live in that channel's own dedicated SharePoint site, separate from the parent team site, so you must identify and search the channel's site, not the team's. (Private-channel messages themselves go to a dedicated private-channel mailbox.)

Why the other options are wrong:

  • A. Only standard/shared-channel messages go to the parent team's mailbox. Group-chat messages live in participants' mailboxes and channel files live in SharePoint, so a team-mailbox-only sweep misses the chat and the file.
  • C. A custodian's Teams data isn't all in their own mailbox: group-chat copies sit in every participant's mailbox, channel messages in the team mailbox, and files in SharePoint. Searching only the custodian's mailbox under-collects.
  • D. It's reversed: standard-channel messages are in the team mailbox (not OneDrive), and private-channel files are in the private channel's own dedicated SharePoint site (not the parent team's site).

Memory hook: Chats go to every participant's mailbox; standard-channel messages go to the team mailbox; private-channel files go to that channel's own SharePoint site.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-search-teams

In a premium review set with analytics run, a reviewer wants to (1) read only the single message in each email thread that already contains all prior replies, and (2) make sure they never cull a message whose body is duplicative but which carries an attachment no other message in the thread has. Which two email-threading fields support this?

Correct answer: C. Is Inclusive identifies the message containing all unique content of the thread; Has Unique Attachments flags a message carrying an attachment not found on any other message in the thread.

Email threading populates two fields for this purpose. Is Inclusive marks the message that contains all the unique content of the thread up to that point, so reviewers can read the inclusive messages and get full context instead of opening every reply. Has Unique Attachments flags an email that carries an attachment not present on any other message in the thread, so a message whose body is fully duplicative is not culled when it holds the only copy of a document. Reading inclusive messages plus anything with unique attachments gives defensible thread coverage, which is safer than Outlook conversation grouping on forks and inline edits.

Why the other options are wrong:

  • A. Dominant Theme and Is Representative belong to Themes clustering and exact-duplicate detection, not email threading. Neither identifies the inclusive message of a thread nor a message's unique attachment.
  • B. Pivot and similarity scores are near-duplicate detection concepts for grouping textually similar documents. They don't drive thread-completeness or attachment-uniqueness decisions in threading.
  • D. MarkAsRepresentative = Unique and Is Group Representative are duplicate/near-duplicate representative markers. They are not the threading fields that identify inclusive messages or unique attachments.

Memory hook: Threading = Is Inclusive (read the message that holds the whole thread) + Has Unique Attachments (never cull the one message with a one-of-a-kind file).

Microsoft Learn: https://learn.microsoft.com/purview/edisc-settings-search-analytics#configure-analytics-settings-for-a-case

Your legal team wants to use premium eDiscovery features (review sets, analytics, tagging) to analyze the mailbox and OneDrive of one custodian under investigation. The three eDiscovery managers and two reviewing attorneys who will operate the case all hold Microsoft 365 E3. Whose licensing determines whether premium analysis is allowed?

Correct answer: A. The custodian whose data is analyzed must have E5 (or the Purview Suite / eDiscovery and Audit add-on); the operators do not need E5.

The premium eDiscovery license requirement attaches to the data subject (the custodian whose mailbox, OneDrive, or other content is analyzed), not to the people operating the tool. Microsoft Learn states that to analyze a user's data with premium features enabled, that user must have Office 365/Microsoft 365 E5, or an equivalent add-on (Purview Suite or the Microsoft 365 eDiscovery and Audit add-on on E3/E1). Administrators, compliance officers, and legal reviewers assigned to the case as members don't need E5 to collect, view, and analyze premium data. (Operators and custodians still need at least E3 to participate in eDiscovery at all.) So premium exposure is scoped by who you analyze, not who clicks the buttons.

Why the other options are wrong:

  • B. Operators don't need E5. Upgrading the managers and attorneys is unnecessary spend; the E5 (or add-on) requirement lands on the custodian whose data is analyzed.
  • C. Enabling the premium toggle is an eDiscovery Administrator setting, but its licensing gate is the custodian's data, not the admin's own license. The admin doesn't need E5 to enable it.
  • D. Only the custodian (data subject) needs E5. Requiring E5 on every case member is exactly the over-buy mistake this per-custodian rule prevents.

Memory hook: E5 rides on the data you analyze, not the hand on the mouse: license the custodian, not the operator.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-permissions

Classic standalone Content Search was retired on which date, and where does Content Search functionality live now?

Correct answer: C. Retired August 31, 2025; now lives inside the unified eDiscovery experience in the Microsoft Purview portal.

Microsoft retired all classic eDiscovery experiences, including classic Content Search, classic eDiscovery (Standard), and classic eDiscovery (Premium), on August 31, 2025. Multiple Microsoft Learn pages carry this explicit caution: 'Microsoft retired all classic eDiscovery experiences on August 31, 2025.' All Content Search functionality is now inside the unified eDiscovery experience in the Microsoft Purview portal, available as a dedicated Content Search case.

Why the other options are wrong:

  • A. Classic Audit Search (the old audit search experience) retired November 30, 2023. Content Search retired August 31, 2025. These are different retirements. The Security & Compliance Center itself was migrated into purview.microsoft.com.
  • B. Advanced Hunting in Defender XDR is a threat-hunting query tool over security telemetry. It is not a replacement for Content Search. Content Search's successor is inside Purview eDiscovery.
  • D. Classic Content Search is definitively retired. The new Content Search experience lives as a case inside the unified eDiscovery in the Microsoft Purview portal.

Memory hook: Content Search retired Aug 31 2025. It lives INSIDE eDiscovery in purview.microsoft.com now. Same queries, new home.

Microsoft Learn: https://learn.microsoft.com/en-us/purview/ediscovery

A production must deliver decrypted, rights-protected (RMS/sensitivity-label-encrypted) email to opposing counsel. The operator holds the RMS Decrypt role. Out of habit, they configure the export with 'Create PSTs for messages.' Why can this leak encrypted mail, and what is the correct export configuration?

Correct answer: B. To have the export decrypt RMS-protected mail, you must export the results as individual messages ('Create .msg files for messages'); the PST option can leave rights-protected mail still encrypted.

eDiscovery decrypts content protected with Microsoft encryption technologies during preview and export, provided you hold the RMS Decrypt role (assigned to the eDiscovery Manager role group by default). But the export format decides whether decryption actually lands: Microsoft's documentation states that to enable decryption of RMS-protected messages on export you must export the search results as individual messages (.msg). The PST option can carry rights-protected mail out still encrypted. So for any adverse production of decrypted protected mail, choose 'Create .msg files for messages,' not PST.

Why the other options are wrong:

  • A. Holding RMS Decrypt is necessary but not sufficient. Even with the role, the PST export format can leave protected mail encrypted. Decryption on export requires the .msg (individual messages) format.
  • C. eDiscovery does decrypt Microsoft-encrypted content automatically during preview and export when you have the RMS Decrypt role; manual per-item decryption isn't required. The requirement is simply the correct export format.
  • D. ScanPST (Inbox Repair) is recommended to repair PST file errors after export; it does not decrypt rights-protected content. It cannot substitute for exporting as individual messages.

Memory hook: Decrypt protected mail on export = export as individual .msg. PST can ship it still encrypted, even with RMS Decrypt.

Microsoft Learn: https://learn.microsoft.com/purview/edisc-decryption#decrypting-rms-protected-email-messages-and-encrypted-file-attachments-by-using-premium-ediscovery-features

Communication Compliance (11 questions)

Go deeper on this topic in Communication Compliance with Microsoft Purview.

Your harassment program must cover hate speech in Exchange email as well as Teams. A colleague proposes the 'Detect inappropriate content' template (Hate, Violence, Sexual, Self-harm classifiers). What is the coverage gap, and how do you close it for email?

Correct answer: B. The content-safety (LLM) classifiers in 'Detect inappropriate content' cover Microsoft 365 Copilot, Teams, and Viva Engage only, not Exchange; for email, use 'Detect inappropriate text' (Threat, Discrimination, Targeted harassment trainable classifiers), whose locations include Exchange Online.

Per the policy guidance, the content-safety classifiers built on large language models (Hate, Sexual, Violence, Self-harm) are supported only for Microsoft 365 Copilot, Teams, and Viva Engage workloads; they do not evaluate Exchange, attachments, OCR images, or Teams meeting transcripts. The 'Detect inappropriate content' template is scoped accordingly to Teams and Viva Engage. To cover email, use 'Detect inappropriate text', which uses the Microsoft-provided Threat, Discrimination, and Targeted harassment trainable classifiers and lists Exchange Online among its locations.

Why the other options are wrong:

  • A. The content-safety classifiers do not run on Exchange at all, so the gap is the entire Exchange channel, not just long emails. The 10,000-character limit is a per-message ceiling on the supported channels, not the reason email is excluded.
  • C. 'Detect inappropriate text' does cover Exchange Online (Threat/Discrimination/Targeted harassment). 'Detect inappropriate images' targets adult and racy images, not text-based hate speech.
  • D. 'Detect inappropriate content' is scoped to Teams and Viva Engage; its LLM classifiers explicitly do not run on Exchange, so it leaves email uncovered.

Memory hook: 'Inappropriate CONTENT' = LLM classifiers, Teams/Viva/Copilot ONLY (no Exchange). For EMAIL harassment use 'Inappropriate TEXT' (Threat/Discrimination/Harassment, includes Exchange).

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-policies#content-safety-classifiers-based-on-large-language-models

A financial-supervision Communication Compliance policy that ran cleanly for months suddenly stops generating any alerts, even though the trading desk is still active. An admin confirms the policy still exists and is not paused. What most likely happened, and what is the correct recovery action?

Correct answer: D. The policy reached its 100 GB or 1 million message storage limit and auto-deactivated, stopping message processing. The correct move is to copy the policy to maintain coverage, not delete it, because deleting permanently destroys all captured messages, attachments, and alerts.

Each Communication Compliance policy has a storage limit of 100 GB or 1 million messages, whichever is reached first. Notification emails go to the Communication Compliance or Communication Compliance Admins role groups at 80, 90, and 95 percent of the limit, and when the limit is reached the policy is automatically deactivated and stops processing messages for alerts. Microsoft's documented continuity move is to copy the policy (identical settings, new scoped mailbox) to maintain coverage. Deleting a deactivated policy permanently deletes all messages, associated attachments, and alerts, so you must not delete it if those items still matter.

Why the other options are wrong:

  • A. The quiet policy is a storage-cap deactivation, not an alert-retention expiry. Auditing is a setup prerequisite whose state would not cause a healthy policy to go silent after months.
  • B. The relevant cap is the per-policy 100 GB / 1 million message limit, not the 50 GB EXO user-mailbox quota, and you can't simply raise it; you copy the policy to resume capture.
  • C. Losing reviewers would block review of alerts, not stop detection and message processing. The silent halt after months of operation matches hitting the storage cap.

Memory hook: 100 GB or 1M messages triggers auto-deactivate (warnings at 80/90/95%). Recover by COPYING the policy. Never delete a capped policy: delete = permanent loss of everything it captured.

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-policies#storage-limit-notification

Before deploying Communication Compliance in Germany, your works council is told 'reviewers cannot see who sent a flagged message.' You enable Settings, then Communication Compliance, then Privacy, then Show anonymized versions of usernames. Which statement most accurately describes the guarantee you can actually make?

Correct answer: C. Members of the Communication Compliance Analysts role group see pseudonyms (for example 'AnonIS8-988'), but members of the Communication Compliance Investigators role group always see real usernames regardless of the setting; and the setting is tenant-wide across all users and all policies.

Per the Communication Compliance planning guidance, 'Show anonymized versions of usernames' anonymizes usernames to prevent the Communication Compliance Analysts role group from seeing who is associated with alerts, but users in the Communication Compliance Investigators role group always see real usernames, not the anonymized versions. It is a solution-wide switch: it anonymizes all users with current and past policy matches and applies to all policies. Usernames are still displayed when adding users to existing policies or assigning users to new policies, because you cannot scope a policy to a pseudonym. So the honest commitment is identity-blind first-line triage, not that no reviewer can ever see identities.

Why the other options are wrong:

  • A. Investigators always see real names; anonymization applies only to the Analysts tier. Telling the works council no reviewer can ever see a person is false and would undermine the program's credibility.
  • B. Anonymization is a single tenant-wide toggle, not a per-policy setting. Enabling it re-pseudonymizes (or reveals) every user with a match across every policy at once.
  • D. Names are deliberately shown at configuration time, when assigning or adding users to policies, because you cannot scope a policy to an anonymized token. Anonymization covers the review experience, not policy assignment.

Memory hook: Anonymization blinds ANALYSTS only; INVESTIGATORS always see real names. Tenant-wide switch (all users/all policies), and names still show when you assign users to a policy.

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-plan#plan-for-the-investigation-and-remediation-workflow

A first-line triage reviewer is a member of the Communication Compliance Analysts role group and is named as a reviewer on a policy. They open a policy match but cannot read the message body or open the Conversation and Translation tabs. What is the correct explanation?

Correct answer: D. The Analysts role group grants viewing of message metadata only; reading message content and opening the Conversation and Translation tabs requires the Communication Compliance Investigators role group.

The Communication Compliance Analysts role group holds the Communication Compliance Analysis role, which Microsoft defines as being able to view message metadata only. The Communication Compliance Investigators role group additionally holds the Communication Compliance Investigation role, which allows viewing message metadata and the message itself. In the permissions matrix, viewing the Conversation and Translation tabs is 'Yes' only for the combined Communication Compliance role and for Investigators. Analysts show 'No.' So an Analyst can triage on metadata but cannot read the body or open those tabs, which is the deliberate separation of duties.

Why the other options are wrong:

  • A. Metadata-only access is by design for Analysts, not a propagation artifact. The up-to-30-minute delay affects when a newly assigned role takes effect, not what an Analyst can see once it does.
  • B. Anonymization pseudonymizes usernames for Analysts; it does not hide message content, and it never applies to Investigators, who always see real names.
  • C. Viewers can access only reports and widgets: no alerts and no message content at all. Adding Viewers would grant less, not more.

Memory hook: Analysts = metadata only. Investigators = metadata + message body + Conversation/Translation tabs. The one-word role difference (Analysis vs Investigation) is the whole gate.

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-permissions

An Investigator selects several serious policy matches and uses 'Escalate for investigation.' Which statement correctly describes what this action does?

Correct answer: D. It creates a new eDiscovery (Premium) case with the custodian auto-filled; you can include up to 100 messages across channels, and creating the case does not resolve or tag the matches.

Escalate for investigation creates a new eDiscovery (Premium) case for one or more selected messages. The custodian is automatically filled in for you, and you don't need additional permissions to manage the case. Creating the case does not resolve the match or add a tag. The match stays in Pending. You can select a total of 100 messages across all Communication Compliance channels for a single case (for example, 50 Teams chats, 25 Exchange emails, and 25 Viva Engage messages). This is an advanced remediation action available to Investigators (and the combined Communication Compliance role), not to Analysts.

Why the other options are wrong:

  • A. Creating the case explicitly does not resolve or tag the match; it remains in Pending so you can still act on the Communication Compliance side.
  • B. No extra eDiscovery permissions are needed: Microsoft states you don't need additional permissions to manage the case. The Investigator role that authorizes the escalation is sufficient.
  • C. That describes plain 'Escalate' (to another reviewer), which stays inside Communication Compliance and does not resolve the item. Escalate for investigation instead spins up an eDiscovery (Premium) case. The action that auto-resolves a match is Notify, not a peer escalation.

Memory hook: Escalate FOR INVESTIGATION = new eDiscovery (Premium) case, custodian auto-filled, up to 100 messages, does NOT resolve/tag, no extra eDiscovery permission. (Plain 'Escalate' = peer reviewer.)

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-investigate-remediate

An admin scopes a Communication Compliance policy using a Microsoft 365 Group instead of a distribution group, expecting the policy to inspect each member's individual email and Teams chats. What is the actual detection behavior, and what does Microsoft recommend?

Correct answer: C. Assigning a Microsoft 365 Group detects messages sent to the group, not the individual messages each member sends or receives; Microsoft recommends distribution groups so each member's own messages are detected.

Microsoft's group chart is explicit: when you assign a distribution group, the policy detects all emails and Teams chats from each user in the group; when you assign a Microsoft 365 Group, the policy detects all emails and Teams chats sent to the Microsoft 365 Group, not the individual messages received or sent by each member. Because of that difference, Microsoft recommends using distribution groups so each member's individual communications are automatically detected.

Why the other options are wrong:

  • A. They behave differently: a distribution group captures each member's own messages, whereas a Microsoft 365 Group captures messages sent to the group. That distinction is the whole point.
  • B. This reverses the two. It is the distribution group (not the Microsoft 365 Group) that captures each member's individual messages.
  • D. Both distribution groups and Microsoft 365 Groups are supported for scoped users; individual users are not the only option.

Memory hook: Distribution group = messages FROM each member. Microsoft 365 Group = messages sent TO the group. Want per-member coverage? Use a distribution group.

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-configure#step-3-optional-set-up-groups-for-communication-compliance

Fabrikam wants external recipients to access encrypted email only through the secure web portal so that the organization can later revoke and expire those messages. An engineer asks which PowerShell cmdlet creates a new custom branding template to enable this, and notes that Fabrikam already has Microsoft Purview Message Encryption set up. Which cmdlet is correct, and what is the licensing condition?

Correct answer: D. New-OMEConfiguration creates a new custom branding template, and creating custom (non-default) templates requires Microsoft Purview Advanced Message Encryption.

Microsoft Learn states: 'If you have Microsoft Purview Advanced Message Encryption, you can create custom branding templates for your organization by using the New-OMEConfiguration cmdlet. Once you've created the template, you modify the template by using the Set-OMEConfiguration cmdlet... You can create multiple templates.' Learn also lists New-OMEConfiguration as 'Create a new branding template, Advanced Message Encryption only.' Set-OMEConfiguration modifies the default template or an existing custom template but does not create one. The custom branding template is what forces external recipients into the portal experience, which is the prerequisite for revocation and expiration.

Why the other options are wrong:

  • A. Set-OMEConfiguration modifies the default branding template or a custom template that already exists; it does not create a new one. Creating new templates also requires Advanced Message Encryption, not just any Exchange Online license.
  • B. Set-OMEMessageRevocation revokes an already-sent message; it has nothing to do with creating branding templates. It is also an Advanced Message Encryption capability, not an E3 feature.
  • C. New-TransportRule creates a mail flow rule that applies a branding template; it does not create the template itself. The branding template is created with New-OMEConfiguration.

Memory hook: New-OMEConfiguration = create custom template (AME only). Set-OMEConfiguration = modify default or existing. Remove-OMEConfiguration = delete custom (never the default).

Microsoft Learn: https://learn.microsoft.com/purview/add-your-organization-brand-to-encrypted-messages#create-an-encrypted-message-branding-template-advanced-message-encryption

In Communication Compliance settings, an admin enables 'Show anonymized versions of usernames.' Which statement correctly describes the effect of this setting?

Correct answer: C. Usernames are anonymized for the Communication Compliance Analysts role group, while Communication Compliance Investigators always see real usernames; usernames are still shown when assigning users to policies.

With 'Show anonymized versions of usernames' on, user names are anonymized to prevent members of the Communication Compliance Analysts role group from seeing who is associated with alerts (Grace Taylor appears as a pseudonym such as AnonIS8-988). Members of the Communication Compliance Investigators role group always see real user names, not the anonymized versions. The setting applies to all users with current and past policy matches and to all policies, but user names are still displayed when adding users to existing policies or assigning users to new policies (you cannot scope a policy to a pseudonym).

Why the other options are wrong:

  • A. Anonymization is a single tenant-wide toggle for the whole solution; it is not a per-policy setting.
  • B. Investigators always see real names; the setting never anonymizes them. It also applies only to the Communication Compliance experience, not to other Purview solutions or the admin center.
  • D. Enabling it anonymizes all users with current AND past matches, applied retroactively across every policy, not just future matches.

Memory hook: Anonymization = one tenant-wide switch that blinds Analysts only. Investigators always see real names, and names always show when you assign users to a policy (you can't scope a ghost).

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-plan

An administrator is documenting the recipient experience for Microsoft Purview Message Encryption. A Microsoft 365 recipient in another tenant, a Gmail recipient, and a recipient at a small ISP with no Microsoft, Google, or Yahoo identity each receive an encrypted message. Which description matches Microsoft's documented behavior?

Correct answer: A. The Microsoft 365 recipient reads the message inline in supported Outlook clients; the Gmail recipient authenticates to the encrypted message portal using their Google credentials; the ISP recipient with no supported social identity uses a one-time passcode.

The recipient's identity decides the experience, in three tiers. A Microsoft 365 recipient reading in Outlook 2016 or Outlook on the web gets the inline experience and doesn't have to take any other action to view the message. Accounts outside Microsoft 365, such as Gmail, Yahoo, and Microsoft accounts, are federated with the OME portal, so the Gmail recipient authenticates to the portal with their Google identity. All other identities, like the ISP recipient with no Microsoft, Google, or Yahoo account, fall back to a one-time passcode sent to their address.

Why the other options are wrong:

  • B. Microsoft Purview Message Encryption is specifically designed to work with Outlook.com, Gmail, Yahoo, and other email services. External recipients can absolutely view the mail through the portal; they are not locked out.
  • C. One-time passcode is only the fallback for identities that aren't federated (not Microsoft, Google, or Yahoo). Microsoft 365 recipients use the inline experience and Gmail recipients can sign in with their Google identity, so 'OTP for everyone' is wrong.
  • D. Gmail does not render Microsoft Purview encrypted mail inline; the Gmail recipient gets a wrapper directing them to the portal. The Microsoft 365 recipient is the one who gets the inline experience with no extra steps, not an OTP. This option inverts both behaviors.

Memory hook: Inline = Microsoft 365 / Microsoft account in Outlook. Federated portal sign-in = Gmail / Yahoo / Microsoft account. One-time passcode = everyone else with no supported identity.

Microsoft Learn: https://learn.microsoft.com/purview/ome-version-comparison#advantages-of-microsoft-purview-message-encryption-over-legacy-ome

A user at Contoso applies the Encrypt-Only option to an outbound email in Outlook on the web. The recipient, an external business partner, asks whether they will be able to print the message and forward it to a colleague. Which statement correctly describes the recipient's rights under Encrypt-Only?

Correct answer: C. The recipient has all usage rights except Save As, Export, and Full Control, so they can copy, print, and forward the message but cannot remove the encryption.

Microsoft Learn states for the Encrypt-only option: 'the email is encrypted and recipients must be authenticated. Then, the recipients have all usage rights except Save As, Export and Full Control. This combination of usage rights means that the recipients have no restrictions except that they can't remove the encryption. For example, a recipient can copy from the email, print it, and forward it.' Encrypt-Only is the permissive option: it guarantees the message stays encrypted in transit and at rest, but it deliberately does NOT restrict what an authenticated recipient can do with the content. The only thing the recipient cannot do is strip the protection (Save As / Export / Full Control are withheld).

Why the other options are wrong:

  • A. Full Control is precisely one of the three rights (Save As, Export, Full Control) that Encrypt-Only withholds. A recipient cannot remove the encryption, so they cannot re-share the content unprotected.
  • B. Encrypt-Only does not force the portal experience, and recipients are never stripped of reply rights. Whether a recipient uses the inline experience or the web portal depends on their identity type, not on the Encrypt-Only option.
  • D. This describes Do Not Forward, not Encrypt-Only. Under Do Not Forward, Learn states recipients 'can't forward it, print it, or copy from it.' Encrypt-Only is the opposite end of the spectrum and applies no usage restrictions.

Memory hook: Encrypt-Only = encrypt the pipe, not the behavior. Recipients can copy / print / forward; they just can't peel off the encryption (no Save As / Export / Full Control).

Microsoft Learn: https://learn.microsoft.com/purview/rights-management-usage-rights#encrypt-only-option-for-emails

While building a Communication Compliance policy, an admin tries to assign a mail-enabled security group as the policy's reviewer so the whole compliance team can triage alerts. The group cannot be added. What is the correct requirement for reviewers?

Correct answer: B. Reviewers must be individual users, each with a mailbox hosted on Exchange Online, and each must already be in the Communication Compliance Analysts or Investigators role group; groups of any type can't be assigned as reviewers.

Microsoft's policy-creation guidance states plainly that 'Reviewers are individual users and all reviewers must have mailboxes hosted on Exchange Online,' and the planning guidance adds that reviewers must be assigned to either the Communication Compliance Analysts or Communication Compliance Investigators role group and be named in the specific policy they review. The supported-groups table lists no supported group types for reviewers: distribution groups, dynamic distribution groups, nested distribution groups, and mail-enabled security groups are all unsupported as reviewers. Adding a reviewer also sends an automatic notification email, which is why an EXO mailbox is required.

Why the other options are wrong:

  • A. Reviewers need a reviewer role group (Analysts or Investigators) plus policy assignment plus an EXO mailbox, not Global Administrator. Microsoft recommends minimizing Global Admins.
  • C. Being in a role group is necessary but not sufficient; a reviewer must also be named in the specific policy. The Admins role group can't review alerts at all; it configures policies only.
  • D. No group type is supported as a reviewer, including a mail-enabled security group. Reviewers must be individual users.

Memory hook: Reviewers = individual users only (no groups, ever) + EXO mailbox + Analysts/Investigators role + named on that policy. Four gates, all required.

Microsoft Learn: https://learn.microsoft.com/purview/communication-compliance-configure#step-5-required-create-a-communication-compliance-policy