2.2. Ingest Data into Microsoft Sentinel

💡 First Principle: A detection can only see data that arrives, and data arrives only through a defined pipe: a source, a collection mechanism, a rule describing what to collect, and a destination table. Every ingestion question on the exam is a question about one of those four parts. When something isn't showing up, walk the pipe from source to table.

What breaks without this discipline is the silent blind spot. A domain controller that never got a data collection rule, a firewall sending to the wrong syslog facility, an Azure subscription created after the activity-log setting was configured: each leaves the SOC confident and blind. Ingestion is also where cost is decided, so the right answer usually collects exactly what detection and investigation need, and no more.

Think of ingestion as plumbing. Sources are buildings that produce water (logs). Connectors are the type of pipe: some are built-in service mains (service-to-service connectors for Microsoft clouds), some need a pump installed on site (the Azure Monitor Agent, AMA), and some need a collection tank first (a Windows Event Collector, a Linux syslog forwarder). The data collection rule (DCR) is the valve and filter that decides what flows and where to. The destination table is the tank in the workspace.

⚠️ Common Misconception: "The legacy Log Analytics agent is still a valid way to collect security events." The Log Analytics agent (MMA, also called OMS) was retired in August 2024. Current collection uses AMA with DCRs. Exam options that install MMA or reference "legacy agent" connectors are distractors. Two related traps follow in this section: CEF appliances can't send directly into Sentinel (they need a Linux forwarder), and Windows Event Forwarding data lands in a different table than per-host security event collection.