Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 451–525

The user entity is the core anchor for UEBA in Microsoft Sentinel, enabling the engine to build a behavioral baseline and detect anomalies like unusual logon times, failed logins, or peers' rare access to sensitive resources. Insider threat hunting depends on correlating identity, access, and action attributes around a unique user, which is why user entity analysis correctly identifies abnormal access patterns. Without user-level behavioral analytics, insider threats that leverage legitimate credentials would remain undetected.

Microsoft Defender for Endpoint Live Response is the correct tool because it provides a secure, remote shell session to an endpoint that is onboarded to Microsoft Defender for Endpoint. Analysts can use Live Response commands like 'collect' to retrieve specific files, run forensic scripts, and inspect system artifacts in real time. It also supports a managed library of commands and can be restricted through RBAC roles, making it purpose-built for incident response file collection.

Guest Configuration is an Azure Policy extension that can audit and deploy configurations inside Azure VMs, including Arc-enabled servers, using PowerShell Desired State Configuration (DSC). It enforces baselines by remediating settings such as password policy, Windows Defender Firewall rules, and TLS versions through DeployIfNotExists and Modify effects. This aligns with the goal of automating security baseline enforcement. Therefore, it is the correct choice.

This is the correct condition set because automation rules in Microsoft Sentinel trigger on incidents, and they can evaluate incident-level properties such as Incident severity and Entity type. The 'Entity type contains User' condition checks the first-class entities associated with the incident, ensuring the rule only runs on high-severity incidents that actually include a user entity, which is precisely what the requirement asks for.

AzureHound enumerates Microsoft Entra ID objects, users, groups and role assignments via the Graph API, so Microsoft Entra ID Audit Logs capture the directory read and consent activity that reveals enumeration. These logs expose the reconnaissance patterns AzureHound generates.

Investigating the alert by reviewing related entities (e.g., user, IP, host) and the underlying logs is the correct first step because it determines whether the detected activity is a true positive. Sentinel's incident investigation canvas allows you to track entity relationships, pivot to related events, and query KQL to confirm the alert's validity before any containment or remediation action is taken.

Microsoft Defender for Endpoint is a cloud-based endpoint detection and response (EDR) solution that provides risk-based vulnerability management, antivirus, attack surface reduction, and automated investigation and remediation on devices. It natively shares signals with other Defender products in the Defender XDR portal, allowing correlated incidents across endpoints, identities, and email. This makes it a fitting component of the XDR suite because it contributes telemetry from the physical and virtual endpoints across your organization.

Playbooks in Microsoft Sentinel are built on Azure Logic Apps, which provide a visual designer to automate incident response actions such as blocking IPs, resetting passwords, or opening tickets. Logic Apps connectors integrate with many services, allowing you to orchestrate a wide range of response workflows. Therefore, Azure Logic Apps is the correct choice for creating an automated response in Sentinel.

Matching EventID 4769 with TicketOptions "0x40810000" and TicketEncryptionType "0x17" isolates RC4-encrypted, forwardable, renewable service ticket requests typical of golden ticket activity, then summarising count() by AccountName and taking the top 10 surfaces the most prolific requesters.

A full antivirus scan is a remediation action in Microsoft Defender for Endpoint, detecting and removing residual malware artefacts across the device after an infection. It satisfies the scenario by cleaning persistent threats that remain following initial detection and investigation.

In Microsoft Defender for Office 365, the 'Block sender' action directly adds the sender's email address to the tenant-level block list used by Exchange Online Protection, causing future messages from that address to be rejected during mail flow. This is the appropriate remediation when an email-based threat needs to be stopped at the messaging layer, and it can be executed from the email entity or threat explorer. It is therefore the correct action to block the sender across Exchange Online.

In Sentinel UEBA, this alert likely combines an impossible-travel event (source IP geolocation far from the user's normal base) with a mass-download anomaly such as copying hundreds of sensitive files from SharePoint Online or OneDrive within minutes. Because the location shift coincides with a sudden spike in data access that does not match the user's established behavioral baseline, the most probable scenario is an attacker using stolen credentials. UEBA also assigns a high risk score when the anomalous activity targets sensitive data categories, and the combination of geographic and volumetric deviations strongly indicates account compromise rather than benign behavior.

Microsoft Entra ID sign-in logs record authentication events, including the originating IP, device and conditional access outcome. They satisfy the lateral movement requirement by exposing credential reuse or anomalous sign-ins from compromised accounts moving between Azure resources.

In Microsoft Sentinel, all ingested telemetry resides in a designated Log Analytics workspace, and the workspace's retention settings determine how many days of raw logs are available for queries, analytics, and threat hunting. Adjusting table-level or workspace-level retention directly controls the lifespan of that data, including whether it moves to long-term retention or archive. Because Sentinel does not maintain a separate storage pool, the Log Analytics retention configuration is the authoritative mechanism for data retention.

This option correctly describes the query's purpose: it starts with medium-risk user sign-ins, joins those with service principal sign-ins on the same IP address, and uses a count threshold to identify repeated correlation. Such a pattern can reveal token theft or lateral movement where an attacker uses a stolen user token from an IP also associated with a service principal. The combination of the risk level on the user sign-in and the shared IP with a service principal is the key investigative signal.

Just-In-Time (JIT) VM Access correctly describes time-limited opening of management ports (e.g., RDP/SSH) through NSG rules, while Adaptive Application Controls correctly describes an allowlist-based mechanism that uses machine learning to permit only known safe executables. File Integrity Monitoring (FIM) correctly targets changes to sensitive registry keys and files, and the Regulatory Compliance Dashboard correctly assesses Azure resources against industry standards such as CIS and PCI DSS. This alignment accurately captures each feature's core operational purpose without conflating network access, application control, integrity verification, or compliance assessment.

The Entity behavior blade is the correct feature because when you open a specific entity (user, device, or domain) in the Defender portal, the Entity behavior tab automatically renders a timeline of that entity's activities, associated alerts, and incident history. This direct entity-focused view lets an analyst immediately see whether that user was implicated in past incidents without writing any queries or building custom workbooks. Correct.

DeviceProcessEvents records process creation events and exposes the SHA256 column, letting the hunter filter executions by the exact file hash observed. This satisfies the 24-hour scope via Timestamp filtering, returning every device that ran that specific binary regardless of filename or path.

Microsoft Sentinel's UEBA engine leverages machine learning to establish a baseline of typical behavior for each user and their peer group. When a user's activities—such as access patterns, resource usage, or data exfiltration attempts—diverge significantly from that baseline, Sentinel surfaces an anomaly. This peer-to-peer comparison is a core UEBA capability that helps identify insider threats and compromised accounts, and it is distinct from simple rule-based alerting.

A SharePoint app connector enables Defender for Cloud Apps to proxy sessions, and a session policy scoped to jdoe, the ExecConfidential site and the Unmanaged device tag applies Block download in real time, satisfying the requirement to prevent sensitive file downloads from unmanaged devices.

Using an incident manager with a cross-workspace view is the correct approach because Microsoft Sentinel can aggregate incidents from multiple workspaces through Azure Lighthouse delegation. A central SOC workspace can then query and manage incidents across all listed workspaces from a single pane of glass, while each workspace retains its data residency and collection boundaries. This directly centralizes the incident lifecycle—triage, assignment, and closure—without duplicating configuration or merging data stores.

The device timeline, also known as the process timeline, is the correct answer because it provides a chronological view of events and a visual representation of the process tree, including parent-child relationships. This allows an analyst to trace an attack chain from initial access to execution, observing how each process was spawned and what actions it performed. It is a core DFIR tool in Microsoft Defender for Endpoint for investigating a single device's historical activity.

Analytics rules are the core detection mechanism in Microsoft Sentinel; without them, ingested logs remain dormant and never generate alerts or incidents. These rules use Kusto Query Language (KQL) to define detection logic, set alert thresholds, and trigger automated responses when suspicious activity matches. Enabling the AWS S3 and GCP Pub/Sub connectors supplies raw log data, but only analytics rules transform that data into actionable security incidents by performing correlation and pattern matching across the multicloud logs.

Content hub hunting queries map to MITRE ATT&CK tactics and techniques, giving you pre-built KQL aligned to the framework's structure. This satisfies the scenario's requirement to conduct hunting within ATT&CK, letting you pivot from known technique coverage rather than authoring detections from scratch.

This connector is a valid choice because it ingests unified audit logs from Microsoft 365, along with alerts and incidents from the Microsoft 365 Defender suite. It allows you to collect audit records related to user actions such as mailbox access, file shares, and Teams messages, which are critical for security investigations. By integrating with Microsoft 365 Defender, the connector provides a streamlined way to bring these logs into your SIEM, making it one of the two correct answers.

This query is correct because it uses the CloudAppEvents table, the authoritative table in Microsoft 365 Defender advanced hunting for cloud app activities, and filters on ActionType == 'FileDownloaded', which is the exact event name for file downloads in SharePoint Online. The AccountDisplayName filter isolates the target user's actions within the last 7 days, and summarize TotalSize = sum(FileSize) correctly aggregates the FileSize numeric column to yield the total bytes downloaded. It is the only option that combines the right table, accurate action type, and proper aggregation.

The managed identity must be assigned the Sentinel Reader RBAC role on the target Log Analytics workspace (or its resource group). Without this role, the Microsoft Sentinel connector in the Logic App returns an authorization error when attempting to read incidents or execute a query, even though the Logic App trigger ran successfully. Permissions are not automatically granted to the managed identity's service principal; they must be explicitly assigned via Azure RBAC.

Configuring an automation rule with trigger 'When incident is created' and conditions for severity equals High and 'Assigned to' is empty ensures the playbook runs only for newly created High-severity incidents that are unassigned. This pre-filtering eliminates unnecessary playbook executions and allows the playbook to focus solely on the response actions, such as assigning an owner or initiating an investigation. Because the trigger fires on incident creation, the conditions are evaluated at the moment the incident is generated, which is the correct pattern for this scenario.

Suspending the user account in Microsoft Entra ID immediately disables the account, preventing the user from authenticating and blocking issuance of new access tokens across all Entra ID-integrated cloud applications, including Exchange Online, SharePoint, and Teams. This is the most direct and comprehensive identity-centric containment action because it removes the attacker's ability to log in regardless of endpoint, IP, or session state. It also stops password-based and token-based access at the source, making it the preferred first step in responding to a compromised identity.

Azure Security Benchmark is a comprehensive policy initiative (policy set definition) that bundles multiple built-in policy definitions representing security best practices and compliance controls across services, including SQL servers. Specifically, it includes policies such as 'Advanced Data Security on SQL servers should be enabled' and 'Vulnerability assessment on SQL servers should be enabled', which together establish a baseline for SQL security. Assigning this initiative to the Azure subscription allows Microsoft Defender for Cloud to evaluate, audit, and automatically deploy the required SQL security settings, making it the correct choice for meeting the stated requirement.

The Investigation graph is the correct tool for incident investigation because it presents an interactive, visual map of entities (such as hosts, IPs, and accounts) and their connections to alerts and activities. It allows analysts to expand nodes to explore related entities, assess blast radius, and pivot directly into other data sources, making it purpose-built for correlating and understanding a specific incident's scope.

This approach correctly models the lateral movement sequence: the mstsc.exe process on the initiating host contains the target device's name or IP in its command line (e.g., mstsc /v:10.0.0.5), so extracting that value and self-joining DeviceProcessEvents back to the target device lets you pivot from the RDP client to the PowerShell process that ran after connection. Adding a time window of less than 10 minutes between the mstsc.exe event on the source and the PowerShell event on the target filters out unrelated script activity, producing a precise correlation that reflects the attack chain. Because both legs are process events from DeviceProcessEvents, the join uses consistent schema (DeviceName, Timestamp, CommandLine) and allows direct association regardless of network port or logon type.

This automation rule is triggered when a new incident is created and its condition matches alert titles containing the word 'Malware.' The rule's action invokes a playbook—an Azure Logic Apps workflow—that is designed to isolate the affected device, typically through a Microsoft Defender for Endpoint connector. This correctly describes the two core parts of the rule: the condition (incident created + alert title contains 'Malware') and the action (run a playbook to isolate a device).

Disabling accounts stops further misuse.

The correct recommendation prompts an analyst to deploy a supported endpoint protection solution, such as Microsoft Defender Antivirus or another integrated partner product, onto the VM. Defender for Cloud evaluates the VM's installed security agents and health state; if no solution is reported via the MMA/AMA or Microsoft Defender for Endpoint integration, it assigns the recommendation as 'unhealthy.' It can also detect a supported agent that is disabled, out-of-date, or reporting errors, and then direct the analyst to fix or provision the agent.

SigninLogs in Microsoft Entra ID records both successful and failed user sign-in attempts, including the user principal name, source IP, application, and failure reason. This is the authoritative identity-plane log for detecting brute-force behavior, because you can aggregate sign-in failures per account or IP and compare the count against a threshold, optionally looking for a subsequent success. For a scheduled analytics rule that detects brute-force attacks on cloud identities, SigninLogs is the correct data source.

Before troubleshooting Sentinel, verify that Microsoft Defender for Endpoint alerts are actually being produced and sent to Microsoft 365 Defender by reviewing the Microsoft 365 Defender portal. If no MDE alerts are visible there, they cannot propagate downstream to Sentinel, regardless of connector configuration. This is the root-cause check because the Microsoft 365 Defender connector only ingests what Microsoft 365 Defender itself has received and correlated; an empty source yields empty Sentinel tables.

Revoking all current sessions immediately invalidates the access tokens, refresh tokens, and session cookies that have already been issued to the user, terminating any active attacker foothold in real time. This is a containment-first action because it stops ongoing malicious activity without waiting for password changes or conditional access checks. However, it only disrupts existing authentications; it does not prevent future sign-ins, so it must be paired with disabling the account to block new authentication attempts.

The Incidents blade in Microsoft Sentinel is the dedicated operational workspace for security analysts to triage, investigate, and manage security incidents. It aggregates related alerts into a single incident, provides filtering by status, severity, and product, and supports actions like assignment and closing. This is the correct place to review existing incidents as it centralizes all detection results requiring attention.

DeviceNetworkEvents supplies the outbound connection telemetry — remote IP, port, and URL — that mshta.exe generated when fetching the remote script. This directly confirms the LotL attack by correlating the process execution already surfaced in the hunting query with the actual command-and-control or payload download destination, satisfying the requirement to verify external network contact.

Service accounts often have elevated privileges and allow remote connections (e.g., SMB, WinRM, RDP) to multiple systems for legitimate application workloads. When an attacker compromises a service account, correlating its historical baseline with anomalous outbound network connections—such as connections to previously unseen hosts or non-standard protocols—can reveal lateral movement attempts that would otherwise blend in with normal service traffic.

Querying EmailEvents in Microsoft Sentinel's advanced hunting tables returns the specific email, recipient, delivery action and verdict, tying the phishing message to the affected user. This satisfies the stem's triage requirement by scoping the incident to concrete evidence before remediation.

Automation rules are the native Sentinel mechanism that runs on incident creation or alert creation and can perform actions like assigning ownership, changing status, or invoking a playbook (Logic App) via a trigger. When an automation rule is configured to run a playbook, it uses the alert trigger or incident trigger in the Logic App, passing the alert payload. This is the direct answer to the question because automation rules bridge detection to response. They are the correct trigger mechanism.

Azure Functions can be deployed to create a custom ingestion pipeline for AWS CloudTrail logs. This involves configuring an Azure Function to retrieve logs from the designated AWS S3 bucket where CloudTrail stores its data. The function then processes these logs and forwards them to the Microsoft Sentinel Log Analytics workspace, effectively satisfying the requirement to ingest AWS CloudTrail logs. This method offers flexibility for custom transformations or filtering before ingestion.

Adaptive network hardening continuously analyzes actual traffic flows to and from Azure resources, learning the legitimate patterns of communication. It then compares these learned flows against the current NSG rules and recommends—or can automatically apply—tightened rules that block traffic that does not match the baseline. When a deviation from the learned pattern is observed, such as an unexpected source IP or port combination, it raises an alert, making it the appropriate control for detecting anomalous network behavior.

DeviceFileEvents records file creation, modification and renaming activity from Defender for Endpoint, capturing the rapid, high-volume write and rename operations ransomware performs during encryption. This directly satisfies the stem's requirement to detect file encryption events, unlike tables covering process, network or registry activity.

The Investigation graph maps the incident's entities—accounts, hosts, IPs—and their linked events, letting the analyst pivot across the failed-then-successful logon sequence and unusual location in one view, satisfying the need to rapidly gather context before deciding whether the activity is malicious.

Enable automatic attack disruption in the Microsoft Defender XDR settings. This native capability automatically contains compromised identities by disabling user accounts or isolating devices when an active attack is detected, without manual intervention. It uses cross-domain signals to break the attack chain immediately, aligning exactly with the requirement to automatically respond in real time.

This option accurately reflects the ARM template's trigger and action configuration. On incident creation, when 'Severity' equals 'High', the rule executes an update action changing severity to 'Medium' and an assignment action setting the owner to the 'SOC-Tier2' group. Both actions run in sequence as part of that single rule instance, and no other conditions modify this behavior.

The query targets the active threats collection, which only holds unresolved detections. Once remediation completes, the threat moves out of that list, so querying by that ID returns nothing even though the historical record may still exist elsewhere.

Microsoft Entra ID is a correct connector because it ingests sign-in logs (including interactive and non-interactive sign-ins) and audit logs from Azure AD into Microsoft Sentinel. This data is essential for identity-based threat detection and investigation, allowing analysts to trace authentication attempts and directory changes.

A scheduled playbook uses a recurrence trigger to query Microsoft Sentinel for incidents older than 90 days with status New, then closes them automatically. This satisfies the bulk-closure requirement without manual triage, unlike automation rules, which trigger on incident creation rather than elapsed age.

This option is correct because the query explicitly examines command-line arguments for the '-EncodedCommand' parameter, which is a well-known PowerShell feature that attackers abuse to obfuscate malicious scripts. When an encoded command is present, the actual script is a Base64-encoded string, making static detection more difficult and justifying a suspicion review. Security analysts use such queries in advanced hunting to surface potentially hidden or obfuscated PowerShell activity.

In Microsoft Defender for Cloud, the Recommendations blade aggregates all security assessments, including the built-in recommendation 'System updates should be installed on your machines' (assessment key 4ab39e73-6c9d-4c5e-a9e7-5f2f2b3b3b3b). This assessment evaluates each virtual machine for missing critical or security updates and lists the affected resources with their patch status directly in the recommendation's 'Affected resources' tab. Therefore, this is the correct place to view all VMs missing critical updates.

Collecting investigation packages from affected devices is appropriate because it captures volatile forensic artifacts—such as running processes, active network connections, registry keys, and loaded drivers—in their current live state. This package enables analysts to identify Indicators of Compromise (IOCs), the initial access vector, and the full lateral movement scope without altering or destroying evidence. It is a non-disruptive collection action that complements containment, ensuring the investigation has the data needed to understand the outbreak before any cleanup begins.

Adding filters that exclude known benign activity narrows the result set, directly reducing the false positives the hunt query returns. This refines the analytic without disabling it, satisfying the requirement to tune detection logic so genuine threats remain visible while routine noise is suppressed.

DeviceNetworkEvents is the workflow's core because it reveals each process's outbound and inbound network connections, including remote IP, remote port, protocol, and the initiating process image. Lateral movement requires a connection to another host via protocols like SMB (445), RDP (3389), or WinRM (5985), so hunting can simply look for unusual or repetitive connection patterns from a compromised host to internal addresses. This table also lets you join to process creation events, making it indispensable for reconstructing the full attack chain between systems.

Microsoft Sentinel Repositories (CI/CD) enables you to manage analytics rules as code in Azure DevOps or GitHub, with content deployed via ARM templates or Bicep. This enforces a formal approval workflow through pull requests and branch policies before any rule reaches the workspace, ensuring only reviewed and approved rules are deployed. It also provides version control and rollback capabilities, making it the most robust governance approach for rule lifecycle management.

Modifying the rule's query to include additional filters, such as excluding known-safe IP addresses or requiring specific event attributes, directly increases precision by removing benign activity from the detection logic. This addresses the root cause of false positives because the KQL query is the decision engine that determines which raw events become alerts. Properly scoped filters reduce incident volume while preserving genuine threat detection.

Incident merging in Microsoft Sentinel combines multiple incidents that are part of the same attack campaign or share entities into a single incident. This directly reduces the number of incidents analysts must triage, lowering mean time to respond and preventing alert fatigue. By minimizing the chance that a critical alert is lost in a queue, it reduces the financial impact of a successful breach, thus lowering annualized loss expectancy.

File policies are purpose-built in Defender for Cloud Apps to monitor and govern files stored in connected cloud apps such as SharePoint, OneDrive, Box, and Google Drive. They evaluate conditions on file metadata, sharing permissions, file name, and content inspection, and can trigger alerts or automatic actions like quarantine or revoking access. This allows you to create a policy that specifically detects files shared with external users, thereby directly addressing the requirement to monitor file sharing.

The Microsoft Defender for Cloud data connector in Microsoft Sentinel is the native integration path for streaming cloud security alerts and recommendations. When you add this connector and select your subscriptions, Sentinel automatically ingests the data into the SecurityAlert and SecurityRecommendation tables using the correct schema and entity mapping. This creates a direct, managed pipeline that allows the SOC to triage and respond to Defender for Cloud findings as Sentinel incidents without any additional configuration.

The exhibit exposes riskLevel and riskState, which are populated by Microsoft Entra ID Protection when a user's risk score exceeds a threshold. These fields indicate that the identity has been flagged as at risk due to suspicious activity, such as atypical travel or leaked credentials. This is an automated risk assessment from Entra ID Protection, not a manual determination or a Sentinel analytics detection.

An analytics rule is the correct choice because Microsoft Sentinel uses analytics rules as its primary detection mechanism. A scheduled or Microsoft security analytics rule runs KQL queries on a recurring basis, evaluates results against thresholds or entity behavior, and can generate alerts and incidents for suspicious sign-in patterns or other anomalies, thereby satisfying the requirement to ensure detection and alerting.

This connector is the explicit, required data ingestion path between Microsoft Purview DLP and Microsoft Sentinel. It calls the Office 365 Management API to pull DLP alert records and writes them into the SecurityAlert table, which is what Sentinel analytics rules actually query. Without this connector enabled and configured, no DLP alert—regardless of policy mode or audit logging—will appear in Sentinel. Therefore, it is the only condition that directly determines whether DLP alerts are ingested.

Excluding known admin accounts helps reduce noise while keeping detection for other users.

A custom detection rule in Microsoft Defender XDR is the correct mechanism because it allows you to define a KQL-based query and, in the rule configuration, specify an incident assignment action. When the detection fires and generates an incident, that action automatically assigns the incident to a designated group (or in some cases an individual). This is the officially supported way to automate incident assignment in the Defender XDR incident queue, ensuring every generated incident has an owner from the outset.

Adding a condition to the rule query to filter out known legitimate user agents is the targeted fix because it directly removes the benign UserAgent strings from the anomaly-detection scope. In KQL, you can implement this with a `where UserAgent notin (~['LegitAgent1', 'LegitAgent2'])` clause or a regex pattern like `where UserAgent !matches regex @"(Chrome/120\.0|Edge/120\.0)"`, preserving the rule's ability to detect truly anomalous strings. This approach reduces false positives while maintaining full detection fidelity for other anomalous sign-in attributes such as geographic location, device compliance, or risk score, aligning with Sentinel best practices for rule tuning.

Enabling Defender for Servers activates the integrated vulnerability assessment capability (Microsoft Defender Vulnerability Management) and configuring auto-provisioning ensures the VA solution is automatically installed on all existing and future Azure VMs. This eliminates manual per-VM setup and provides continuous, centralized vulnerability findings in Defender for Cloud. It is the recommended, fully supported path for environment-wide coverage.

DeviceEvents is the correct table because it contains a wide range of Windows security events, including Event ID 4698 which is specifically the creation of a scheduled task. This table ingests events from the Windows Event Log and is the primary place to hunt for persistence mechanisms like new scheduled tasks. You can also find related events like task updates (4702) and deletions (4699) here. So for identifying suspicious scheduled task creation, DeviceEvents is the authoritative source.

Event 4732 is generated by the Windows security audit policy whenever a user or group is added to a security-enabled local group, such as the Administrators group. Defender for Cloud collects Windows Security Events through the Log Analytics agent or Azure Monitor Agent, allowing custom alerts or the built-in 'Security event log' Analytics rule to detect these membership changes. This is the correct data source because it directly captures the OS-level audit trail of local group modification.

Office 365 audit logs, specifically the Exchange workload, are the authoritative source because they capture changes to mailbox forwarding and inbox rules. Operations like Set-Mailbox, which includes modifications to ForwardingSmtpAddress, and New-InboxRule or Set-InboxRule with RedirectTo are logged with the actor's UPN, the exact timestamp, and the target mailbox. These events are accessible via the Microsoft Purview compliance portal or the Search-UnifiedAuditLog cmdlet, making them the definitive evidence for a data exfiltration via email investigation.

Microsoft Sentinel Reader is the correct role because it grants read-only access to all Sentinel resources, including incidents, workbooks, hunting queries, and analytics rule templates. This allows the junior analyst to view and investigate security data without any risk of accidental modification, aligning perfectly with the principle of least privilege.

Automation rules include a built-in 'Run playbook' action that invokes a Microsoft Sentinel playbook (an Azure Logic Apps workflow) automatically whenever the rule's trigger conditions are met, such as on incident creation or status change. This action allows security analysts to chain SOAR actions—like threat intelligence enrichment, quarantine, or email notification—directly from the incident workflow without manual intervention. The playbook must be registered with the incident trigger to appear in the automation rule.