VanArsdel Ltd's compliance officer wants to give end users limited control over their quarantined emails. Specifically, users should be able to release their own emails quarantined by spam filtering without admin involvement. However, emails quarantined because of phishing or malware detections must require admin approval before any release — end users should only be able to request a release, not perform it themselves. How should the Microsoft 365 administrator configure this?
Select an answer to reveal the explanation.
Short Explanation
You need separate quarantine policies: one lets users self-release spam-quarantined mail, and another lets them only request release for phishing or malware. You apply each policy to the matching threat protection policy, so you get the exact tiered control without transport-rule hacks.
Full Explanation
The correct approach is to create a quarantine policy granting users self-release permission and apply it to the spam filter policy; create a separate quarantine policy granting users request-release-only permission and apply it to the anti-phishing and anti-malware policies. Microsoft Defender for Office 365 quarantine policies allow administrators to precisely define what end users can do with their quarantined messages. By creating two separate quarantine policies — one granting 'Release messages' (self-release) permission for spam, and another granting 'Request release' (admin-approval-required) permission for phishing and malware — and then assigning these policies to the respective threat protection policies, VanArsdel Ltd achieves exactly the tiered access model required. Quarantine policies can be applied per-protection-type within the anti-spam, anti-phishing, and anti-malware policies under Microsoft Defender for Office 365.
The approach that sets all threat protection policies to use the default quarantine policy with No access for end users is incorrect because setting No access for all quarantine policies would prevent end users from doing anything with their quarantined spam messages, which contradicts the compliance officer's requirement that spam emails should be self-releasable. This over-restricts user capabilities.
The approach that enables quarantine notifications globally and configures users to have full release permissions for all quarantined mail from the default quarantine notification settings is incorrect because enabling quarantine notifications and granting full release permission is an all-or-nothing approach that applies the same permissions globally. This would give users the ability to self-release phishing and malware quarantined emails, which violates the requirement that those categories require admin approval. Notifications can be enabled independently of release permissions.
The approach that creates Exchange transport rules that automatically release spam-quarantined messages and route phishing-quarantined messages to a manager approval mailbox is incorrect because Exchange mail flow rules (transport rules) operate on messages before or during delivery — they cannot be used to manage messages that are already held in quarantine. Transport rules cannot route quarantine-release requests to a manager approval mailbox. This is not how Exchange transport rules function.
Exam tip: Quarantine policies are a key feature tested on AB-650. Remember the three main user permission presets: No access (users cannot see or interact with quarantined mail), Limited access (users can request release but not self-release — admin must approve), and Full access (users can self-release, block sender, and delete). You can also create custom policies with granular permissions. The key is that each threat policy (anti-spam, anti-phishing, anti-malware, Safe Attachments) can reference a different quarantine policy.