7.2 Data Connectors and Security Signals

Connectors Are the Front Door

A data connector is the mechanism by which Microsoft Sentinel ingests security signals so they land in the underlying Log Analytics workspace. Connectors are the first step in the Sentinel workflow: analytics rules, incidents, workbooks, hunting queries, and playbooks all operate on the data that connectors bring in. If a scenario says an organization wants to collect security signals to detect and investigate threats, the Sentinel answer begins with connectors.

Microsoft provides hundreds of out-of-the-box connectors, and the exam expects you to recognize the broad categories rather than memorize any one setup. The data lands in tables in the workspace and becomes queryable with Kusto Query Language (KQL).

Many connectors are delivered as content solutions from the Sentinel Content Hub. Installing one of these often deploys not just the ingestion path but also matched analytics rules, workbooks, and hunting queries tuned for that source. For SC-900 the key idea is simply that connectors are packaged on-ramps for getting the right data in.

Because Sentinel bills largely on data ingested and retained, connectors are also where data-cost decisions begin in the real world. The exam will not ask for pricing math, but it may describe an organization wanting to control which sources flow in — that is still a connector concept.

The Dependency Chain and Product Cues

Think of Sentinel as a pipeline that starts with connectors:

• Connect — data connectors ingest signals into the Log Analytics workspace.
• Detect — analytics rules evaluate that data and raise incidents.
• Investigate — incidents and hunting work the data.
• Visualize — workbooks chart trends from the data.
• Respond — automation rules and playbooks act on incidents.

The practical consequence: no connected data means analytics, hunting, and workbooks have less to work with. A scenario that says "the team enabled an analytics rule but it never fires" frequently means the relevant data source is not connected. That cause-and-effect is a fair fundamentals-level inference.

Use connector wording to anchor product selection, but do not stop there. The prompt may move on to detection or response, yet the entry cue is the need to feed signals into a SIEM:

The exam may not use the word connector at all. It may describe a company whose security signals live in several systems and that wants a Microsoft solution to centralize them for analysis — that is still the Sentinel connector idea. Keep compliance (Purview) and identity governance (Entra) scenarios out of this lane: connectors carry security telemetry for detection and response, not retention labels or access reviews.

Why Connectors Define Sentinel's Value

The range of connectors is precisely what lets Sentinel act as a single pane of glass and what most clearly separates it from Microsoft Defender XDR. Defender XDR correlates signals only across Microsoft workloads — endpoints, identities, email, and cloud apps — with little configuration because the sources are built in. Sentinel deliberately reaches further: its connector catalog includes AWS, Google Cloud, dozens of firewall and proxy vendors, network appliances, SaaS platforms, identity providers, and custom applications, in addition to all of the Microsoft sources.

When a scenario stresses non-Microsoft or mixed-vendor sources, that breadth is the signal to choose Sentinel rather than a single Defender product.

Ask three questions about the source. Is it a supported cloud service? Look for a native service-to-service connector and its permissions, licensing, and configuration prerequisites. Is it a server or virtual machine producing operating-system logs? An Azure Monitor Agent connector and data collection rule may fit. Is it a network appliance, third-party service, or custom application? Check whether the source exposes Syslog, Common Event Format, or an API; use the documented connector or supported custom-ingestion method. These are selection clues, not guarantees that every product uses the same ingestion path.

For SC-900 you will not configure any of these. The durable takeaways are that connectors are the on-ramp that makes Sentinel's broad visibility possible, that they come in native, agent-based, and standards-based varieties, that many arrive as packaged solutions bundling rules, workbooks, and hunting queries, and that every downstream Sentinel feature depends on the data they bring in. Recognizing connectors as the first and enabling step lets you answer both "which product" and "why did detection not fire" questions correctly.