SC-200日本語 無料問題集「Microsoft Security Operations Analyst (SC-200日本語版)」
経営陣の問題を調査するには、高度なハンティングクエリを作成する必要があります。
質問にはどのように回答すればよいですか？回答するには、回答欄で適切なオプションを選択してください。
注：正解ごとに1ポイントが加算されます。
質問にはどのように回答すればよいですか？回答するには、回答欄で適切なオプションを選択してください。
注：正解ごとに1ポイントが加算されます。
正解：
Explanation:
Table: DeviceFileEvents
Aggregation function: count()
In Microsoft Defender XDR advanced hunting, data tables such as DeviceFileEvents , DeviceProcessEvents
, and CloudAppEvents are used to investigate various types of activities. Since this query aims to investigate an issue related to file activity-specifically identifying when files have been accessed, modified, or created repeatedly-the correct data source table is DeviceFileEvents . This table contains information about file- level activities recorded by Defender for Endpoint sensors, including file path, file name, action type, and user account involved.
The KQL structure shown in the image follows standard hunting query syntax:
DeviceFileEvents
| where Timestamp > ago(2d)
| summarize activityCount = count() by FolderPath, FileName, ActionType, AccountDisplayName
| where activityCount > 5
Here's why:
* The where Timestamp > ago(2d) clause filters results from the last 2 days, a typical timeframe for immediate investigations.
* The summarize operator groups events by FolderPath, FileName, ActionType, and AccountDisplayName, then uses count() to determine how many times each file was acted upon.
* Finally, where activityCount > 5 filters to show only unusually high-frequency activity, which might indicate suspicious or automated file manipulation.
Microsoft Defender XDR documentation highlights that DeviceFileEvents is the correct schema for file activity investigations, while DeviceProcessEvents focuses on process creation and execution, and CloudAppEvents targets cloud application usage.
Thus, the verified and documented correct completions are:
Table: DeviceFileEvents
Aggregation function: count()
Workspacel という名前の Microsoft Sentinel ワークスペースがあり、その中に CommonSecurityLog という名前のテーブルがあります。CommonSecurityLog にはログを取り込みます。CommonSecurityLog のログ取り込み時間は平均 5 分です。
7分間の遡及期間を持ち、CommonSecurityLogテーブルのデータを使用する分析ルールを作成する必要があります。ソリューションは以下の要件を満たす必要があります。
同じイベントが二度処理されるのを防ぎます。
ログ取り込みの遅延によるイベントの見逃しを最小限に抑える。
ルールを定義するKQLクエリをどのように完成させるべきですか？回答するには、回答欄で適切なオプションを選択してください。
注：正解ごとに1ポイントが加算されます。
7分間の遡及期間を持ち、CommonSecurityLogテーブルのデータを使用する分析ルールを作成する必要があります。ソリューションは以下の要件を満たす必要があります。
同じイベントが二度処理されるのを防ぎます。
ログ取り込みの遅延によるイベントの見逃しを最小限に抑える。
ルールを定義するKQLクエリをどのように完成させるべきですか？回答するには、回答欄で適切なオプションを選択してください。
注：正解ごとに1ポイントが加算されます。
正解：
Explanation:
When creating scheduled analytics rules in Microsoft Sentinel, you should account for ingestion delay so late-arriving events aren't missed, while also avoiding reprocessing the same events. The recommended pattern is to widen the TimeGenerated window by the expected delay and then gate results by ingestion_time() to include only data that actually arrived within the delay window:
let ingestion_delay = 5min;
let rule_look_back = 7min;
CommonSecurityLog
| where TimeGenerated > = ago(ingestion_delay + rule_look_back) // cover late arrivals
| where ingestion_time() > ago(ingestion_delay) // only newly ingested data
* TimeGenerated > = ago(ingestion_delay + rule_look_back) ensures the query looks back 7 + 5 = 12 minutes , so events that were generated up to 7 minutes ago but arrived up to 5 minutes late are still captured.
* ingestion_time() > ago(ingestion_delay) limits results to items ingested in the last 5 minutes , preventing the same already-processed events from being picked up again on the next run, while minimizing misses due to late ingestion.
Thus, choose (ingestion_delay + rule_look_back) for the first blank and (ingestion_delay) for the second.
Microsoft Sentinelワークスペースをお持ちです。
Microsoft Sentinelインシデントは、以下の図に示すように生成されます。
ドロップダウンメニューを使用して、[図]に示されている情報に基づいて各文を完成させる回答を選択してください。
注：正解ごとに1ポイントが加算されます。
Microsoft Sentinelインシデントは、以下の図に示すように生成されます。
ドロップダウンメニューを使用して、[図]に示されている情報に基づいて各文を完成させる回答を選択してください。
注：正解ごとに1ポイントが加算されます。
正解：
Azure Sentinelの要件を満たすには、イベントにメモを追加する必要があります。
どの3つの行動を順番に実行すべきでしょうか？回答するには、行動リストから適切な行動を回答欄に移動させ、正しい順序に並べ替えてください。
どの3つの行動を順番に実行すべきでしょうか？回答するには、行動リストから適切な行動を回答欄に移動させ、正しい順序に並べ替えてください。
正解：
Explanation:
To attach notes that you can later see during investigations and hunting, you use Bookmarks in Microsoft Sentinel. Bookmarks are created from the Hunting (or Logs) experience inside the Sentinel workspace and let you pin a specific query result (including IPs, accounts, hosts) with notes, tags, and mapped entities so it appears in the investigation graph and is easily referenceable. The correct workflow is: first, run your KQL query from the Microsoft Sentinel workspace (not from generic Azure Monitor), because Sentinel's hunting experience is where bookmarks integrate with incidents and the investigation graph. Next, select a specific query result that represents the suspicious activity (e.g., a data access event from the target IP). Finally, create a Bookmark and map the relevant entity (IP address, Account, etc.) while adding your notes . Mapping the entity ensures the bookmarked event is connected in the investigation graph; the notes provide the narrative
/context you need when pivoting later. Adding the query to favorites is optional for convenience but does not attach notes to a specific event, and running the query from Azure Monitor would not place the bookmark within Sentinel's investigation context.
お客様は、Microsoft Purview を使用する Microsoft 365 サブスクリプションを所有しており、その中に Site1 という名前の Microsoft SharePoint Online サイトが含まれています。Site1 には、次の表に示すファイルが含まれています。
Microsoft Purview から、次の表に示すコンテンツ検索クエリを作成します。
以下の各記述について、正しい場合は「はい」を選択してください。そうでない場合は「いいえ」を選択してください。
注：正解ごとに1ポイントが加算されます。
Microsoft Purview から、次の表に示すコンテンツ検索クエリを作成します。
以下の各記述について、正しい場合は「はい」を選択してください。そうでない場合は「いいえ」を選択してください。
注：正解ごとに1ポイントが加算されます。
正解：
Explanation:
This question refers to Microsoft Purview Content Search queries, which use KQL (Keyword Query Language) for searching files and metadata in SharePoint, Exchange, and other M365 repositories.
* Search1: Author: " User1 " FileExtension:xlsx
* This query searches for items authored by User1 and with file extension .xlsx .
* In the dataset, only File3.xlsx has the .xlsx extension, but its Author is User3 , not User1.
* Therefore, Search1 will not return File3 # answer: No . (Correction after logical review)
* Search2: Author: " User* " and FileExtension:*
* The wildcard User* matches any author name starting with "User" (User1, User2, User3).
* FileExtension:* matches any file type that has an extension.
* Therefore, all three files (File1.docx, File2.docx, File3.xlsx) match this query.
* Hence, Search2 will return File1 # answer: Yes .
* Search3: Author:(User1..3)
* The range (User1..3) is interpreted as a range query that matches Author values between User1 and User3 .
* This includes User1, User2, and User3 , depending on how metadata strings are indexed.
* Therefore, File2 (authored by User2) is included in this range.
* Hence, Search3 will return File2 # answer: Yes .
# Final Correct Table
Statement
Yes
No
Search1 will return File3
# #
Search2 will return File1
# #
Search3 will return File2
# #
Summary:
* Search1: No (author and extension don't match).
* Search2: Yes (wildcard matches all "User" authors).
* Search3: Yes (range includes User2).
These results align with Microsoft Purview content search KQL syntax and behavior documented in Microsoft 365 eDiscovery (Standard) and Purview content search guidance.