The hard set (6 questions)
The hardest SC-401 questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book for this exam holds the full bank.
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: Edisc search Teams
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: Edisc ref partially indexed items
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: Edisc hold create
A mailbox is already covered by five separate retention policies and eDiscovery holds. You then add a sixth, query-based eDiscovery hold to that mailbox, expecting non-matching items to be trimmed from the hold. What actually happens to content that doesn't match the query?
Correct answer: A. Because more than five holds of any type apply to the location, the query-based hold doesn't clear non-matching content, so all content is preserved
A query-based hold normally clears content that doesn't match the query every 7 to 14 days. However, if more than five holds of any type apply to a content location, the query-based hold does not clear non-matching content - effectively everything in the location is preserved. Partially indexed and unindexed items are always preserved as well.
Why the other options are wrong:
- B. There's no five-hold cap that blocks additional holds; the sixth hold applies fine.
- C. The 7-to-14-day clearing only happens when five or fewer holds apply; with six holds it stops.
- D. Query-based holds are supported on both mailboxes and SharePoint sites.
Memory hook: More than 5 holds on a location = query-based hold stops trimming; keep everything.
Microsoft Learn: Edisc hold create
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: Edisc decryption
An employee is leaving. Legal wants the full contents of their Exchange Online mailbox preserved and searchable for potential litigation for several years, but Finance does not want to keep paying for a Microsoft 365 license for a departed user. What is the correct approach?
Correct answer: D. Apply a hold (a Microsoft 365 retention policy/label or Litigation Hold) to the mailbox, confirm the hold is applied, then delete the user account so the mailbox becomes an inactive mailbox, preserved with no license required.
Microsoft Learn on inactive mailboxes states that if a hold is applied before the account is deleted, the mailbox is converted into an inactive mailbox and its contents are retained for the duration of the hold with no license consumed. Authorized people with eDiscovery permissions can then search and export it.
Why the other options are wrong:
- A. Wrong: a PST export is a point-in-time copy that isn't tamper-proof or centrally searchable; Microsoft's supported preservation method for litigation is the inactive mailbox.
- B. Wrong: a shared mailbox keeps the mailbox active for shared access; it isn't the mechanism to immutably preserve a departed user's data for litigation, and shared mailboxes over 50 GB or with a hold/archive still need a license. The supported preservation path is an inactive mailbox.
- C. Wrong: deleting the account without a hold only soft-deletes the mailbox for 30 days; after 30 days the data is permanently removed. There is no automatic long-term retention.
Memory hook: Hold FIRST, then delete the account = inactive mailbox (no license, preserved for the hold's duration).
Microsoft Learn: Inactive mailboxes in Office 365
