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