Microsoft Security Operations Analyst SC-200 (SC-200) — Questions 151–225

Zero-hour auto purge (ZAP) is a Defender for Office 365 feature that retroactively identifies and acts on messages already delivered to a user's mailbox when they are later found to be phishing, malware, or spam. It automatically moves those messages to quarantine or the junk email folder, or deletes them, depending on the configured policy, effectively closing the gap when detection occurs post-delivery.

This is a standard, supported integration path for firewall appliances that emit Common Event Format (CEF) messages over syslog. The firewall sends CEF to a log collector/forwarder that has the Azure Monitor Agent installed; AMA forwards the events to a Log Analytics workspace using a data collection rule, populating the CommonSecurityLog table in Microsoft Sentinel. This method preserves normalized fields such as source/destination IP, port, and action, making it directly usable by analytics rules.

DeviceProcessEvents captures every process creation, along with the file name, command line, and parent process PID, enabling analysts to build a process tree from the initial point of execution. This table is the authoritative source for tracking the initial process — such as a malicious binary launched from an Office macro — because it records the moment the process became active. By querying DeviceProcessEvents, incident responders can trace the parent process chain and determine exactly which executable initiated the encryption.

Playbooks are cloud workflows built on Azure Logic Apps that you can invoke from Microsoft Sentinel to automate a security response. They can be triggered by an analytics rule (automatically on alert creation) or by an automation rule on an incident, and they support actions such as isolating a compromised host, resetting credentials, opening a ticket, or sending a Teams notification. Because they run with the Sentinel connector's context, playbooks are the native mechanism for incident-triggered orchestration and satisfy the requirement for automated responses.

The Microsoft Defender for Office 365 data connector in Sentinel is the appropriate choice because it directly ingests rich Office 365 security signals, including alerts for phishing, malware, malicious URLs, and user-reported email threats, as well as unified incidents. This connector enables you to automatically collect these alerts and correlate them with other analytics in Sentinel, providing complete visibility into email, Teams, and compliance-related threats. No other connector provides native, purpose-built ingestion of Office 365 protection data.

This is the correct behavior for the rule's grouping settings. Microsoft Sentinel uses the entity matching method of 'All' to require that alerts share the exact same set of entities for grouping into one incident. When the rule fires, the incident creation engine evaluates each alert against the defined entities and groups those with matching values, providing a unified incident for triage and investigation.

The EmailEvents table in Microsoft 365 Defender Advanced Hunting is the primary source for email metadata, including the sender, recipient, subject, and message ID (NetworkMessageId). It also records delivery status (Delivered, Blocked, Failed) and detection verdicts for malware, phishing, and spam. This table is essential for hunting email-borne threats because it allows you to filter by specific senders or recipients, inspect message disposition, and correlate with other email and identity tables.

This query correctly targets the DeviceProcessEvents table in Microsoft Defender XDR advanced hunting, filters for the process name certutil.exe, and uses has_any to match either of the suspicious arguments. Because DeviceProcessEvents captures process creation events with full command lines, it is the appropriate table for detecting this behavior. The has_any operator efficiently checks for multiple substrings in the command line, making it ideal for this scenario.

Modifying the analytics rule query to exclude sign-ins from the specific location is the precise fix because it filters out false positives at the source while preserving detection for all other events. In KQL, you would add a clause such as `| where Location != 'Country'` or filter by IP address, ensuring the rule's logic specifically ignores the unwanted sign-in origin. This keeps the rule active and focused on real anomalies, reducing alert noise without losing coverage for other suspicious activities.

AADSignInEventsBeta is the correct table because it resides in the Microsoft 365 Defender advanced hunting schema and contains Microsoft Entra ID (Azure AD) sign-in records. Each row represents an authentication attempt, providing the timestamp, source IP address, user principal name (UPN), application, client app, and sign-in result (success or failure). Critically, it includes both interactive and non-interactive sign-ins, so an analyst can pivot on a user's specific IP or timestamp to reconstruct their cloud sign-in activity.

The analytics rule wizard includes a dedicated 'Incident settings' tab where you can enable alert grouping, making it the correct and native mechanism for consolidating alerts into incidents. When enabled, you can configure grouping based on entity matching (e.g., same account, host, or IP address) and set a time window for how far back to look for matching alerts. You can also choose to limit grouping to specific entities or include custom details to refine the grouping logic. This configuration is applied automatically during incident creation, so no additional automation or manual steps are needed.

Downloading hundreds of files from SharePoint Online in a short period matches mass-download behaviour that Defender for Cloud Apps flags as potential exfiltration. The volume and compressed timeframe satisfy the suspicious-activity constraint in the stem, unlike routine single-file access, making it the strongest hunting query candidate.

OfficeActivity represents the unified audit log for Microsoft 365, pulling records from Exchange, SharePoint, OneDrive, Teams, and other workloads. It captures user-level events such as email actions, file accesses, and messages sent after authentication, making it the appropriate table to investigate a user's activities in M365. This table is the primary source for reconstructing user behavior in the M365 environment.

The investigation graph visualises related entities, alerts and activities on a timeline, letting you trace the lateral movement path across accounts and hosts. It surfaces the attack chronology that a raw incident list or hunting query alone would not present as clearly.

A hypothesis must state what the adversary is trying to achieve, since the goal directs which behaviours, telemetry and queries the hunter pursues. Without an objective, hunting lacks a testable premise and becomes unfocused data review.

Enabling the 'Vulnerability assessment for machines' component in the Defender for Servers plan settings is the native, integrated approach within Microsoft Defender for Cloud. This action automatically provisions the Microsoft Defender Vulnerability Management solution to all existing and future Azure VMs and Arc-enabled servers, eliminating the need for per-VM manual steps. It ensures continuous coverage as new machines are added, directly satisfying the requirement to enable vulnerability assessment for existing and future resources at the subscription level.

The Microsoft 365 Defender data connector in Microsoft Sentinel is essential because it ingests alerts and raw events from Defender XDR into the Log Analytics workspace. This connector creates the SecurityAlert and SecurityIncident tables that Sentinel uses to generate incidents, and without it, no Microsoft 365 Defender alert would ever reach Sentinel to trigger any automation. This is why it is the correct component to include, as it is the foundational source of the incident data.

The Microsoft 365 Defender user investigation page (now within the unified Microsoft Defender XDR) provides a single, entity-centric view of a user's alerts, incidents, sign-ins, and related activities across identities, endpoints, email, and cloud apps. It automatically correlates evidence and provides a timeline that allows an incident responder to quickly detect the scope and blast radius of a compromised account. This is the correct investigation surface because it is specifically designed for user entity investigation, and Sentinel can ingest these detections through the Microsoft 365 Defender connector.

The Microsoft Defender for Cloud data connector is the native, purpose-built integration that ingests Defender for Cloud security alerts, recommendations, and incidents directly into Microsoft Sentinel. It requires no extra infrastructure or custom code, automatically streaming alerts from Azure, on-premises, and other cloud workloads protected by Defender for Cloud, and it supports bidirectional status synchronization. This is the correct connector because it directly satisfies the requirement to ingest Defender for Cloud incidents into Sentinel.

Live Response provides a remote, interactive shell session to the VM, allowing an analyst to execute built-in commands or PowerShell scripts directly on the machine. Through this shell, you can enumerate running processes, retrieve their command-line arguments, identify parent-child process relationships, and terminate malicious processes. This hands-on capability is exactly what is needed to investigate the alert and determine whether the process is benign or malicious.

Use the 'Isolate device' action from the Microsoft Defender XDR portal, which invokes Defender for Endpoint's machine isolation and breaks the attack chain by severing all inbound and outbound network traffic, except traffic between the device and the MDE cloud service plus any forensic processes you explicitly allow. This preserves the agent's ability to receive future commands and send telemetry, enabling continued investigation while the threat actor loses connectivity. It is the direct, built-in containment action for an endpoint in an incident.

ParentProcessId is the authoritative column for direct process lineage because it stores the process ID of the process that created the current process. When a process creation event is logged, this field is populated with the parent process's unique identifier, enabling an exact one-level relationship in the process tree. Using it lets you join back to the same DeviceProcessEvents table to retrieve the parent process's command line and metadata.

ThreatIntelligenceIndicator tables store ingested threat indicators, including malicious IP addresses, matched against your environment. Querying it lets you confirm whether the sign-in's source IP appears in known threat intelligence, directly satisfying the requirement to identify a known malicious IP address rather than relying on sign-in logs alone.

Controlled folder access (CFA) in Microsoft Defender for Endpoint is the correct proactive control because it uses a Windows kernel mini-filter to intercept file-write and delete operations, blocking any process that is not on an approved allowlist from modifying files inside protected directories. This directly stops ransomware from encrypting user data in real time, even if the malware has already executed. CFA can be configured via Intune or group policy and provides a targeted, low-disruption defense that preserves forensic data and remote remediation capabilities.

The Azure Monitor Agent (AMA) is the current, unified agent for collecting telemetry from both Azure and non-Azure resources, including Windows servers outside Azure. After you install AMA and associate it with your Log Analytics workspace, you define collection rules via Data Collection Rules (DCRs) to capture security events such as 4624/4625, performance counters, and custom logs for Microsoft Sentinel. For a non-Azure Windows server, you install AMA with an onboarding script or via a management tool, and Sentinel then ingests the data from the Log Analytics workspace as its underlying telemetry source.

A Microsoft Sentinel custom rule that queries Azure SQL audit logs would require shipping all SQL audit telemetry to the Log Analytics workspace, writing and maintaining KQL logic, and mapping data classification tags, which are stored as database metadata rather than as fields within individual audit log records. This approach is operationally heavy, adds detection latency, and fails to leverage the built-in machine-learning anomaly detection in Defender for Cloud's Advanced Threat Protection, so it is not the recommended or efficient solution.

The Microsoft Sentinel Contributor role is the minimal built-in Azure RBAC role that provides full access to Sentinel resources, including the ability to enable UEBA. It grants write permissions to Sentinel settings, such as turning on User and Entity Behavior Analytics from the Settings blade. This role is scoped to the Sentinel workspace or resource group, ensuring least-privilege access for security operators. Because it specifically targets Sentinel's control plane, no additional tenant-level permissions are needed.

The ActionType 'RunAntiMalwareScan' sends a command through the Defender for Endpoint sensor to the antimalware engine, instructing it to execute a scan on the endpoint. This is a non-interactive, one-time response action that can be a full or quick scan depending on device policy, with results reported back to the console. It does not require isolation or a Live Response session.

Before containing or remediating, you must establish scope and impact. Reviewing the device timeline and alert details reveals the affected processes, files and network connections, ensuring subsequent response actions target the actual threat rather than disrupting legitimate activity.

Logic App Contributor is one of the two required permissions because Sentinel playbooks are implemented as Azure Logic Apps. This role provides full management authority over Logic Apps, enabling users to create, edit, and execute the workflows that playbooks depend on. Without it, even with Sentinel-level permissions, the underlying playbook logic cannot be altered or run, making it essential for managing playbooks.

Scheduled analytics rules only raise an alert for each row returned by their KQL query. If the query logic was recently changed—adding an overly restrictive where clause, altering the time range, referencing a renamed table or column—or contains a syntax error, the query can return zero results or fail before producing output. That directly explains why the rule runs on schedule yet no alerts are generated, making query review the first diagnostic step.

Microsoft Defender for Endpoint is the correct source because it is an endpoint detection and response (EDR) solution that installs a sensor on the device, continuously monitoring processes, file executions, registry changes, and behaviors. Its real-time protection and behavioral analytics would detect the malicious file directly on the endpoint, and this detection would surface as an alert in Microsoft Sentinel. As the only option with a local agent capable of seeing file execution, it is the definitive source for this incident.

Threat Explorer (Investigation) is the correct choice because it is a purpose-built email security search tool that lets the analyst search all mail across the organization using filters like sender, recipient, subject, message ID, and delivery status. It provides a comprehensive, KQL-free view of every instance of the email, including delivery actions and threat detections, and supports direct remediation. This makes it the natural first tool for locating and analyzing a specific reported email.

Enabling 'Create incidents from Microsoft 365 Defender' on the Microsoft Defender XDR data connector is the designated method for ingesting already-correlated incidents into Microsoft Sentinel. This toggle allows the connector to pull Defender XDR incidents directly from the Microsoft Graph Security API, ensuring Sentinel receives the full incident with its related alerts, entities, and attack story. Without this setting, the connector would only ingest raw alerts, leaving you to rebuild the correlation that Defender XDR already performed, which defeats the purpose of unified incident management.

Automation rules in Microsoft Sentinel can trigger on incident creation and evaluate conditions such as the analytics rule name. The 'Assign owner' action can set the incident owner to a user or group. This directly meets the requirement with minimal effort and is the native method for automatic assignment.

The KQL `union` operator is the correct choice because it appends rows from two or more tables vertically into a single result set. If the tables have different columns, `union` returns all distinct columns and fills missing values with nulls, which is exactly what is needed to consolidate security data from various sources like SigninLogs, SecurityEvent, and AzureActivity. In Sentinel hunting queries, `union` allows an analyst to stack data sources with different schemas without losing any columns and is standard for cross-source investigation.

Checking the connector health page in Microsoft Sentinel is the correct first step because it provides a centralized view of each data connector's status, including whether it's connected, when the last event was received, and any ingestion errors. This page also shows the connector type, relevant log tables, and version information. If the connector is healthy, the issue likely lies in the source device or forwarder; if unhealthy, you can see specific error messages and take targeted corrective action.

The ServiceNow connector in Microsoft Sentinel provides a native, out-of-the-box integration that allows security operations teams to automatically create, update, and close incidents as ServiceNow tickets. It leverages the ServiceNow API with prebuilt authentication handling and a data collection rule, eliminating the need for custom code or manual API calls. This directly meets the requirement to configure the environment for ticket creation, making it the correct choice.

The 'Enable incident across workspaces' feature in Microsoft Sentinel is a built-in capability that creates a central incident view by aggregating incidents from up to 100 Sentinel workspaces, typically spread across regions or tenants, into a single incident list. It leverages Azure Lighthouse for onboarding, but the key is that Sentinel's incident pipeline synchronizes incidents (by incident ARM ID) into a designated central workspace, preserving the original workspace context for each incident. This gives security operations teams a unified queue for detection, investigation, and response without migrating or re-ingesting any data.

Revoking sessions in Microsoft Entra ID invalidates all refresh tokens and active sessions for the compromised account, immediately cutting off the attacker's access while the password is reset. This directly satisfies the requirement to revoke all active sessions.

The 'Require re-authentication' action is a session-level conditional access app control in Microsoft Defender for Cloud Apps that terminates only the specific anomalous session, leaving the user's other active sessions unaffected. It forces both the user and the attacker to re-authenticate, effectively invalidating the stolen access token for that session and any associated refresh token for that session context. Because it is applied solely to the identified risky session, it minimizes user productivity loss while successfully revoking the attacker's unauthorized access, making it the most targeted and proportionate response.

Microsoft 365 Defender is a valid data source because its built-in connector streams unified alerts and incidents from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Defender for Cloud Apps into Microsoft Sentinel. These security signals include attacker activities, malware events, and phishing detections, which are mapped directly to Sentinel's incident schema for correlation and investigation.

Creating a snapshot of the OS disk from the Azure portal is the correct first step because it produces a read-only, point-in-time copy of the entire virtual disk without powering on the VM, ensuring no writes alter the original evidence. The snapshot captures the raw disk structure including deleted data and file slack, and you can later attach it to a secure analysis VM or use it to instantiate a new disk for offline forensic examination, while storing the snapshot in a separate, access-controlled resource group to maintain chain of custody.

Using Sentinel automation to block outbound traffic to mining pools via NSG rules contains the threat without affecting legitimate traffic; Live Response collects evidence for investigation; Azure Policy to enforce Defender for Endpoint deployment prevents future occurrences by ensuring all VMs have EDR coverage.

Automation rules are the only one of these options that directly acts on incident properties after an incident is created or updated. You can configure a rule with conditions like 'incident title contains critical' and an action of 'Assign to analyst,' which automatically sets the owner field to the chosen analyst. This is the intended, supported mechanism in Microsoft Sentinel for ensuring critical incidents are owned by a specific person.

Selective isolation is the preferred containment action in Microsoft Defender for Endpoint because it blocks all network traffic except communication with the Defender for Endpoint cloud service. This preserves the sensor's ability to send telemetry and receive automated or manual remediation commands, so the security team retains visibility and control during the incident. It effectively halts lateral movement and command-and-control while keeping the device within the security management plane, making it the only option that both contains the threat and maintains operational monitoring.

Live Response in Microsoft Defender XDR supports running the `Get-File` and memory-dump collection commands directly on a compromised Windows endpoint, satisfying the requirement to gather volatile forensic evidence without disrupting the device. This preserves RAM contents that would otherwise be lost on shutdown, which is essential for incident response.

A DLP policy in Microsoft Purview is the correct control because it can be configured with the Credit Card Number sensitive info type, which uses pattern matching and checksum validation to detect this data in Exchange Online mail. The policy can specify an action to send an alert to the security team whenever the data is detected, meeting the alerting requirement precisely.

Microsoft Defender XDR supports custom roles created in the portal with granular permissions, such as the specific 'View incidents' permission under the Security operations category. Assigning that custom role to the Security Operations group grants them exactly the read-only incident access they need without broadening to endpoint management or unrelated security workloads. This is the precise, least-privilege approach and aligns with Defender XDR's unified RBAC model for isolated access to alert and incident data.

The Microsoft Teams connector in Sentinel automation rules can post messages to a Teams channel or send adaptive cards, which is the standard way to notify analysts of incidents. It supports actions such as 'Post message (V3)' that can include incident details, and it also allows for approval flows via Teams. This aligns with the requirement to configure SOAR capabilities for messaging a team.

Initiating user risk remediation in Microsoft Entra ID Protection is the correct, containment-focused response because it lets you confirm the sign-in as compromised, immediately revoke all refresh tokens and session cookies, and force the user to reauthenticate with a new password. This directly neutralizes the attacker's token-based access while preserving the legitimate user's ability to regain access after verification. It combines detection with automated, policy-driven response and is the documented best practice for handling confirmed user risk in Entra ID.

Enabling the Microsoft Defender XDR connector streams Defender for Endpoint alerts into Microsoft Sentinel, where the "Create incidents" toggle governs automatic incident generation. This directly satisfies the requirement to auto-create Sentinel incidents from endpoint alerts, since the connector's incident creation setting is the mechanism controlling that behaviour.

The automation rule's trigger is the likely culprit. In Microsoft Sentinel, automation rules can be configured to run when an incident is created, when an incident is updated, or when an alert is generated. If your rule runs only at creation time, the playbook executes immediately after the incident is born, before any status changes, owner assignments, or alert grouping that would normally follow. Many playbooks—especially those using the Sentinel incident connector's 'Get incident' action—expect the incident to have these post-creation values, and without them the playbook may error out or take an incorrect action. To resolve this, you should create a second automation rule triggered on incident update, or change the trigger to match the playbook's dependency.

Threat Explorer in the Microsoft 365 Defender portal is the actual investigation-and-remediation surface for email threats; it combines a robust queryable event store with built-in actions. You can filter by threat type, sender, subject, or detection technology, select one or multiple messages, and directly delete (soft or hard) them from user mailboxes. For a suspicious email already delivered, this is the only option that both finds and removes it. Also supports in-place review of the payload and email summary.

Set-MpPreference -DisableRealtimeMonitoring $false is the correct command because it explicitly sets the DisableRealtimeMonitoring configuration to false, which re-enables Microsoft Defender's real-time scanning engine. This preference is the direct control for the monitoring state, and applying it reverses any setting that previously disabled the service. It is the only option that addresses the root cause of a disabled real-time protection rather than performing an unrelated action.

This sequence is the exact workflow for a Microsoft Sentinel saved hunting query. You must first select the Sentinel workspace, open the Hunting blade, and click 'New Query' to instantiate a blank query editor. Writing and running the KQL before saving is critical because Run executes the query against the workspace's Log Analytics tables and lets you validate the result set. Only after confirming the query returns the intended rows should you save it with a meaningful name and description for future hunting loops.

SigninLogs holds Microsoft Entra ID interactive sign-in events with UserPrincipalName and IPAddress, so filtering the last 24 hours and summarising by IPAddress satisfies the requirement to enumerate distinct source addresses for that user. AADNonInteractiveUserSignInLogs would not match interactive portal sign-ins.

Automation rules support the "Assign owner" action, which lets you set the incident's owner to a specific analyst, a group, or a user by email address. This action can be triggered when an incident is created or updated based on conditions such as severity or analytics rule, thereby enabling systematic incident triage and routing directly from the rule.

Enabling the Servers plan in Microsoft Defender for Cloud is the required subscription-level action that activates the built-in vulnerability assessment for Azure VMs. This plan automatically deploys the Defender Vulnerability Management solution to both existing and newly created VMs, and the resulting scans are surfaced as recommendations and findings within Defender for Cloud. Without this plan enabled, there is no integrated vulnerability scanning available.

The Log Analytics agent (or Azure Monitor Agent) must be installed on the Linux server before any syslog collection can occur. The agent acts as the local collector: it listens on UDP 25224 for syslog messages forwarded by the rsyslog daemon, applies filtering rules for facilities and severities, and then sends the parsed events to the Log Analytics workspace. Without the agent, there is no component to receive and ingest the syslog stream, regardless of rsyslog configuration.

Microsoft Defender for Office 365 Threat Explorer is the correct tool because it provides a granular email-focused entity view that includes delivery actions, threat types, phish simulation tags, and associated campaign information for messages that bypassed filtering. Analysts can pivot from a single email ID to see message traces, sender and recipient details, and the specific policy or isolation verdict applied. This investigative capability directly addresses the need to examine a suspicious email received despite the existing spam filter.

Reviewing all failed attempts from that IP in the Activity log reveals the pattern, volume and targeted accounts, confirming whether the behaviour constitutes brute-force credential guessing rather than isolated user error. This evidence-based correlation is the most effective next investigative step.

The endswith operator checks if a string ends with a specified suffix. Using endswith '.locked' on the FileName column will accurately identify files that have been renamed with the '.locked' extension, which is characteristic of ransomware encryption. This operator is case-insensitive and efficient for this purpose.

The bin(TimeGenerated, 5m) function rounds each event's timestamp down to the start of its containing five-minute interval, so summarize groups all events from the same IPAddress that occur within that same bucket and counts them as a single aggregate. This is the standard KQL pattern for time-windowed aggregation in scheduled analytics rules because it collapses many raw events into per-IP, per-window counts. Without a bin expression, the query would not define fixed time windows, making this the only option that correctly produces the desired 5-minute grouping.

Disabling the associated accounts in Microsoft Entra ID revokes authentication tokens and prevents the attacker reusing compromised credentials to re-encrypt or pivot. This satisfies containment by cutting the identity path, since ransomware operators routinely retain valid accounts to re-establish access after device-level cleanup.

Reviewing Microsoft Entra ID audit logs exposes the specific directory operations AzureHound performs, such as role assignments and service principal enumeration, letting you confirm whether the flagged activity is genuine privilege-escalation reconnaissance rather than benign administrative behaviour. This directly satisfies the stem's requirement to validate the alert before escalating.

Configuring the Microsoft Sentinel Entra ID connector requires interactive authentication with a user who holds the Security Administrator or Global Administrator role. This role is necessary to grant the connector consent to access Microsoft Graph APIs for reading directory audit and sign-in logs, and to create the required diagnostic settings. Without this privilege, the connector cannot be enabled even if the workspace and licenses are in place.

Brute-force detection requires correlating failures with eventual success, not just counting successful sign-ins. Including failed attempts and filtering for users with many failures plus at least one success exposes password-guessing that succeeded, which the current success-only query misses entirely.

Enabling Azure Defender for SQL on the SQL Server VM activates Advanced Threat Protection (ATP), which surfaces SQL injection attempts, anomalous user logins, and brute-force attacks specific to the database engine. This plan integrates with the Log Analytics agent to evaluate SQL audit logs in real time and generates actionable security alerts. It is the only option that directly provides the SQL-specific threat detection required by the scenario.

In Microsoft Sentinel, an automation rule is the correct mechanism to trigger a playbook when an incident is created. Since the UEBA analytics rule generates incidents for suspicious behavior, you attach an automation rule to that rule that invokes a playbook. The playbook can then call Microsoft Entra ID to disable a user account, providing immediate, coordinated incident response.

Revoking Entra ID sessions invalidates refresh tokens immediately, while resetting the password in both directories removes the attacker's on-premises and cloud credentials. This dual reset contains the compromised admin account before further security group modifications occur.

Sign-in logs record token issuance details, including the token's unique identifier and authentication context, letting you correlate the alert with the specific session and confirm whether a stolen or replayed token was used rather than legitimate credentials.

Configuring tenant-wide settings in Microsoft 365 requires the Global Administrator role because these settings affect the entire organization, such as organizational profile, privacy preferences, and integration options. Only Global Administrators have the necessary authorization to modify settings that apply to all users and services across the tenant, ensuring central control and compliance with organizational governance.

When a CSV file is uploaded as a new custom table in a Microsoft Sentinel Log Analytics workspace, it is assigned a name with the '_CL' suffix and stored as a regular KQL table. You can directly reference that table name, e.g., 'MaliciousIPs_CL', in a scheduled query just like any other table, because the data is already ingested and available for Kusto to scan. This is the standard and most efficient way to query custom log data, as no additional functions, operators, or external references are required.