SC-200 Cheat Sheet

Configure incident notification rules under Settings > Microsoft Defender XDR > Email notifications > Incidents. Rules can filter by alert severity, service or detection source, and device group, allowing different SOC teams to receive relevant incidents rather than every alert.

Trap Using an Actions notification rule, which filters response operations rather than incident alerts.

Use the Actions tab of Defender XDR email notifications to select manual or automated action sources, action types, device groups, and completed or failed status. Selecting All device groups covers current and future groups. Response action email notifications currently do not support response actions contained in custom detections.

Trap Using incident severity as a proxy for remediation failure, which describes alert risk rather than action execution status.

Create a notification rule on the Threat analytics tab to receive emails when reports are published or updated. Select all reports or filter by report type or tag; a matching report need not represent an incident in your tenant. Add at least one recipient and use Send test email to verify delivery.

Trap Creating an alert notification rule, which subscribes to tenant detections rather than threat report updates.

Managing incident and action email rules requires Manage security settings permission, or Security Administrator under basic permissions management. With RBAC, administrators can create, edit, delete, and receive notifications only for device groups they are permitted to manage. Adding an email recipient does not expand the administrator's device scope.

Trap Assigning Security Reader to a notification administrator, which supplies visibility without security-settings management.

Configure endpoint alert subscriptions under Settings > Endpoints > General > Email notifications, separately from the XDR incident, action, and threat analytics subscriptions. Use Add item to select alert severity, devices or device groups, and recipient email addresses, then send a test email and save the rule. If matching alerts do not arrive, inspect Junk Email, the mail security product, and mailbox rules that move messages. New recipients receive notifications for alerts triggered after they were added rather than a replay of earlier alerts.

Trap Editing an XDR incident subscription to repair missing endpoint-alert emails, leaving the separate endpoint notification rule unchanged.

Use the Hide alert action in an alert tuning rule for known benign Defender for Endpoint activity that should not create incidents. Hidden alerts remain in AlertInfo and AlertEvidence for hunting. This action is available for Defender for Endpoint alerts, not every Defender workload.

Trap Creating an antivirus exclusion, which changes protection coverage rather than only alert visibility.

Choose Resolve alert when matching alerts and associated incidents should be automatically resolved rather than hidden. The alert and incident records still exist with resolved status, providing a record of expected activity. Scope the rule to evidence that reliably identifies the approved activity.

Trap Choosing Hide alert when resolved incident records are required, because hiding prevents incident creation.

Set as behavior converts matching signals into behaviors that do not appear in the alert queue or trigger incidents. Query BehaviorInfo and BehaviorEntities to retain investigative visibility. This tuning action is not supported for Defender for Cloud or Defender for Office 365 alerts.

Trap Selecting Resolve alert, which retains alert records rather than converting signals into behavior records.

Alert tuning supports evidence such as files, processes, and scheduled tasks, with up to 200 conditions per rule. Combine conditions with AND, OR, and grouping; condition values are case-insensitive and some properties support wildcards. An alert type is identified by IoaDefinitionId, so a display-title change does not necessarily identify a new type.

Trap Matching only an incident's display title, which is not the evidence-based alert type used by tuning.

Enable Restrict correlation to within scoped device groups when local SOC teams must act on incidents confined to their accessible groups. Cross-group alerts no longer form one incident, so the global SOC sees separate incidents by device group. The setting affects future correlations only.

Trap Using an email device-group filter to separate incidents, which changes notification recipients without changing correlation.

Microsoft's built-in tuning rules reduce noise from common benign activity without disabling associated automated investigations or email notifications. If an automated investigation finds malicious or suspicious activity, Defender reactivates the suppressed alert. These built-in rules do not apply to custom detection alerts or Custom TI alerts. Use custom tuning when an organization-specific condition needs its own suppression policy.

Trap Relying on built-in benign-activity suppression to quiet a custom detection, which lies outside the built-in rules' scope.

When creating a tuning rule from an alert, choose either the selected alert type or Any alert type based on certain conditions. For the latter, select the service sources to which the rule should apply; only services you have permission to manage are offered. Use the selected-type option when the approved exception concerns one detection rather than every detection involving the same evidence. Broadening both type and service scope can suppress unrelated alerts that happen to satisfy those evidence conditions.

Trap Selecting any alert type across all services for one benign detection, extending the exception to unrelated detections sharing its evidence.

Hiding or resolving alerts changes alert handling, not the allow decision for a file that triggered them. After creating a tuning rule from an alert, the Successful rule creation page can separately add selected evidence as Allow indicators. Select the approved file and its intended scope, then save that allowance when preventing future blocking is also required.

Trap Using Resolve alert tuning as an application-unblocking exception, although changing alert status does not create the file's scoped Allow indicator.

Enable EDR in block mode to remediate malicious artifacts detected by endpoint detection and response even when Microsoft Defender Antivirus runs in passive mode. This complements another primary antivirus product rather than making Defender Antivirus the primary real-time scanner. Configure the feature under Settings > Endpoints > Advanced features.

Turn on Custom network indicators before using an organization-specific list of IP addresses, domains, or URLs to allow or block destinations. Use web content filtering instead when the requirement is to block categories of websites rather than named destinations. These are separate controls in Endpoint advanced features.

Trap Selecting web content filtering for a specific IP block, because its policy model selects content categories.

Enable Allow or block file when file indicators must prevent devices from reading, writing, or running identified files. Microsoft Defender Antivirus must be the active antimalware solution and cloud-based protection must be enabled. Merely onboarding a device does not establish these prerequisites.

Trap Relying on passive antivirus plus EDR block mode as the stated prerequisite for Allow or block file, which requires active antivirus.

Enable tamper protection to stop applications and other unauthorized methods from changing protected Microsoft Defender Antivirus settings. Its purpose is to preserve security configuration during attacks. It is distinct from a rule that blocks a particular application behavior.

Trap Using an ASR rule as a substitute for locking antivirus configuration, because ASR targets risky software behaviors.

Automatically resolve alerts closes alerts when no threats are found or detected threats are remediated. It does not overwrite a status that an analyst manually set to In progress or Resolved. Since active alerts contribute to device risk, automatic resolution can also affect the device's risk level.

Trap Creating broad benign-activity suppression to close remediated threats, which ignores the remediation-based eligibility of automatic resolution.

Enable Microsoft Defender for Cloud Apps integration to forward Defender for Endpoint signals for cloud application visibility. The forwarded information is stored and processed in the Defender for Cloud Apps data location. Use this integration for application-use insight, not as an alternative to endpoint onboarding.

Enable Device discovery in Endpoint advanced features to find unmanaged devices through endpoints already onboarded to Defender for Endpoint. Discovery adds visibility to the device inventory and helps assess risks without deploying a separate discovery appliance. Review onboarding status and onboard eligible discovered endpoints separately when they need endpoint protection. An inventory entry produced by discovery is not evidence that the discovered device has a Defender sensor.

Trap Treating a discovered workstation's inventory entry as completed onboarding, although discovery can list devices with no installed sensor.

Under Settings > Endpoints > Advanced features, enable Live response for device sessions and configure the separate Live response for servers switch for server sessions. Save preferences after changing the relevant switch. These controls make sessions available to appropriately authorized users; assigning a response role alone does not turn the feature on. When an authorized responder cannot open a server session, check the server-specific enablement rather than increasing the responder's privileges.

Trap Granting a broader administrator role to overcome disabled server live response, although role assignment does not enable the server capability.

Enable the Microsoft Intune connection in Defender for Endpoint and complete the corresponding integration in Intune. This connection shares device data for risk-based compliance and Conditional Access enforcement. It requires an active Intune environment and appropriate licenses rather than being supplied by the Endpoint switch alone. Configuring this integration establishes the risk-sharing path; it does not itself author the access policies that consume that risk.

Trap Turning on only the Defender-side Intune switch, leaving the required Intune-side connection incomplete.

Turn on Web content filtering, then create a policy specifying blocked categories and the intended device groups. On Windows, enable SmartScreen for Microsoft Edge and network protection in block mode for supported non-Microsoft browsers. On macOS and Linux, network protection in block mode is required for all supported browsers, including Edge. A policy with no categories selected audits web activity rather than blocking categories.

Trap Leaving network protection in audit mode while expecting Chrome category blocks, although its enforcement path requires block mode.

Turn on Authenticated telemetry under Endpoint advanced features when protecting dashboard telemetry integrity. This setting prevents spoofing telemetry into the dashboard. It addresses the trustworthiness of incoming telemetry rather than which web destinations an endpoint may access.

Hide potential duplicate device records matches records by hostname and last seen time and keeps the most accurate record visible. It hides duplicates from Device inventory, vulnerability management pages, and public machine-data APIs. The records remain available in global search, advanced hunting, alerts, and incidents. The setting is enabled tenant-wide by default and can be turned off to show those duplicate records again.

Trap Using duplicate-record hiding as an evidence-deletion mechanism, although investigative surfaces retain the hidden records.

Enable Share endpoint alerts with Microsoft Compliance Center to send endpoint security alerts and their triage status to the Microsoft Purview portal. With the relevant insider-risk policy indicators configured, the integration shares alerts for applicable users with insider risk management. Forwarded data is stored in the same location as Office 365 data. Choose this sharing control for insider-risk consumption rather than the Cloud Apps integration used for cloud-application visibility.

Trap Enabling Cloud Apps integration to supply Purview insider-risk alerts, routing endpoint signals to the wrong consuming service.

The Download quarantined files advanced feature backs up quarantined files in a secure, compliant location so responders can download them directly from quarantine. The setting is enabled by default. Check this evidence-preservation setting when planning later retrieval rather than treating file blocking or live response enablement as the backup mechanism.

Trap Using live response enablement as assurance that quarantine has a downloadable backup, although interactive session access does not configure the quarantine backup feature.

Enable Show user details in Endpoint advanced features to expose profile information stored in Microsoft Entra ID while investigating user account entities. Available details include the user's picture, name, title, and department in views such as the alert queue and device details page. This switch supplies identity context rather than changing an account's access permissions.

Trap Reaching for the Defender for Cloud Apps integration to display an account's department, although that integration forwards endpoint signals for application-use visibility.

Enable Default to streamlined connectivity when onboarding devices in the Defender portal to make the streamlined package the default for supported operating systems. The standard package remains available through an explicit selection on the onboarding page. This setting controls the default package choice rather than forcing every onboarding operation to use streamlined connectivity.

Trap Turning off the tenant's streamlined default merely to obtain one standard onboarding package, although the onboarding page still offers that package explicitly.

Configure an endpoint indicator's action, expiration, and device-group scope to apply a threat decision only where and while it is needed. Indicators can represent files, certificates, IP addresses, domains, or URLs. An indicator is a detection or enforcement rule, not merely a saved hunting search.

Trap Adding an IOC only to a Sentinel watchlist, which does not configure endpoint prevention actions.

Specify individual IP addresses for endpoint IP indicators; wildcards and ranges are not supported. IPv4 uses dotted-quad notation, while the documented IPv6 format includes all eight segments. A subnet-level network requirement therefore cannot be represented by entering a CIDR range as one indicator.

Trap Entering a firewall-style CIDR network into the indicator field, which does not support ranges.

A domain indicator such as example.com covers that domain and its subdomains. A URL-path indicator targets resources under the specified path instead. HTTPS URL-path matching is supported in Microsoft Edge, while HTTP URL paths can be matched across browsers.

Trap Choosing an HTTPS path indicator for browser-independent path blocking, because encrypted path matching is Edge-specific.

Use a certificate indicator when the allow or block decision should follow a signing certificate rather than one file version. Certificate indicators accept CER or PEM files. File-hash indicators identify individual file content, so changed application versions can require different hashes.

Trap Blocking one executable hash to cover every future release from its publisher, because changed file content changes the hash.

When a team needs one site in an otherwise blocked web category, create an Allow domain indicator scoped to that team's device group. This preserves category-based blocking for other users and sites. Allow indicators do not generate alerts by design.

Trap Disabling the entire web content filtering category, which removes the restriction beyond the required business exception.

Select Audit to alert on an indicator match without blocking, Warn to offer a user-bypassable warning, or Block execution to prevent execution without that bypass. Block and remediate also applies remediation and is supported for files and certificates, not IP addresses, URLs, or domains. File indicators support all these actions, while certificates support only Allow or Block and remediate. Choose both the indicator type and action from the required outcome rather than assuming every object supports an audit or warning stage.

Trap Selecting Audit for a certificate indicator to stage a publisher policy, although certificates offer only Allow or Block and remediate.

Network protection determines whether to allow or block website access after the TCP three-way handshake completes. A ConnectionSuccess record describes success at the TCP layer, not a final decision to permit the website. Inspect the associated block or alert evidence before declaring that the network indicator failed. Recreating the indicator solely because the handshake succeeded addresses the wrong layer of the connection.

Trap Treating ConnectionSuccess as proof that a blocked site was usable, confusing transport establishment with the later network-protection verdict.

File and certificate indicators do not block exclusions defined for Microsoft Defender Antivirus. When an apparently valid blocking indicator does not stop a matching file, inspect the effective antivirus exclusions and correct an unintended exception. Adding the same blocking hash again does not override the exclusion. Preserve an exception only when its security tradeoff is intentional and approved.

Trap Adding a certificate block to overcome an antivirus file exclusion, although certificate indicators honor that exclusion boundary too.

For indicators synchronized from Defender for Cloud Apps, the sanctioned or unsanctioned application policy is authoritative over locally edited indicator settings. Unsanctioned applications enable Generate Alert, and clearing it in Defender for Endpoint can be reversed by the next synchronization. Diagnose repeated reversions at the originating Cloud Apps policy rather than repeatedly editing the generated indicator. Sanctioned or allowed applications use the no-alert setting, but changing an application's sanction status also changes the underlying access decision.

Trap Repeatedly clearing Generate Alert on a synchronized unsanctioned-app indicator, although the source Cloud Apps policy restores its setting.

Use App Control for Business or AppLocker when the goal is to prevent an application persistently rather than stop one identified malicious file. Applications commonly contain multiple files, so a hash indicator for one component does not express the complete application restriction. A file indicator is appropriate as an immediate containment measure for a known file, not as the primary long-term application-control policy.

Trap Blocking only the main executable's hash as a durable application ban, leaving other application components outside the indicator's identity match.

Microsoft documents an indicator alert limitation in which Block and Warn produce generic informational alerts rather than alerts with the configured custom title and severity. Audit alerts use the customer-provided severity. Validate alert presentation against the selected action before diagnosing an informational block alert as a failure to save a high-severity configuration.

Trap Repeatedly raising a Block indicator's custom severity to force a high-severity alert, although its documented alert path produces generic informational output.

For an indicator configured with Warn, enable Files or activities are blocked under Windows Security's Virus & Threat Protection notifications so the user receives the bypass prompt. The corresponding FilesBlockedNotificationDisabled registry value must be 0. When the intended warning interaction is missing, inspect notification delivery rather than changing the indicator into a permanent Allow exception.

Trap Replacing Warn with Allow to repair a missing bypass prompt, removing the warning decision instead of enabling its blocked-activity notification.

EnableFileHashComputation calculates file hashes during scans and supports IoC enforcement against hashes belonging to trusted applications. It is disabled by default and is enabled manually through Group Policy alongside the Allow or block file configuration. Evaluate this setting when validating trusted-application hash enforcement rather than assuming the portal's file-control switch establishes hash computation.

Trap Using successful file-indicator creation as proof that trusted application hashes are being computed during scans, although that computation has a separate disabled-by-default setting.

Defender for Endpoint limits the tenant to 15,000 indicators, and Microsoft does not support increasing that limit. Size feed imports against the tenant-wide allowance rather than treating each device group as a separate capacity pool. A feed exceeding the allowance needs selection and lifecycle management instead of a quota-increase dependency.

Trap Splitting an oversized indicator feed across device groups to obtain extra capacity, although the limit is counted at tenant scope.

Custom data collection captures endpoint events beyond default telemetry and requires Defender for Endpoint Plan 2 plus a connected Microsoft Sentinel workspace. Select that workspace explicitly in Custom Data Collection even if it is already connected. The current feature supports one Sentinel workspace per tenant, and Sentinel ingestion charges apply.

Trap Extending XDR retention to collect missing event types, which preserves collected telemetry without configuring additional collection.

Scope a custom data collection rule to all applicable devices or to devices with dynamic tags from Asset Rule Management. The dynamic tag rule must have run at least once; manual static tags are not supported. If expected devices produce no events, verify tag evaluation as well as the collection rule.

Trap Applying a manual device tag for collection targeting, which is not supported by custom collection scope.

Each custom collection rule can capture up to 75,000 events per device in a rolling 24-hour window. Collection for that rule pauses on a device that reaches the limit until the window resets. Refine table, action, and event conditions when overly broad collection exhausts the allowance.

Trap Increasing workspace retention to fix stopped collection, which changes storage duration rather than the device collection cap.

Custom endpoint collection supports Windows 10 and Windows 11 with a minimum client version of 10.8805, and Windows Server 2019 or later. Windows 10 requires ESU enrollment. Check these prerequisites before investigating missing rule deployment on an otherwise onboarded endpoint.

Creating or editing a custom collection rule typically takes 20 minutes to one hour to deploy. Verify events in DeviceCustomFileEvents, DeviceCustomScriptEvents, DeviceCustomNetworkEvents, DeviceCustomProcessEvents, or DeviceCustomImageLoadEvents as appropriate. RuleName and RuleLastModificationTime help distinguish a deployed revision from older output.

Trap Checking only DeviceProcessEvents for custom rule output, because custom process telemetry has its own table.

Deleting a custom data collection rule permanently removes that rule and stops new collection. Historical data already in Sentinel remains available under its retention settings. Disable a rule instead when a reversible pause is required.

Trap Deleting the rule as a way to purge historical telemetry, which does not delete data already stored in Sentinel.

Use ASR rules for requirements such as blocking executable content from email, Office child-process creation, or untrusted and unsigned processes running from USB. These rules target behaviors commonly abused by attackers. Controlled folder access is the alternative for protecting designated folders against unauthorized changes.

Trap Choosing controlled folder access to block Office child processes, because it protects folder writes rather than that process behavior.

ASR rules require Microsoft Defender Antivirus as the primary antivirus in Active mode with real-time protection enabled. Passive mode, including passive mode with EDR in block mode, does not satisfy this requirement. Cloud-delivered protection is also important, and some rules have explicit cloud dependencies.

Trap Using EDR in block mode to satisfy the ASR antivirus prerequisite, because ASR requires active real-time antivirus.

Deploy ASR rules in Audit mode to observe affected applications without enforcing the block, then use the results to refine policy before switching to Block or Warn. Microsoft distinguishes standard protection rules, which normally need less testing, from other ASR rules that should be tested first. Environments using Configuration Manager need particular care with the WMI persistence rule because that client relies on WMI.

Trap Using Block mode as an observation-only pilot, which enforces the behavior restriction during the test.

In Intune Endpoint security, create an Attack surface reduction policy with platform Windows and profile Attack Surface Reduction Rules. For devices managed through Defender for Endpoint security settings management, assign policies to Microsoft Entra device groups. That management path supports device objects rather than user targeting.

Trap Assigning the policy to an Entra user group for Defender for Endpoint management, which supports device targeting only.

Choose Block credential stealing from the Windows local security authority subsystem when applications must be prevented from accessing LSASS memory to extract credentials. A block event for an updater means its LSASS access was denied, not that the updater was prevented from running. Unnecessary LSASS enumeration can generate events without a functional failure, so an event alone does not justify an application exception. When LSA protection is enabled, Microsoft documents this ASR rule as redundant and not applicable in the management settings.

Trap Exempting a functioning updater merely because its LSASS access was blocked, restoring unnecessary access to credential-bearing memory.

Enable Block abuse of exploited vulnerable signed drivers to prevent applications from saving vulnerable signed drivers on the computer. A valid signature does not make a vulnerable driver safe, because privileged applications can exploit it to gain kernel access. The rule does not prevent loading a vulnerable driver already present on disk. Add an appropriate application-control or vulnerable-driver blocklist control when existing driver loading must also be prevented.

Trap Relying only on vulnerable-driver ASR after the driver is already installed, although its enforcement boundary is saving drivers rather than loading existing ones.

When an allowed Office macro drops an untrusted executable, select Block Office applications from creating executable content to prevent access to or execution of that payload. If the attack instead moves code into an existing process, select Block Office applications from injecting code into other processes; restart Office applications after configuring it. For a VBA macro that invokes native APIs without writing a payload, select Block Win32 API calls from Office macros, which depends on AMSI. Blocking executable creation alone does not address an attack whose relevant operation is memory injection or an API call.

Trap Choosing Office executable-content blocking for a fileless VBA Win32 API attack, although the malicious operation does not depend on a dropped executable.

Choose Block execution of potentially obfuscated scripts when suspicious properties inside concealed script content are the behavior to stop; the rule supports PowerShell and requires AMSI and cloud-delivered protection. Choose Block JavaScript or VBScript from launching downloaded executable content when the behavior is a script fetching and starting a payload, even if the script is readable. The downloaded-content rule depends on AMSI but does not list cloud protection as an enforcement dependency. Test legitimate obfuscated applications and scripted installers because each can exhibit the behavior its respective rule targets.

Trap Using only obfuscated-script protection against a readable VBScript downloader, mistaking concealment detection for downloaded-payload launch control.

Use Block persistence through WMI event subscription to prevent malware from abusing the WMI repository and event model for persistent execution; this rule depends on RPC. Use Block process creations originating from PSExec and WMI commands when the requirement is to stop processes launched through those remote execution mechanisms. Microsoft advises against enabling the process-creation rule through alternative deployment methods on Configuration Manager-managed devices because its client relies heavily on WMI. An event-subscription persistence control is not a general replacement for remote process-creation blocking.

Trap Selecting WMI event-subscription blocking to stop a PSExec-launched process, although that process does not require WMI persistence.

For execution restricted by file trust, select Block executable files from running unless they meet a prevalence, age, or trusted list criterion. For additional ransomware-focused protection, select Use advanced protection against ransomware, which combines client and cloud heuristics and can block files that lack a positive reputation. Both rules require cloud-delivered protection. An unknown business executable can therefore need compatibility evaluation even when no known-malware signature identifies it.

Trap Assuming a new unsigned business executable is exempt because it has no known malware verdict, overlooking the absence of sufficient positive reputation.

Choose antivirus, antivirus-exclusion, and EDR templates for supported Windows, macOS, or Linux devices; Defender Firewall and Firewall rules templates are Windows-specific. Use the firewall profile for firewall settings and the firewall-rules profile for individual traffic rules rather than an ASR profile. After configuring the Intune connection and security settings management, supported policies can also reach devices onboarded to Defender for Endpoint but not enrolled in Intune. Onboarding does not make every policy template available on every operating system.

Trap Assigning a Windows Defender Firewall template to Linux endpoints merely because they are onboarded, ignoring platform-specific template support.

With Defender unified RBAC, grant Core security settings (manage) under Authorization and settings > Security settings to create and manage endpoint security policies. The permission must apply to all devices: a role limited to specific device groups cannot open the Endpoint security policies page. Core security settings (read) is the alternative for read-only access. Regardless of the access-granting role, the displayed policy list is also scoped by Intune RBAC assignments.

Trap Granting policy-management permission only on one device group, leaving the administrator unable to open the all-device policy-management surface.

Open the saved endpoint policy to inspect its status, applicable devices, and assigned groups, then use the device's Configuration management > Security policies tab to check applied policies. Devices managed through Defender security settings management check with Intune every 90 minutes. To request an earlier refresh, choose More actions > Policy sync on the device entity page; application should occur in about 10 minutes. A policy listed in inventory proves creation, not that each target has applied it.

Trap Creating another copy of a policy before checking assignments and synchronizing the device, adding configuration without resolving delivery latency.

Choose Block Adobe Reader from creating child processes when a PDF attack uses Reader to launch another process. Choose Block Office communication application from creating child processes when Outlook is the parent application. The general Office child-process rule targets applications such as Word, Excel, and PowerPoint, so its name should not be treated as coverage for every application in these scenarios.

Trap Using Block all Office applications from creating child processes for an Outlook-launched payload, overlooking the distinct Office communication application control.

Select Block rebooting machine in Safe Mode to stop commonly abused commands such as bcdedit and bootcfg from restarting Windows into Safe Mode. Attackers use this transition because security products can be disabled or run with reduced functionality there. Manual Safe Mode access through Windows Recovery Environment remains available, so this rule is not a prohibition on all recovery entry paths.

Trap Using this ASR rule to enforce a requirement that nobody can enter Safe Mode through Windows Recovery Environment, a manual route that remains accessible.

Block use of copied or impersonated system tools treats executables in the Windows System32 and SysWOW64 directories as system tools. It blocks copies or same-named files running elsewhere even when Microsoft or another trusted vendor signed them. Select this rule for relocated or impersonated tool execution rather than relying on a signature or prevalence-based trust decision.

Trap Using a valid Microsoft signature to dismiss a copied-tool ASR block as impossible, although the rule evaluates execution outside the system tool's expected location.

Choose Block Webshell creation for Servers to prevent web-shell script creation on Windows servers running Microsoft Exchange. Such scripts can give an attacker remote command execution, payload download, or credential theft capabilities on the compromised server. Match the policy to this supported server workload rather than interpreting the rule as a general Office or script-execution restriction.

Trap Using Block Office applications from creating executable content to stop an Exchange web-shell drop, although that rule depends on Office applications writing the payload.

Local ASR configuration through Set-MpPreference has the lowest precedence. Policy-based configuration overwrites conflicting local settings on startup. Correct the authoritative management policy when a local change repeatedly disappears.

Trap Repeating Set-MpPreference at each restart, which leaves the higher-precedence policy conflict unresolved.

When Group Policy and MDM configure the same ASR rule, Group Policy takes precedence by default. Setting the ControlPolicyConflict Policy CSP value MDMWinsOverGP to 1 makes MDM win instead; its default value is 0. Avoid configuring the same rule through competing authorities when possible.

Trap Assuming the most recently edited Intune policy always wins, because default conflict precedence favors Group Policy.

Use Add-MpPreference to add ASR rule IDs and corresponding actions without replacing existing assignments. Set-MpPreference overwrites the specified ASR configuration, while Remove-MpPreference removes selected entries. Pair AttackSurfaceReductionRules_Ids with the intended AttackSurfaceReductionRules_Actions values.

Trap Using Set-MpPreference to append a single rule, which can replace the previously configured rule list.

ASR action values include 0 for Disabled, 1 for Enabled or Block, 2 for Audit, 5 for NotConfigured, and 6 for Warn. Select the value for the intended rollout behavior rather than treating every nonzero value as blocking. Configuration methods that identify rules by GUID still require the correct action for each rule.

Use ASR only per rule exclusions when an approved path should bypass just one supported rule. Attack surface reduction only exclusions apply across ASR rules that honor those exclusions. Prefer the narrow exception that resolves the verified application conflict instead of exempting the path from every applicable ASR rule.

Trap Using a global ASR exclusion for a single-rule compatibility issue, which broadens the exemption to other rules.

Warn initially blocks the activity but offers Unblock for a 24-hour bypass, unlike Audit, which records without blocking, or Block, which provides no such bypass. Starting with Defender Antivirus platform version 4.18.26060, using Unblock requires administrator approval. The LSASS credential-theft and Office process-injection rules do not support Warn. Use a supported enforcement mode for those rules rather than promising users a warning-based exception.

Trap Using Warn for Office process-injection compatibility, although that rule does not implement the bypass mode.

Check an ASR rule's exclusion compatibility before reusing an antivirus file or folder exception. Block credential stealing from the Windows local security authority subsystem ignores Microsoft Defender Antivirus file and folder exclusions but honors ASR exclusions. For a verified compatibility problem requiring an exception to this rule, configure an ASR exclusion rather than assuming the antivirus path exclusion applies.

Trap Using an antivirus folder exclusion for a password-sync application's LSASS access, even though this rule does not consult that exclusion type.

ASR enforcement and notification support are separate capabilities: the LSASS credential-theft rule lists neither EDR alerts nor user notifications. For Block Adobe Reader from creating child processes, EDR alerts require High plus or Zero tolerance cloud protection, while user pop-ups require High, High plus, or Zero tolerance. Check the specific rule's notification support and cloud protection level before treating a silent block as failed protection.

Trap Using an empty EDR alert queue as the deployment acceptance test for every ASR rule, although some enforced rules have no EDR alert output.

When managing Block Webshell creation for Servers in Microsoft Defender for Endpoint, leave that rule Not Configured in Group Policy and other local settings. Explicit Enabled or Disabled values can conflict with central management and prevent the rule from applying correctly. Resolve this deployment conflict by removing the competing configuration rather than setting a local value to reinforce the central policy.

Trap Using Disabled in Group Policy to hand control to Defender for Endpoint, because Disabled remains an explicit competing configuration rather than relinquishing configuration of the rule.

From September 1, 2026, Defender for Endpoint AIR no longer operates as a separate investigation experience or supports manual triggering. Its detection and response capabilities run automatically in the default antivirus protection stack; use a full antivirus scan for an on-demand endpoint investigation. This change does not remove Defender for Office 365 AIR.

Trap Launching a separate endpoint AIR investigation from an older procedure, because that experience is no longer available.

Use the Pending tab in Action center to review and approve or reject actions that still need a decision. Use History to audit completed actions, including automated responses, manual operations, live response activity, and antivirus remediation. Bulk approval or rejection requires selected actions to have the same action type.

Trap Closing an incident to approve pending remediation, which changes case status rather than authorizing an action.

Inspect Action source in Action center to distinguish manual device or email actions, automated actions, advanced hunting actions, Explorer actions, and live response operations. This lets the SOC identify the responsible workflow before changing automation settings. An action in History is not necessarily the result of AIR.

Trap Changing the device automation level for every recorded action, because manually initiated actions have a different source.

Under Defender unified RBAC, endpoint remediation uses Security operations > Security data > Response (manage). Email remediation uses the relevant email and collaboration advanced-actions permission when that workload's unified RBAC is active. In the documented legacy email permissions path, Security Administrator must be combined with Search and Purge for remediation.

Trap Granting read-only security data access to an approver, which allows inspection without the required response permission.

The Defender XDR investigation process assesses evidence as Malicious, Suspicious, or No threats found, then identifies whether remediation is needed. Alert eligibility and workload configuration determine whether an investigation starts; its evidence findings determine whether response work follows. For Defender for Office 365 Plan 2, an investigation can close when no threats are found or the affected messages were already remediated. Therefore, a completed investigation with no new action is not by itself evidence of failed automation.

Trap Treating every completed investigation without a quarantine operation as an automation failure, despite clean evidence or messages already remediated.

For Defender for Endpoint's Semi - require approval for all folders level, pending remediation actions time out after seven days. A timed-out action behaves as though it was rejected, not approved. Arrange review within that window when remediation needs authorization; leaving the request unanswered does not provide eventual automatic execution.

Trap Assuming an unattended approval queue provides delayed automatic remediation, because expiration takes the rejection path rather than granting authorization.

Deploy the Defender products needed for the attack scenarios and response actions you expect to use. A detection that relies on Cloud Apps signals needs that product, while endpoint containment requires Defender for Endpoint. Automatic Contain device also requires device discovery to use Standard discovery.

Trap Treating the XDR license alone as sufficient to execute every response action, because the corresponding products must be deployed.

Automatic attack disruption can trigger without manual approval when a device group's remediation setting is Semi automation. Full remediation is recommended; No automated response excludes the group from automated containment. Do not interpret the approval behavior of conventional remediation as an approval gate for disruption.

Trap Selecting Semi automation to require approval before containment, because attack disruption can still act immediately.

Attack disruption can operate independently of the device's Defender Antivirus operating state. Active, Passive, and EDR Block Mode are supported states for this capability. Other controls such as ASR have different antivirus prerequisites and must be evaluated separately.

Trap Applying ASR's active-antivirus requirement to attack disruption, because their prerequisites differ.

Configure required domain-controller audit events and validate Defender for Identity action-account permissions before relying on on-premises account disablement. By default, the sensor impersonates the domain controller's LocalSystem account; changed action-account configuration must retain the needed rights. Check that other account-enablement automation will not undo disruption during an attack.

Trap Assuming a detected identity compromise proves the sensor can disable the account, because detection and remediation permissions are separate.

For Defender for Office 365 attack disruption, mailboxes must be hosted in Exchange Online. At minimum, audit MailItemsAccessed, UpdateInboxRules, MoveToDeletedItems, SoftDelete, and HardDelete. These signals support visibility into mailbox access and attacker-driven changes.

Connect Defender for Cloud Apps to Microsoft 365 and select all required connector options, including Microsoft Entra ID apps. Partial selection can degrade disruption and app governance functionality or cause operations to fail. A connector that exists but omits required data is not equivalent to complete integration.

Trap Enabling only Exchange activity collection, which omits other required Microsoft 365 connector options.

Automatic attack disruption correlates signals across Defender workloads into a high-confidence incident, identifies attacker-controlled assets, and automatically contains them while the attack is progressing. Its decision evaluates the attack as a whole rather than matching a single indicator of compromise. Choose this built-in capability for coordinated containment without authoring a Sentinel playbook; a playbook is appropriate when you need to define your own response workflow.

Trap Reaching for a single file-hash block to obtain incident-wide containment, although the hash decision addresses only matching file content.

For an approved critical-account exception, use Settings > Microsoft Defender XDR > Automated response > Identities > Add user exclusion; use Devices > Policy application > Exclude IP for an address, range, or subnet containment exception. These targeted exclusions reduce protection for the selected assets without disabling automated response for an entire device group. If an isolated workstation merely needs access to a particular process or destination, configure selective isolation exclusions instead. A traffic exception preserves the permitted communication during isolation, whereas an attack-disruption exclusion prevents the selected automatic response.

Trap Using an attack-disruption asset exclusion to preserve one management connection, thereby removing automatic response protection instead of only permitting the necessary traffic.

Validate the endpoint Sense Agent version before relying on Contain user: the minimum supported version is 10.8470. Read MsSenseDllVersion under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status to confirm the installed sensor version. Successful onboarding alone does not establish compatibility with this response action.

Trap Checking only the antivirus operating mode when Contain user fails, although the action also requires a compatible Sense sensor.

Automatic device isolation in attack disruption is limited to end-user workstations onboarded to and managed by Defender for Endpoint. An unmanaged asset is not eligible for this isolation action, even when attack disruption can contain it. Contain device instead enforces restrictions through onboarded endpoints that block communication from the suspicious asset, so its coverage does not require installing a sensor on that asset.

Trap Assuming a discovered unmanaged workstation can receive automatic isolation because Contain device covers it, confusing peer-enforced restrictions with management of the target workstation.

Contain user applies a Defender for Endpoint containment policy across onboarded devices to block communication from the compromised identity. Its enforcement limits authentication-based access, file system access, and network communication at those endpoints. Disable user instead acts on the account in its identity service, so endpoint containment is not evidence that the directory account has been disabled.

Trap Assuming a Contain user action proves directory-wide account disablement, because the action enforces restrictions through endpoint policies rather than changing the account's enabled state.

For a cloud-native account, attack disruption executes disablement in Microsoft Entra ID through a Microsoft-managed enterprise application. Disabling an Entra account does not depend on deploying Defender for Identity. For a synchronized identity, disruption can disable both the Active Directory account through sensor-equipped domain controllers and its Entra counterpart; a purely on-premises account uses the domain-controller path.

Trap Requiring a domain-controller sensor before protecting cloud-native accounts, incorrectly extending the Active Directory execution dependency to the enterprise-application path.

The eligible roles for configuring automatic attack disruption include Security Operator, Security Administrator, Global Administrator, User Administrator, Authentication Administrator, Privileged Authentication Administrator, Directory Writers, and Helpdesk Administrator. The documented device-group automation procedure instead requires Global Administrator or Security Administrator. Select authorization for the specific configuration operation rather than treating eligibility for general disruption setup as permission to change device remediation levels.

Trap Using Security Operator alone to change device-group automation settings, confusing general disruption eligibility with the administrator requirement for that procedure.

Device groups match on device name, domain, tags, and OS platform. When several groups match, only the highest-ranked group applies; rank 1 has the highest priority. Use ranking deliberately because the selected group determines scoped access and its remediation setting.

Trap Combining remediation levels from every matching device group, because membership resolves to a single highest-ranked group.

A device must match all specified property conditions in a group definition. Within a property such as tag, device name, or domain, multiple values are alternatives joined with OR. Each of those properties supports up to 10 values, allowing a group to cover several naming patterns without relaxing its other conditions.

Trap Treating an OS condition and a tag condition as alternatives, which admits devices that fail one of the required properties.

Assign Microsoft Entra user groups with RBAC roles to control which analysts can access a device group. If no Entra groups are assigned, the device group remains accessible to all users with portal access. Device grouping and analyst role assignment therefore need to be configured together.

Trap Leaving the user-access list empty to deny access, because the default exposes the group to portal users.

Devices that match no custom device group enter Ungrouped devices (default). You cannot delete or rerank this fallback group, but you can change its remediation level and assigned Entra user groups. Review it so that new or incorrectly tagged devices do not inherit unintended access or automation settings.

Trap Deleting the default group to enforce explicit grouping, because the fallback group cannot be removed.

Deleting a device group removes that group from email notification rules that reference it. If it is the only group in a notification rule, the notification rule is deleted as well. Review notification dependencies before reorganizing group membership or retiring a group.

Trap Assuming a notification rule automatically falls back to all devices after its sole group is deleted, because the rule itself is removed.

For remediation governed by the device-group automation level, Full remediates malicious artifacts automatically, whereas Semi - require approval for all folders requires approval for every file remediation. Semi - require approval for core folders gates operating-system locations such as the Windows directory but allows automatic remediation elsewhere. Semi - require approval for non-temp folders allows automatic remediation in temporary locations and requires approval outside them. These are remediation approval settings, not a way to restore the separate manually triggered endpoint AIR experience that Microsoft discontinued on September 1, 2026.

Trap Selecting the core-folders approval level when every file remediation needs approval, leaving noncore files eligible for automatic remediation.

Use an automation rule to assign incident owners, change status or severity, add tags or tasks, and close expected incidents. Use a playbook when richer branching or interactions with external systems exceed the available built-in actions. One automation rule can apply to multiple analytics rules.

Trap Building a Logic App solely to assign an incident owner, which adds a workflow where an automation-rule action suffices.

Choose When incident is created for initial triage and When incident is updated for changes such as ownership, severity, tags, or added alerts. When alert is created can respond to supported Sentinel analytics alerts even if they have no incident. A creation trigger does not rerun merely because an existing incident receives an update.

Trap Using only an incident-created trigger for escalation on a later severity change, which is an update event.

Automation rule ordering matters because conditions are evaluated when each rule runs. If an earlier rule changes status or tags, a later rule sees those updated values. Sequence dependent rules deliberately rather than assuming every rule evaluates the original incident snapshot.

Trap Placing a tag-dependent routing rule before the rule that adds the tag, which evaluates the condition before the tag exists.

Use Updated by on incident-update automation to distinguish user, application, playbook, automation-rule, and other supported update sources. Combine it with changed, changed from, changed to, or added conditions when a specific transition should trigger work. Excluding automation-generated updates helps prevent repeated reactions to the workflow's own changes.

Trap Testing only that severity equals High for every update, which also matches unrelated updates while severity remains High.

Create an automation rule from a recurring incident to prepopulate its analytics rule and entity conditions and propose a closing action. Set an expiration date for temporary suppression, such as a scheduled security test. Narrow conditions retain coverage for unrelated incidents generated by the same detection.

Trap Disabling the analytics rule for a narrow maintenance exception, which stops detection for all activity covered by that rule.

Pair incident-created or incident-updated automation rules with incident-trigger playbooks, and alert-created automation rules with alert-trigger playbooks. The trigger determines the input schema, so an available workflow is not interchangeable merely because its actions are suitable. Alert-created automation conditions select the analytics rules to which automation applies; they do not offer the incident and entity property conditions available for incident-triggered rules.

Trap Reaching for an alert-created rule to filter directly on incident ownership, which is outside that trigger's analytics-rule-only condition set.

Each automation trigger type has its own order queue, and equal order numbers within a trigger type are resolved randomly. When creation automation causes incident updates, applicable creation rules finish before the resulting update-trigger rules run. A playbook lasting more than two minutes does not block the next action beyond two minutes after its start. Use distinct order numbers for deterministic rule sequencing, but do not treat those numbers as a completion dependency for a long-running workflow.

Trap Assuming a later closing action waits for a lengthy enrichment playbook because it appears second, despite the two-minute advancement boundary.

Any individual tag evaluates true when at least one tag satisfies the condition, including a negative condition. For an incident tagged Protected and Routine, Any individual tag does not contain Protected succeeds because Routine satisfies it. Use Collection of all tags does not contain Protected when the presence of that tag anywhere must exclude the incident from automation.

Trap Using Any individual tag does not contain Protected to safeguard protected incidents, allowing another ordinary tag to satisfy the condition and run the action.

After a workspace is onboarded to the Defender portal, multiple changes to an incident within a 5-to-10-minute period can be sent to Sentinel as one update containing only the most recent change. Intermediate updates are lost rather than delivered later as separate triggers. Design update-driven workflows without assuming that every transient status or ownership transition will reach the Sentinel rule.

Trap Using a transient incident status as a guaranteed handoff trigger after Defender onboarding, although consolidation can discard that transition before Sentinel receives an update.

Export Sentinel automation rules as Azure Resource Manager template JSON to preserve their configured parameters as deployable code. The exported file is workspace-independent and can be imported into another workspace or tenant. Version-control and review this definition for repeatable deployments instead of manually recreating the same conditions and actions in each workspace.

Trap Using a Logic Apps workflow export to replicate the surrounding automation rule, although that workflow definition does not supply the Sentinel rule's trigger conditions and ordering.

Use a playbook for multi-step enrichment, external ticket synchronization, notifications, or response across services. A playbook is an Azure Logic Apps resource and can incur Logic Apps charges beyond Sentinel ingestion costs. A template must be deployed and configured before it becomes an active workflow.

Trap Treating a Content hub playbook template as an already running response workflow, because it still needs deployment and configuration.

Use the Microsoft Sentinel incident trigger for workflows invoked on incident creation or updates and for incident-level manual response. Its payload includes incident properties, an alerts array, entities, and workspace information. Selecting an alert property can create a For each loop because an incident can contain several alerts.

Trap Using an entity-only trigger for a workflow that requires the complete incident and all its alerts, because its payload is scoped differently.

Update Incident and Add comments to incident use the Incident ARM ID to identify the target. In a workflow starting with an alert, use Alert - Get Incident to retrieve the incident and its ARM ID first. An alert ID is not interchangeable with the incident resource identifier.

Trap Passing the alert ID into Update Incident, which expects an incident resource identifier.

Use Entities - Get IPs, Hosts, Accounts, URLs, or FileHashes to filter the Entities array and expose type-specific fields. The result is still an array, so process each entity as needed. For other entity types, combine Filter array with Parse JSON.

Trap Treating the incident Entities value as a single IP object, because it contains multiple heterogeneous JSON entities.

Grant the Microsoft Sentinel service account Microsoft Sentinel Automation Contributor on the resource group containing the playbooks. This authorizes Sentinel to invoke workflows in that group independently of the analyst's own roles. The role is intended for the Sentinel service, not as a general user-authoring role.

Trap Granting Logic App Contributor only to the analyst, which does not give the Sentinel service permission to invoke the playbook.

Consumption uses multitenant Logic Apps, whereas Standard supports single-tenant hosting and multiple workflows; Sentinel Standard playbooks must use stateful workflows. For Standard, choose Logic Apps Standard Operator to enable, disable, or resubmit workflows, Standard Developer to create and edit them, or Standard Contributor for full management. These hosting roles do not replace Sentinel invocation authorization or the independent authorization of each API connection inside the workflow. For example, a Sentinel connection authenticated as Reader can use triggers and read actions, but updating an incident requires Responder or Contributor on the target workspace.

Trap Assigning Standard Developer to the workflow author to fix a Reader-authenticated connection's failed incident update, which executes under the connection identity instead.

For cross-workspace or Azure Lighthouse multitenant automation, define Sentinel's execution permissions where the playbook resides, not merely where the automation rule is stored. If an MSSP signed into its managing tenant configures a customer-workspace rule to run a customer-tenant playbook, Sentinel needs execution permissions in both tenants. In addition to the customer-side grant, add Lighthouse delegation for the managing tenant's Azure Security Insights application with Microsoft Sentinel Automation Contributor on the playbook resource group.

Trap Assuming delegated analyst access to a customer workspace also delegates the managing tenant's Sentinel service invocation rights, leaving the Azure Security Insights application unauthorized.

The person granting Sentinel its playbook execution permission needs Owner or User Access Administrator authority at the relevant scope. Logic App Contributor can edit and manage a Consumption workflow but cannot grant that access. When an author cannot authorize Sentinel to invoke the workflow, have an authorized access administrator perform the role assignment rather than expanding the workflow's actions or connections.

Trap Assigning Logic App Contributor to solve a failed Sentinel execution-role grant, although workflow management permission does not include role-assignment authority.

When a newer version of a playbook template is published, active playbooks created from it receive an additional label in the Active playbooks tab indicating an available update. Treat the label as a maintenance signal to review the deployed workflow against the new template. Publication of the template revision is not evidence that the running playbook has adopted its changes.

Trap Closing a playbook maintenance task solely because its template was updated in the content catalog, mistaking an update-available label for an applied workflow revision.

Assign Microsoft Sentinel Reader for viewing data, incidents, workbooks, and recommendations without incident changes. Assign Microsoft Sentinel Responder when the analyst must also manage incidents. Responder does not grant analytics-rule authoring or playbook execution by itself.

Trap Assigning Contributor to an analyst who only needs incident management, which also permits security-content changes.

Use Microsoft Sentinel Contributor for creating or editing analytics rules and other Sentinel resources and for installing or updating Content hub solutions. It includes incident-management permissions but does not itself grant Logic App authoring. Assign separate workflow permissions when the same engineer also maintains playbooks.

Trap Using Sentinel Responder for analytics-rule editing, because that role stops at incident management.

Microsoft recommends assigning Sentinel roles at the resource group containing the workspace so related resources are included. If assigning directly to the workspace, also assign the necessary role to its SecurityInsights solution resource and any other required resources. Workspace-only assignment can leave gaps in access to the overall solution.

Trap Assuming workspace scope automatically includes sibling Logic App resources, which are separate Azure resources.

Azure role assignments are cumulative. Giving a user Microsoft Sentinel Reader does not remove write permissions already granted through Contributor or another applicable role. Review all inherited and direct assignments when enforcing least privilege.

Trap Adding Reader as a restrictive override for an existing Contributor assignment, because Azure RBAC combines granted permissions.

A guest analyst assigning Sentinel incidents needs the Microsoft Entra Directory Readers role in addition to Microsoft Sentinel Responder. Responder supplies incident-management access, while the directory role supplies the identity lookup required for assignment. Grant the directory permission rather than escalating workspace access to Sentinel Contributor merely to resolve guest assignment failures.

Trap Upgrading a guest to Sentinel Contributor to fix assignee lookup, which broadens SIEM administration without supplying Microsoft Entra directory-reading permission.

Microsoft Sentinel Playbook Operator is the role for listing, viewing, and manually running playbooks. Its capabilities exclude creating or editing the workflows, so distinguish an operator's duties from a workflow author's duties when selecting roles. This user-facing capability is separate from the Sentinel service's Automation Contributor authorization and does not establish that all prerequisites for a particular execution are satisfied.

Trap Choosing Playbook Operator for an analyst who must modify response steps, because permission to invoke an existing workflow does not include workflow-definition edits.

Microsoft Sentinel SIEM uses Azure RBAC, while data lake access also supports Microsoft Entra roles and Defender unified RBAC. Entra Security Reader can provide read access across data lake workspaces, whereas workspace-scoped Azure roles can restrict access to particular workspaces. Do not assume a tenant-wide role and a workspace role have the same scope.

Trap Granting a tenant-wide Entra role for a single-workspace access requirement, which broadens the accessible lake content.

Use table-level RBAC or resource-context RBAC when a team should see only selected data rather than every table in a workspace. A broad workspace read role is appropriate only when the team may query the workspace as a whole. Match the access model to the actual data boundary.

Trap Using a workbook filter as an access boundary, because a display filter does not restrict direct data queries.

A user with a lesser Sentinel role can create or delete workbooks when also assigned Workbook Contributor. Workbook resources and the data they query have separate access requirements. This supports dashboard authors who should not modify analytics rules or the wider Sentinel configuration.

Trap Granting Sentinel Contributor solely for dashboard editing, which also allows unrelated Sentinel content changes.

Creating scheduled jobs or managing jobs in the Sentinel data lake requires a supported role such as Microsoft Entra Security Operator, Security Administrator, or Global Administrator. Read-only access to query data does not by itself grant job management. Prefer Security Operator over broader administrator roles when it satisfies the task.

Trap Using Security Reader for scheduled-job management, because its access is read-only.

For workspace-scoped retention and custom-table management, grant Microsoft.OperationalInsights/workspaces/write and Microsoft.OperationalInsights/workspaces/tables/write; deleting custom tables also requires Microsoft.OperationalInsights/workspaces/tables/delete. Log Analytics Contributor is a built-in role containing these permissions. Updating system tables in the Sentinel data lake instead uses a Defender unified RBAC role with Data (manage) over the Microsoft Sentinel data collection. Query-read access and permission to manage lake jobs are not substitutes for the relevant table-configuration authorization.

Trap Using a lake job-management assignment as proof of workspace table-administration rights, although workspace configuration is checked against separate Azure RBAC operations.

The Analytics tier provides high-performance interactive queries, analytics rules, hunting, and workbooks. Choose it for tables needed by real-time security operations. Data Lake-only storage is more economical for low-touch history but does not supply the same real-time feature set.

Trap Moving an actively detected table to Data Lake-only to lower cost without changing detections, which removes its real-time analytics availability.

Analytics retention controls how long data remains in the hot, fully interactive state. Total retention controls the complete retained lifetime, including that Analytics period, with older data kept in the lake. To keep a short hot window and longer compliance history, configure both values rather than extending only Analytics retention.

Trap Treating total retention as extra time added after Analytics retention, which overstates the actual retained lifetime.

Analytics retention can be extended up to two years, while total retention can extend to 12 years in the data lake. Retaining data beyond the included periods introduces the applicable retention charges. Use the lake for a multi-year historical requirement that exceeds the Analytics maximum.

Trap Selecting Analytics-only retention for a decade-long requirement, which exceeds its supported retention period.

A change to Analytics retention takes effect immediately for existing data. If total retention remains longer, data outside the new hot window remains in the lake rather than being removed from total retention. Check detection and workbook lookback requirements before shortening the hot period.

Trap Assuming the total-retention deletion grace period also preserves hot-query access, because Analytics retention changes apply immediately.

When total retention is shortened, Microsoft waits 30 days before removing affected data. This gives administrators an opportunity to revert an accidental reduction. Increasing total retention applies to already ingested data that has not yet been removed, not to data already deleted.

Trap Increasing retention to recover data already removed, because retention changes cannot recreate deleted records.

The Defender portal can display Basic Logs tables, but their management currently remains in the Log Analytics workspace. Change the table plan to Analytics if it must be managed through Defender table management. Visibility in a portal does not imply support for editing every table type there.

Trap Trying to change a Basic Logs table's retention in Defender solely because it appears in the table list, which does not provide Basic table management.

Log Analytics permits only one plan switch per table per week, so a same-day reversal is not a safe rollback assumption. Existing records remain for their retention period without being deleted or moved by the switch. After Auxiliary-to-Analytics conversion, use a search job or the search REST API for older Auxiliary records; only newly ingested Analytics records gain interactive access. In the reverse direction, older Analytics records remain interactively accessible, but a query spanning the transition can return partial results and require separate time ranges.

Trap Assuming an Analytics upgrade makes the entire retained archive interactive, although pre-change Auxiliary records retain their separate retrieval path.

Before changing an Analytics table to Basic or Auxiliary / Lake, budget for separately billed queries, including summary-rule queries. Summary rules using resource query scope break under either destination plan, so review that dependency before switching. Basic preserves total retention but treats records older than 30 days as long-term retention; moving to Auxiliary / Lake additionally stops alerts on that table.

Trap Using ingestion savings alone to justify a Basic conversion for a resource-scoped summary pipeline, whose query scope becomes unsupported.

A table showing 30 days of Analytics retention does not mean that only 30 days of storage are included: Microsoft Sentinel solution tables can be extended to 90 days without an additional retention charge. Configure the required retention rather than treating the entitlement as evidence of the table's actual setting. Keeping eligible data hot beyond the included 90 days incurs prorated retention charges separate from ingestion charges. A lake-only ingestion choice has its own ingestion, storage, and processing costs rather than inheriting free hot-storage entitlement.

Trap Assuming the included 90-day allowance proves a table configured for 30 days already retains that much history, confusing billing entitlement with configuration.

Defender XDR hunting data is available for 30 days by default under the XDR license. This default does not automatically ingest those tables into Sentinel Analytics or Data Lake storage. Configure supported-table ingestion or extended retention explicitly when Sentinel copies are needed.

Trap Assuming every XDR hunting table is already a Sentinel workspace table, because the default XDR tier is separate.

Extending supported XDR data beyond 30 days and up to 90 days in Analytics creates Sentinel workspace tables and incurs Sentinel ingestion charges. Storage within that included 90-day period does not add a storage charge, and the data is mirrored to the lake. Free storage therefore does not mean free extended ingestion.

Trap Budgeting no additional cost because the first 90 days of storage are included, which omits Sentinel ingestion charges.

Supported XDR tables can be ingested directly into the Data Lake tier for lower-cost long-term retention. The default 30-day XDR Analytics hunting availability remains, even when the Sentinel ingestion choice is lake-only. Direct lake ingestion still incurs ingestion, storage, and processing costs.

Trap Paying for extended Analytics ingestion solely to preserve the default XDR hunting window, which remains available with lake-only ingestion.

Reset Analytics retention and total retention to the default 30 days to stop supported XDR data ingestion into Sentinel Analytics. The documented behavior also disables the corresponding connector in the Azure portal. Review dependent Sentinel detections before treating this as only a storage-cost adjustment.

Trap Resetting both values while expecting continued connector ingestion, because the reset disables that ingestion path.

Some XDR-default tables, such as the documented IdentityInfo example, can be viewed but not managed from Defender table management. Supported integrated XDR tables such as DeviceEvents can become Sentinel tables through configured ingestion or retention extension. Check the table's supported type instead of assuming all XDR tables share the same controls.

Trap Applying DeviceEvents retention procedures to every XDR-default table, because unsupported tables remain view-only.

Install the solution or standalone workbook from Content hub before using its template. Check Required data types and ingest those sources before expecting the visualizations to populate. Installing the workbook content does not connect its data sources automatically.

Trap Reinstalling a workbook to populate missing charts, which does not ingest its required data.

Save a workbook template to create an editable Azure resource, then open View saved workbook to customize it. The chosen save location stores the workbook's JSON definition, not copies of the log records. Log data continues to reside in the queried workspaces.

Trap Choosing the workbook save region to relocate log data, because only the workbook definition is stored there.

For a log-query workbook component, set Data source to Logs and Resource type to Log Analytics, then select one or more workspaces. Add text, queries, and parameters to build interactive analysis rather than a static screenshot. The selected workspaces determine which logs the component queries.

Trap Changing only the workbook's resource group to change its query source, because source workspaces are configured in the query component.

Use an ASIM parser as a workbook query source when the visualization should work across normalized data from different products. A query tied directly to one vendor table does not automatically cover a later replacement source. Parser-based queries separate the visualization from vendor-specific table structure.

Trap Hard-coding one vendor's raw table for a cross-vendor dashboard, which prevents automatic use of other normalized sources.

Workbook auto refresh supports intervals from five minutes to one day. It is disabled by default, pauses in edit mode, and restarts its interval after manual refresh or returning to view mode. Reenable it after reopening a workbook rather than assuming it runs as a background monitoring service.

Trap Using workbook auto refresh as a persistent alerting job, because it is a visualization refresh mechanism rather than an analytics rule.

Bind a query component's Time Range to the TimeRange parameter, or select Set in query and reference the parameter in its time filter. Bind the component's workspace resource selection to a resource-picker parameter when viewers should choose which workspace supplies its records. Adding a selector without these bindings leaves components using their independently configured scopes. Choose Visualization to match the result shape, such as a line chart with time and numeric columns for a trend or a categorical bar chart with category and count columns for a distribution.

Trap Adding a time picker above a chart while leaving the component's fixed time range selected, so the chart never consumes the viewer's choice.

Some Sentinel workbook visualizations can only be viewed in the Azure portal rather than the Defender portal. When encountering that rendering limitation, select Open in Azure to view the workbook there. A portal-specific visualization limitation does not itself establish a fault in the underlying log query, so changing the query is not the appropriate remedy for that condition.

Trap Using a rewritten KQL query to repair an unsupported Defender visualization, because changing returned records does not add the missing portal rendering support.

SOC data value optimization examines billable tables that ingested data during the past 30 days. It distinguishes tables used by detections, tables used only by other queries or workbooks, and unused tables. Recommendations can improve security use or reduce cost; review compliance retention needs before reducing collection.

Trap Stopping ingestion solely because a table has no analytics rule, which ignores other uses and compliance requirements.

When logs exist but detection coverage is missing, SOC optimization recommends relevant analytics templates. When detections exist without their required inputs, connect the missing data sources instead. If both are absent, install or configure the solution's data sources and detections together.

Trap Adding more rule templates when existing rules lack their source logs, which does not repair the missing telemetry.

SOC optimization does not recommend ingestion changes for a table selected for UEBA or a threat intelligence matching analytics rule. These consumers give the data security value even if ordinary scheduled-rule usage appears low. Assess those dependencies before independently changing the ingestion plan.

Trap Removing a table because no custom scheduled query uses it, which overlooks UEBA or threat intelligence consumers.

Similar-organization recommendations compare ingestion trends and industry profiles to identify missing source types. The models use organizational and system metadata rather than reading customer log contents. Recommendations are not guaranteed for every workspace and exclude custom tables, custom connectors, and shared multi-source tables such as Syslog and CommonSecurityLog.

Trap Expecting a recommendation for a custom application table, which is outside the supported comparison set.

Risk-based SOC optimization considers scenarios with operational, financial, reputational, compliance, or legal impact. It compares ingested logs and enabled detections with the controls needed for those scenarios. Use these recommendations to prioritize coverage by business risk rather than ingestion volume alone.

Use Table insights to inspect ingestion by tier, last data received, volume changes, high-volume tables, and estimated daily cost. These signals help diagnose connector failures and identify retention or tier adjustments. The view is an investigative visualization, not a billing-grade or alerting surface.

Trap Using estimated Table insights cost as the definitive billing ledger, which exceeds the view's intended accuracy and purpose.

Mark a recommendation In progress while implementing it, Complete after its recommended actions are done, or Dismiss when declining it. These status changes organize the team's work; configuration changes are performed through the linked settings or content pages. Recommendations are calculated every 24 hours, and irrelevant recommendations can complete automatically after environmental changes. Reactivate a completed or dismissed recommendation to reassess it, allowing up to an hour for recalculation.

Trap Selecting Complete to deploy a recommended detection, although that action records status rather than creating or enabling the analytics rule.

When SOC optimization recommends changing a commitment tier, compare the pricing commitment with observed ingestion-volume patterns. This billing adjustment is distinct from filtering collected events, changing a table plan, or shortening retention, and does not itself remove detection inputs. Commitment tiers are billed daily; moving to a lower tier or pay-as-you-go requires the 31-day commitment period to finish, while increasing the tier restarts that period.

Trap Shortening retention to implement a commitment-tier recommendation, which changes available history instead of the ingestion pricing agreement.

Install the relevant solution from Content hub to obtain its connectors, analytics templates, and workbooks. Then open the connector page and complete its source-specific setup and permissions. Confirm data reaches the documented tables rather than treating solution installation as proof of collection.

Trap Enabling analytics immediately after solution installation without configuring its connector, which leaves the required logs absent.

Choose Windows Security Events via AMA when Sentinel content expects the SecurityEvent table. A generic Azure Monitor Windows-event DCR can also collect the Security log, but writes it to Event. Collecting the same event IDs through the wrong stream does not satisfy a rule that queries a different table.

Trap Selecting the Security channel in a generic Windows-event DCR and assuming it populates SecurityEvent, because that route writes Event.

For on-premises servers or servers in another cloud, install and enable the Azure Arc Connected Machine agent before configuring the AMA-based connector. Azure Arc provides the resource representation used to deploy and associate AMA. AMA and the Connected Machine agent serve different purposes.

Trap Installing only the Connected Machine agent and expecting security logs, because AMA still performs log collection.

Use diagnostic settings-based connectors for supported Azure platform logs and metrics. Configure the source's categories and send them to the Log Analytics workspace enabled for Sentinel. AMA-based Windows or Linux collection addresses guest operating-system logs rather than substituting for the platform's diagnostic pipeline.

Trap Installing AMA on a VM to collect subscription activity logs, which belong to the Azure platform diagnostic path.

Deploying a data connector requires workspace read and write access plus any additional source permissions listed in that connector's prerequisites. Select a connector whose supported source and destination table schema fit the intended security content. Check its Supported by field for the maintenance and support contact because Content hub includes connectors authored by Microsoft and by other organizations.

Trap Assuming Content hub distribution guarantees Microsoft maintenance, although the connector's Supported by entry can name another provider.

On a UEBA-supported connector's details page in the Defender portal, open Advanced options and use Configure UEBA to toggle on the tables intended for behavioral analysis. This selects the connector data that UEBA should analyze in addition to configuring ingestion. A connected source and populated table alone do not establish that the table has been selected for UEBA.

Trap Using a connector's Connected status as confirmation of UEBA source selection, although the behavioral-analysis toggles are configured separately.

A data collection rule defines event sources, filtering, destination workspaces, and data flows independently of a particular VM. Associate it with selected Azure VMs or Arc-enabled servers to apply that policy. Reuse rules for equivalent requirements and separate rules for subsets needing different collection.

Trap Editing only the destination workspace when one server subset needs different events, because collection scope and filtering reside in DCR configuration.

Use the Common Windows Security event set when both sign-in and sign-out activity are required for an audit trail. Minimal includes events such as successful and failed logons but omits sign-out event 4634 to reduce volume. Minimal is therefore not a complete substitute for auditing requirements.

Trap Selecting Minimal for complete session auditing, because it omits sign-out events.

All events in Windows Security Events via AMA collects the unfiltered Security log and AppLocker channels. It does not include Application, System, or Setup merely because the option says All events. Use the appropriate Windows-event collection configuration for those other channels.

Trap Choosing All events to ingest System and Application logs, which lie outside that connector's named event set.

Use the form LogName!XPathQuery for custom Windows-event collection. For example, Security!*[System[EventID=4625]] selects failed-logon event 4625 from the Security channel. This filters collection at the source rather than discarding unwanted records after they have been ingested.

Trap Putting a KQL where clause in the XPath collection field, which expects Windows Event Log XPath syntax.

Validate an XPath selection with Get-WinEvent using -LogName and -FilterXPath, separating the channel from the XPath expression. A no-matching-events result can still indicate valid syntax, whereas an invalid-query error identifies a syntax problem. DCR XPath supports up to 20 expressions, fewer than the 23 supported by Get-WinEvent.

Trap Treating a successful local query with 23 expressions as proof of DCR compatibility, because the DCR limit is lower.

Use Windows Event Forwarding to send source events to a Windows Event Collector, with WEC enabled and running and AMA installed on that collector. The collector is the cloud-ingestion point rather than every forwarding source. If the collector is outside Azure, it also needs the Arc prerequisite for AMA deployment.

Trap Installing AMA only on a forwarding source while leaving the central WEC without an ingestion agent, which does not upload its collected events.

The Windows Forwarded Events connector writes forwarded records to WindowsEvent, even when their original channel was Security. A built-in rule querying SecurityEvent will not match those records automatically. Use direct Windows Security Events via AMA for unchanged SecurityEvent-based content, or adapt detection queries for WindowsEvent.

Trap Assuming an event's original Security channel determines its destination table, because the forwarding connector writes WindowsEvent.

Deploy appropriate ASIM WindowsEvent parsers when forwarded events must participate in normalized analytics. Query compatible parsers or adapt native queries to the WindowsEvent schema instead of merely changing a table name. Normalization addresses field differences as well as the source table.

Trap Replacing SecurityEvent with WindowsEvent in every rule without checking fields, because the schemas are not identical.

After configuring WEC and forwarding, associate the collector with the Windows Forwarded Events collection rule and choose All events or a Custom XPath selection. WEF delivery to the collector and AMA delivery to Sentinel are separate stages. Diagnose both stages when events exist locally but not in WindowsEvent.

Trap Treating a populated local forwarded-events log as proof of Sentinel ingestion, because the AMA collection stage still needs configuration.

Install AMA on a Linux machine that produces logs or on a dedicated Linux forwarder receiving logs from appliances. The host needs rsyslog or syslog-ng to receive messages and pass them to AMA. Plain Syslog records are ingested into the Syslog table.

Trap Deploying AMA directly to a network appliance that only exports Syslog, instead of using a supported Linux collector.

Configure the minimum log level separately for each Syslog facility in the DCR. Selecting LOG_ERR also includes LOG_CRIT, LOG_ALERT, and LOG_EMERG. Lower-severity messages are excluded, so verify that the selection preserves the events needed by detections.

Trap Selecting LOG_ERR while expecting informational messages from the same facility, which fall below the configured minimum severity.

Devices commonly send Syslog to TCP or UDP port 514 on the collector's daemon, although a different agreed port can be configured. AMA versions 1.28.11 and later receive daemon-forwarded messages on TCP port 28330; earlier versions use a Unix-domain socket. Check the correct hop when diagnosing delivery.

Trap Pointing appliances directly at AMA's internal port as though it were the configured Syslog daemon listener, which bypasses the intended collection hop.

When source devices send Syslog or CEF over TLS, configure rsyslog or syslog-ng for TLS reception and align source, network, and listener settings. AMA installation alone does not configure the source-to-forwarder TLS relationship. Treat transport protection and cloud-agent deployment as separate setup tasks.

Trap Assuming AMA's cloud connection encrypts the appliance-to-forwarder leg, which is controlled by the Syslog transport configuration.

After deploying AMA and associating the DCR on a Linux forwarding host, run the documented Forwarder_AMA_installer.py setup to enable reception from other machines. It configures and restarts rsyslog or syslog-ng and opens the local listening ports. Configure the appliance to send its messages to that forwarder's listener rather than its own local daemon. AMA and DCR configuration alone establish neither the remote receiver nor the appliance's forwarding destination.

Trap Recreating the DCR when the collector has no remote Syslog listener, which leaves the missing daemon receiver configuration unchanged.

Use Common Event Format via AMA when a device emits CEF security records. CEF has a standard header and extensions for fields such as addresses, users, and actions, and the connector stores parsed records in CommonSecurityLog. Plain Syslog uses the Syslog table instead.

Trap Choosing plain Syslog collection for content expecting CommonSecurityLog fields, which does not provide the same parsed destination schema.

When one collector handles both formats, assign distinct facilities to CEF and plain Syslog where the sources support it. Configure each DCR stream to collect only its intended facilities. Otherwise, a CEF message can be stored in both CommonSecurityLog and Syslog.

Trap Enabling every facility on both connectors for completeness, which can ingest the same message twice.

If the appliance cannot change facility, add an ingestion-time transformation to remove CEF messages from the Syslog stream. Check both ProcessName and SyslogMessage; starting with AMA 1.41, noncompliant vendor headers may not identify CEF reliably in ProcessName alone. Keep the corresponding CEF stream so security data is still collected once.

Trap Filtering only ProcessName for CEF on every vendor, which can miss CEF messages with nonstandard headers.

Validate CEF onboarding by sending an approved test message through the collector and querying CommonSecurityLog for the expected DeviceVendor or DeviceProduct. Messages reaching the daemon do not by themselves prove DCR selection, parsing, and cloud ingestion succeeded. Allow for the documented ingestion delay, which can be up to 20 minutes for test logs.

Trap Stopping validation after observing traffic on port 514, which verifies only arrival at the collector.

For a diagnostic settings-based connector, open the source's Diagnostic settings and enable Send to Log Analytics. Select the workspace containing Sentinel and the required log or metric categories, then save. Enabling diagnostics without selecting the correct destination does not deliver data to the intended Sentinel workspace.

Trap Sending diagnostics only to a storage account and expecting immediate Sentinel queries, because the data is not being routed to the workspace.

Use the connector's Azure Policy assignment workflow when the same diagnostic configuration should apply to a collection of supported resources. Choose the assignment scope and target Sentinel workspace. This is more scalable than manually configuring each current and future resource.

Trap Creating individual diagnostic settings for a requirement covering future resources automatically, which does not enforce onboarding at scale.

A diagnostic-settings policy assignment applies to resources added in the future. Select Create a remediation task on the assignment's Remediation tab to bring existing resources into the desired configuration as well. Policy assignment and remediation address different parts of the fleet lifecycle.

Trap Assigning the policy without remediation while expecting every existing resource to be updated immediately, which omits the backfill step.

The Azure Activity connector uses the diagnostic settings pipeline. When migrating from its legacy collection method, disconnect the existing legacy subscription connections before configuring the new path. Use the connector page's legacy-connection section rather than leaving both collection paths active.

Trap Adding the diagnostic pipeline while retaining the legacy subscription connection, contrary to the documented migration sequence.

For diagnostic settings-based connectors managed by Azure Policy, Connected status requires data ingestion within the past 14 days. With no new data for that period, the connector can show disconnected and return to connected when events arrive. Check source activity and actual table ingestion before assuming the configuration was removed.

Trap Recreating diagnostic settings solely because an idle source shows disconnected, which can reflect a lack of recent events rather than lost configuration.

Use Threat Intelligence - TAXII for feeds exposed by TAXII 2.0 or 2.1 servers. Configure the API root URL, collection ID, any required credentials, indicator selection, and polling frequency. STIX is the threat-data representation, while TAXII supplies the exchange protocol.

Trap Providing only a TAXII discovery URL as the collection configuration, which does not identify the API root and collection.

Use the Threat Intelligence upload API when a custom application or threat intelligence platform pushes STIX objects to Sentinel. It does not require a separate data connector, and its Microsoft Entra application needs Microsoft Sentinel Contributor on the target workspace. This differs from Sentinel polling a TAXII server.

Trap Deploying a TAXII server just to use the upload API, which accepts direct REST ingestion instead of polling a feed.

Query ThreatIntelIndicators for Sentinel threat indicators and ThreatIntelObjects for the additional STIX object schema. Update custom analytics, hunting queries, workbooks, and automation that still depend on the legacy ThreatIntelligenceIndicator table. The newer model supports richer threat context than a flat indicator feed.

Trap Building new ingestion validation solely around the legacy ThreatIntelligenceIndicator table, which is not the current target schema.

Threat intelligence ingestion stores and curates indicators for use by Sentinel. To generate alerts from your imported indicators, enable or create analytics that match the relevant observable type against collected activity. Choose a template whose required log source and indicator type are both present.

Trap Expecting every imported IOC to generate an incident immediately, because ingestion alone is not a match against observed activity.

Prefer the Threat Intelligence upload API for new integrations requiring STIX objects beyond indicators. The legacy Threat Intelligence Platform connector uses the Microsoft Graph Security tiIndicators API, is indicator-only, and is on the documented deprecation path. A richer object model requires more than continuing the old indicator feed.

Trap Choosing the legacy tiIndicators integration for threat-actor and relationship objects, which its indicator-only model does not support.

Threat-intelligence ingestion rules filter or enrich objects arriving through data connectors, not objects submitted through the upload API or created manually. Incoming objects pass through the rules in order until a Delete action removes the object from the ingestion pipeline. Delete skips that incoming object without removing any previously stored versions; an object receiving no action is ingested unchanged. New or edited rules can take up to 15 minutes to take effect.

Trap Using an ingestion-rule Delete action to purge an already stored indicator, although the action discards only the incoming pipeline object.

Use the standard Defender Threat Intelligence connector for public indicators and open-source intelligence, or the premium connector for Microsoft's curated indicators and Microsoft-enriched OSINT. These connectors make the acquired intelligence available for your own monitoring and hunting. The freely available Defender Threat Intelligence matching analytics path ingests only indicators that match its rule, so it is not a complete feed-import alternative.

Trap Choosing managed matching analytics to populate a full Microsoft indicator inventory for unrelated hunts, although nonmatching indicators are not ingested through that path.

Creating, updating, or deleting an indicator appends an entry to Sentinel's threat-intelligence tables rather than replacing its previous row. The management interface selects the newest TimeGenerated value for each Id, while Sentinel reingests intelligence every seven to ten days. When validating the active inventory, resolve each identifier to its latest version and evaluate its lifecycle state instead of counting raw rows as distinct active indicators.

Trap Using count() over the raw indicator table as the active inventory, which includes historical revisions and periodically reingested copies.

Use Microsoft Sentinel's relationship builder to connect a threat actor object to an attack pattern object with the Uses relationship type. This records the connection between the actor and the attack technique. Use free-form tags to group threat intelligence objects for retrieval, such as objects associated with an incident, rather than as a substitute for this typed relationship.

Trap Using an attack-technique tag instead of a Uses relationship, because a retrieval label does not establish the typed connection between the threat actor and attack pattern objects.

Preserve a threat intelligence object's Traffic Light Protocol (TLP) sensitivity marking when deciding who may receive it. In Sentinel's documented markings, Green permits sharing within the community but not publicly, while Red confines disclosure to the specific group or meeting where the information was originally disclosed. Set TLP when creating or editing the object; upload API submissions express the marking through object_marking_refs. This is a disclosure restriction, distinct from a retrieval tag or an attribution relationship.

Trap Using a partner-community distribution list for Red-marked intelligence, because community sharing extends beyond the original disclosure group.

Use Microsoft Sentinel's threat-intelligence management interface to capture intelligence discovered during local investigations without building a feed integration. Select Add new > TI object, choose the object type, complete the required fields, and select Add. This manual entry route suits individual analyst-curated objects when there is no external feed to poll or application submitting them.

Trap Deploying a TAXII connector for an analyst's standalone finding, introducing a server-and-collection dependency where direct TI object entry is sufficient.

Inspect GeoLocation and WhoIs enrichments for imported IP and domain indicators to add infrastructure context to an investigation. GeoLocation can identify an IP's organization and country or region, while WhoIs can supply a domain's registrar and record creation information. These attributes describe the observable; they do not establish that your environment communicated with it or that a malicious match occurred.

Trap Treating a domain's registration information as evidence of local malicious traffic, substituting descriptive enrichment for an observed activity match.

Custom Log Analytics table names end in _CL. The Azure portal appends it automatically during creation, but API or command-line creation must supply it explicitly. The DCR output table reference must match the actual workspace table name.

Include TimeGenerated as a datetime column in a custom table's output schema. If the sample does not include it, the portal adds it through the table's DCR transformation. Map an appropriate source timestamp when available so time-based analysis reflects the intended event time.

Trap Keeping only a string timestamp column from the source, which does not satisfy the required TimeGenerated datetime field.

Use a DCR transformation to filter or reshape incoming records into the destination table schema. The transformation is a KQL query evaluated on the incoming data, and its output is what Azure Monitor stores. A query-time function changes how data is read, not what was ingested.

Trap Creating a saved query to remove sensitive fields from stored data, which only changes query output and leaves ingested records intact.

When adding or changing custom columns, update the DCRs that send data to the table so their output matches the new schema. The source sample, transformation output, and destination definition form one ingestion contract. Editing only the table does not rewrite upstream transformations.

Trap Adding a destination column and assuming every sender will populate it automatically, because DCR output mappings are separate.

Custom table creation offers Analytics by default, with Basic and Auxiliary / Lake alternatives where supported. Choose the plan based on the required query and real-time security features, not merely the incoming JSON format. A cheaper storage plan is unsuitable if its feature limitations conflict with the table's intended detections.

In the workspace Tables creation workflow, supply representative JSON, select or create the DCR, and use Run in the Transformation editor to preview results before Apply and Create. For an API-defined DCR, streamDeclarations defines incoming columns, destinations.logAnalytics names the workspace destination, and dataFlows connects the input stream, transformKql, destination name, and outputStream. The outputStream identifies the destination table, while the sender targets the input stream. After creating these resources, configure an authorized application or agent to send data; saving the table does not initiate ingestion.

Trap Waiting for records immediately after table creation, although no sender has been configured to submit data to the declared input stream.

Custom table column names must start with an ASCII letter and use only letters, digits, or underscores afterward; spaces, dots, and dashes are invalid. Quoting an unusual name in KQL does not make that name valid in the destination schema. Auxiliary ingestion also drops data for duplicate column names distinguished only by case, so rename case-colliding output fields instead of relying on the case-sensitive naming supported by Analytics and Basic tables.

Trap Using quoted Kusto identifiers to preserve dotted source-field names as custom columns, although query quoting cannot relax the ingestion schema's naming restrictions.

With az monitor log-analytics workspace table update, the --columns argument specifies the replacement custom-column set. Include every existing custom column that must survive along with the new column; omitted custom columns are deleted. Treat the command as a complete schema change rather than an incremental add operation.

Trap Supplying only the new field to --columns during a schema extension, causing the previously defined custom fields to be omitted from the replacement set.

Azure built-in tables cannot be deleted from a Log Analytics workspace. Within those tables, schema editing can add or remove custom columns, not remove the predefined columns supplied by Azure. Use a custom table when the required destination schema must differ from the built-in definition rather than attempting to dismantle that definition.

Trap Using table deletion to retire an unwanted Azure built-in schema, although the table-management API does not permit deleting that table type.

When extending an Azure built-in table in Log Analytics, end each custom column name with _CF. For example, name an added classification field Classification_CF rather than Classification. Apply this suffix to the added field's schema name; it identifies a custom column within the Azure table.

Trap Using Classification_CL for an added field in an Azure table, because the custom-table naming convention does not satisfy the _CF requirement for custom columns.

Create the data collection rule with kind set to Direct to generate its own logsIngestion endpoint for Logs Ingestion API delivery. Retrieve that endpoint from the DCR's JSON view and use it as the sender's ingestion endpoint. A separate data collection endpoint is required when using private link or a DCR that lacks a logs ingestion endpoint; it is not mandatory for every custom-table API route.

Trap Reaching for the workspace resource ID as the HTTP ingestion destination, confusing the storage resource identifier with the DCR or DCE delivery endpoint.

Set the custom-table ingestion DCR's location to the region of the destination Log Analytics workspace. If the route uses a separate data collection endpoint, that endpoint must share the region too. Choose the destination workspace's region rather than the sending application's location when deploying these ingestion resources.

Trap Placing the DCR near a remote sender to reduce latency, breaking the required regional alignment with the destination workspace.

For Auxiliary / Lake table ingestion, represent TimeGenerated in ISO 8601 format with six decimal places for microsecond precision. Validate timestamp serialization against this plan-specific requirement rather than relying on the broader set of datetime representations supported by Kusto. Declaring a datetime column alone does not establish that an incoming timestamp uses the required format.

Trap Using a locale-formatted timestamp accepted by a general datetime parser, overlooking the Auxiliary / Lake ingestion format restriction.

Check custom column names against the system and reserved-name list, which includes TenantId, Type, and _ResourceId. A source field named Type must be mapped to a nonreserved custom name, such as SourceType, rather than reused unchanged. Valid characters and any required suffix are separate checks and do not authorize a reserved-name collision.

Trap Preserving a vendor's Type field as a custom column because it contains only letters, colliding with a platform-reserved name despite passing lexical validation.