The Microsoft Security Operations Analyst (SC-200)

Dropdown/Step

Value to Select

where ResponseStatusCode in (...)

( " 204 " )

split([dropdown], " / " )[-3]

RequestUri

To detect Microsoft Graph operations that change role membership , you target POST requests to the directoryRoles … /members/$ref endpoint. Adding a member to a role via Microsoft Graph is performed with POST /directoryRoles/{role-id}/members/$ref and, on success, Graph returns HTTP 204 No Content . Therefore, filtering ResponseStatusCode to 204 isolates successful role-assignment events while excluding errors like 401/403 and non-mutating redirects such as 302.

The RequestUri contains the role identifier in the path. For URIs like:

https://graph.microsoft.com/v1.0/directoryRoles/{role-id}/members/$ref

splitting on “/” yields: [https:, , graph.microsoft.com, v1.0, directoryRoles, {role-id}, members, $ref] . The element at index -3 is the {role-id} . Hence, extend Role = tostring(split(RequestUri, " / " )[-3]) correctly extracts the role GUID for reporting.

Putting it together, a concise query is:

MicrosoftGraphActivityLogs

| where RequestUri has_all ( " https://graph.microsoft.com/ " , " /directoryRoles " , " members/$ref " )

| where RequestMethod == " POST "

| where ResponseStatusCode in ( " 204 " )

| extend Role = tostring(split(RequestUri, " / " )[-3])

| project TimeGenerated, IPAddress, ResponseStatusCode, Role

This returns the timestamp, source IP, success code, and the affected role ID for each successful role-membership addition in your tenant.

Step 1: From the Investigation blade, select Insights

The Investigation Insights Workbook is designed to assist in investigations of Azure Sentinel Incidents or individual IP/Account/Host/URL entities.

Step 2: From the Investigation blade, select the entity that represents VM1.

The Investigation Insights workbook is broken up into 2 main sections, Incident Insights and Entity Insights.

Incident Insights

The Incident Insights gives the analyst a view of ongoing Sentinel Incidents and allows for quick access to their associated metadata including alerts and entity information.

Entity Insights

The Entity Insights allows the analyst to take entity data either from an incident or through manual entry and explore related information about that entity. This workbook presently provides view of the following entity types:

IP Address

Account

Host

URL

Step 3: From the details pane of the incident, select Investigate.

Choose a single incident and click View full details or Investigate.

In Microsoft Sentinel , Microsoft incident creation rules are used to automatically create incidents from alerts generated by connected Microsoft security products (like Microsoft Defender XDR, Defender for Endpoint, or Defender for Cloud Apps). However, these rules do not detect malicious IP activity on their own. They simply define how and when alerts from Microsoft security connectors should be grouped or converted into incidents.

To meet the goal — “create an incident when a sign-in to an Azure virtual machine from a malicious IP address is detected” — you must use an analytics rule (scheduled query) or a Fusion rule that actively correlates sign-in logs with threat intelligence data (malicious IPs). Analytics rules in Sentinel run KQL queries that can match sign-in activity (from Azure Activity or SigninLogs) with known malicious IP lists, and they can automatically generate incidents when matches occur.

Therefore, creating a Microsoft incident creation rule for a data connector does not meet the requirement, since it cannot detect or correlate malicious sign-in activity itself.

Hence, the correct answer is B. No .

Labeling activities are available in Activity explorer.

For example:

Sensitivity label applied

This event is generated each time an unlabeled document is labeled or an email is sent with a sensitivity label.

It is captured at the time of save in Office native applications and web applications.

It is captured at the time of occurrence in Azure Information protection add-ins.

Upgrade and downgrade labels actions can also be monitored via the Label event type field and filter.

To release quarantined items on a Windows device protected by Microsoft Defender for Endpoint/Antivirus , you use the Microsoft Defender command-line utility MpCmdRun.exe . This tool supports maintenance actions including scanning, definition management, and quarantine operations. For quarantine specifically, the supported switch is -Restore , which restores items from quarantine. The typical syntax for restoring all items for a specific threat name is:

MpCmdRun.exe -Restore -Name " < ThreatName > " -All

Here, the -Name parameter specifies the detected threat family or name (for custom indicators it reflects the custom threat label, e.g., EUS:Win32/CustomEnterpriseBlock ), and -All applies the restore operation to all items associated with that name—ideal when multiple files (e.g., 20) were quarantined by the same indicator.

Other options are not appropriate for this task:

-GetFiles collects diagnostic logs for support.

-RemoveDefinitions and -ResetPlatform handle antimalware engine/definitions, not quarantine.

MsMpEng.exe is the Defender service binary (not invoked directly), and Start-MpRollback is a separate PowerShell cmdlet for rolling back remediations, not for restoring quarantined files by name.

Therefore, to release the 20 files: MpCmdRun.exe -Restore -Name " EUS:Win32/CustomEnterpriseBlock " -All .

Export logs to: ✅ Azure event hub

Configure streaming by: ✅ Configuring continuous export in Defender for Cloud for each subscription

In Microsoft Defender for Cloud , if you need to stream security alerts and recommendations to an external SIEM or syslog server , the supported approach is to export data to an Azure Event Hub , which acts as a streaming pipeline. The syslog server or SIEM solution can then pull data from the Event Hub in real time using connectors or custom listeners.

The configuration method for sending Defender for Cloud data to an Event Hub is known as continuous export . According to Microsoft’s official Defender for Cloud documentation, continuous export lets you automatically stream alerts and security recommendations to Event Hubs or Log Analytics workspaces . However, when your target is a syslog server , Event Hub is required because it supports continuous streaming outside Azure.

To minimize administrative effort across multiple subscriptions (100 in this case) , you can use Azure Policy or a script to apply continuous export settings per subscription , but the feature must still be enabled individually for each subscription — hence the correct configuration step is:

“Configuring continuous export in Defender for Cloud for each subscription.”

Why not other options:

Log Analytics workspace: used for querying within Azure, not for streaming to external syslog servers.

Azure Storage account: suitable for archival, not streaming.

Modifying diagnostic settings of the tenant: applies only to Azure AD logs, not Defender for Cloud data.

In Microsoft 365 Defender advanced hunting, email attachments are recorded in EmailAttachmentInfo and endpoint file activity is recorded in DeviceFileEvents . To correlate a malicious attachment to devices where the same file was observed, you join on the file hash ( SHA256 ). The hunting guidance specifies using EmailAttachmentInfo to filter by sender and to ensure the attachment has a hash ( isnotempty(SHA256) ). Then, a join with DeviceFileEvents on SHA256 links the email-borne file to endpoint observations.

Before joining, it’s best practice to reduce the right-hand dataset with project to only needed fields (e.g., FileName , SHA256 , DeviceName , DeviceId , Timestamp ) to improve performance and limit data volume. After the join, use project again to shape the final result set for investigation, including timeline and pivot identifiers: Timestamp , FileName , SHA256 , DeviceName , DeviceId , plus email context such as NetworkMessageId , SenderFromAddress , and RecipientEmailAddress .

Therefore, the correct operator sequence is: join (subquery over DeviceFileEvents with project ) on SHA256 , then final project of the incident-relevant columns.

In Microsoft Defender for Cloud, regulatory compliance standards such as PCI DSS 4.0 , ISO 27001 , and NIST SP 800-53 are part of the Cloud Security Posture Management (CSPM) capabilities. To assign or view these regulatory initiatives, the CSPM plan must first be enabled for the environment.

According to Microsoft Defender for Cloud documentation, when you open Environment settings → Security policy , you can view and manage the assigned initiatives. If the option to “Add more industry and regulatory standards” is grayed out or unavailable , it means that the CSPM plan is not active for that subscription.

Once you enable the Defender CSPM plan , Defender for Cloud automatically assigns the Microsoft Cloud Security Benchmark (MCSB) initiative and allows you to add additional frameworks such as PCI DSS 4.0, NIST, or SOC 2.

Option A (Correct) — Enabling CSPM unlocks regulatory compliance capabilities, allowing you to assign the PCI DSS 4.0 initiative.

Option B — Disabling MCSB is unnecessary and not required; it’s automatically included when CSPM is enabled.

Options C and D — Continuous export settings (to Event Hubs or Log Analytics) are used for exporting data, not enabling compliance initiatives.

Hence, the first step to make the “Add more standards” option available is to enable the Cloud Security Posture Management (CSPM) plan on the subscription.

Box 1: join

An inner join.

This query uses kind=inner to specify an inner-join, which prevents deduplication of left side values for DeviceId.

This query uses the DeviceInfo table to check if a potentially compromised user ( < account-name > ) has logged on to any devices and then lists the alerts that have been triggered on those devices.

DeviceInfo

//Query for devices that the potentially compromised account has logged onto

| where LoggedOnUsers contains ' < account-name > '

| distinct DeviceId

//Crosscheck devices against alert records in AlertEvidence and AlertInfo tables

| join kind=inner AlertEvidence on DeviceId

| project AlertId

//List all alerts on devices that user has logged on to

| join AlertInfo on AlertId

| project AlertId, Timestamp, Title, Severity, Category

DeviceInfo LoggedOnUsers AlertEvidence " project AlertID "

Box 2: project