This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage and monitor security posture (20–25%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Configure and use Microsoft data connectors for Azure resources

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

Microsoft Sentinel is only as useful as the security data it can collect and analyze.

A security operations team may have Azure resources generating valuable activity, diagnostic, security, and operational data, but that information does not automatically become available to Microsoft Sentinel. The organization must establish the appropriate data connector and configure the underlying data source.

For the SC-500 exam, understanding Microsoft Sentinel data connectors involves several related concepts:

• What a data connector is
• How Azure resources send data to Microsoft Sentinel
• Diagnostic settings
• Azure Activity logs
• API-based connectors
• Azure Monitor Agent (AMA)
• Data Collection Rules (DCRs)
• Azure Policy-based connector deployment
• Log Analytics workspaces
• Connector permissions
• Data tables
• Verifying ingestion
• Monitoring connector health
• Controlling ingestion costs

Microsoft currently groups Microsoft Sentinel data connectors into several major connection types, including API-based connections, diagnostic settings-based connections, and Windows agent-based connections.

The key exam skill is knowing which mechanism is appropriate for a particular Azure resource or data source.

1. What Is a Microsoft Sentinel Data Connector?

A data connector is the integration mechanism that allows Microsoft Sentinel to collect data from an external source.

The source might be:

• An Azure resource
• A Microsoft service
• A Windows server
• A Linux server
• A third-party security product
• A network device
• An application
• A cloud service

Once connected, the data is generally stored in or made available through Microsoft Sentinel’s underlying data platform, allowing security teams to:

• Query the data
• Create analytics rules
• Investigate incidents
• Run hunting queries
• Build workbooks
• Correlate events
• Perform automated responses

Microsoft Sentinel provides many out-of-the-box connectors for Microsoft services and other supported sources.

The basic architecture

A simplified architecture looks like this:

Azure resource

↓

Data connector / diagnostic settings / agent

↓

Log Analytics workspace

↓

Microsoft Sentinel

↓

KQL queries, analytics rules, hunting, workbooks, incidents and automation

Understanding this flow is fundamental to the SC-500 exam.

2. Azure Resources and Microsoft Sentinel

Azure resources generate several types of information.

For example:

The exact logs and metrics available depend on the resource type.

The connector documentation identifies the relevant data types and destination tables for supported connectors.

3. The Three Major Connector Models

For SC-500, you should recognize three major categories of Sentinel data connectors:

1. API-based connectors
2. Diagnostic settings-based connectors
3. Windows agent-based connectors

Microsoft documents these as distinct connection mechanisms.

The correct choice depends on the source.

4. Diagnostic Settings-Based Connectors

Diagnostic settings are particularly important when connecting Azure resources to Microsoft Sentinel.

Azure resources can expose platform logs and metrics through Azure Monitor diagnostic settings.

A diagnostic setting specifies:

• What data to collect
• Where to send it
• Which categories to enable

For Microsoft Sentinel, the destination is commonly the Log Analytics workspace associated with Sentinel.

Basic flow

Azure resource

↓

Diagnostic setting

↓

Log Analytics workspace

↓

Microsoft Sentinel

Microsoft currently documents a standardized process for diagnostic-settings-based Sentinel connectors.

5. Configuring a Diagnostic Settings-Based Connector

A typical configuration process is:

Step 1 — Open Microsoft Sentinel

Navigate to the appropriate Sentinel workspace.

Step 2 — Open Data connectors

Find the appropriate Azure resource connector.

Step 3 — Open the connector page

Select the connector and open its configuration page.

Step 4 — Select the Azure resource

If the connector provides a list of resources, select the resource whose logs you want to ingest.

Step 5 — Open Diagnostic settings

Navigate to the resource’s Diagnostic settings.

Step 6 — Create a diagnostic setting

Select:

+ Add diagnostic setting

Step 7 — Select the destination

Enable:

Send to Log Analytics workspace

Then select the subscription and Log Analytics workspace where Microsoft Sentinel resides.

Step 8 — Select data types

Select the appropriate:

• Logs
• Metrics

Step 9 — Save

Save the diagnostic setting.

The logs can then begin flowing into the Sentinel workspace.

6. Why Diagnostic Settings Matter

A common SC-500 question might present this requirement:

An organization wants to send Azure resource logs directly to the Log Analytics workspace used by Microsoft Sentinel.

The likely mechanism is:

Azure Monitor diagnostic settings

rather than:

• Installing the Azure Monitor Agent on the resource
• Creating an API connection
• Creating a Windows event collector

This is a critical distinction.

7. Azure Activity Logs

The Azure Activity Log records subscription-level management operations in Azure.

Examples include:

• Creating a resource
• Deleting a resource
• Updating a resource
• Changing configuration
• Starting or stopping resources
• Administrative operations

For example:

An administrator deletes a Key Vault.

The Activity Log can record that management operation.

This is different from resource-specific diagnostic logs.

Important distinction

Activity Log

Primarily describes control-plane/subscription-level activity.

Resource logs

Describe operations occurring within a specific Azure resource or service.

For example:

The distinction between management-plane activity and resource-level telemetry is highly relevant to exam questions.

8. Azure Activity Connector

Microsoft Sentinel provides an Azure Activity connector.

Microsoft has transitioned the Azure Activity connector to the diagnostic-settings pipeline. Organizations still using the legacy connection method need to disconnect existing legacy subscription connections before configuring the newer diagnostic-settings-based connector.

This is an example of why understanding the current connector architecture is important.

Exam tip

If a question explicitly describes the current Azure Activity connector, pay attention to whether it is asking about:

• The older legacy connection mechanism, or
• The current diagnostic-settings-based pipeline.

9. API-Based Connectors

Not every connector uses diagnostic settings.

Some Microsoft services connect to Sentinel through an API-based connector.

The general process is:

1. Open Data connectors.
2. Select the service.
3. Open the connector page.
4. Select Connect.
5. Configure any required options.
6. Optionally enable automatic incident creation from alerts when supported.

Microsoft’s current API-based connector guidance follows this general model.

Example

Suppose the organization needs to ingest alerts from a Microsoft security service that exposes its data through a service-to-service integration.

A diagnostic setting on an Azure resource may not be appropriate.

Instead, the service’s API-based connector may be used.

10. Azure Monitor Agent

Another important connector mechanism is the Azure Monitor Agent (AMA).

AMA is used when Microsoft Sentinel needs to collect events from supported machines and other agent-based sources.

Examples include:

• Azure virtual machines
• Azure Arc-enabled servers
• Windows servers
• Linux systems
• Syslog sources
• Common Event Format (CEF) sources
• Windows Security Events

Microsoft’s current agent-based connector architecture uses Data Collection Rules (DCRs) to define what data the Azure Monitor Agent collects.

11. Data Collection Rules

A Data Collection Rule (DCR) defines how Azure Monitor Agent collects data.

A DCR can specify:

• What data is collected
• Which data sources are involved
• How the data is processed
• Which destinations receive the data

One of the major advantages of DCRs is that they can be defined independently from a particular machine and reused across multiple machines or environments.

Example

Suppose an organization has:

• 100 Azure VMs
• 50 Azure Arc-enabled servers

The organization wants to collect Windows Security Events from all of them.

Instead of manually configuring each machine independently, the security team can use:

Azure Monitor Agent + DCR + resource associations

to manage collection at scale.

12. Azure Monitor Agent Versus Diagnostic Settings

This distinction is especially important for the exam.

Exam shortcut

If the question says:

“Azure resource logs”

think:

Diagnostic settings

If the question says:

“Windows or Linux machine events”

think:

Azure Monitor Agent + DCR

13. Azure Arc and Non-Azure Servers

Azure Monitor Agent-based Sentinel connectors can also collect events from machines outside Azure.

For a system that is not an Azure VM, Azure Arc must be installed and enabled before enabling the AMA-based connector. This includes:

• Physical Windows servers
• On-premises virtual machines
• VMs in another cloud

Microsoft documents Azure Arc as a prerequisite for these non-Azure machine scenarios.

Therefore:

On-premises server

↓

Azure Arc

↓

Azure Monitor Agent

↓

Data Collection Rule

↓

Microsoft Sentinel

is a common architecture.

14. Using Azure Policy to Deploy Diagnostic Settings at Scale

Manually configuring diagnostic settings on hundreds or thousands of Azure resources is inefficient.

Microsoft Sentinel supports diagnostic-settings-based connectors that can be managed through Azure Policy.

Azure Policy can apply a diagnostic-settings configuration across a defined collection of resources of the same type.

For example:

Organization has 500 Azure Key Vaults.

Rather than configuring every Key Vault individually, an Azure Policy assignment can enforce the desired diagnostic configuration.

Conceptual architecture

Azure Policy

↓

Diagnostic settings configuration

↓

Many Azure resources

↓

Log Analytics workspace

↓

Microsoft Sentinel

15. Existing Resources Versus Future Resources

This is a particularly important Azure Policy concept.

Suppose an organization creates a policy that configures diagnostic settings.

The policy can apply to:

• Resources created in the future
• Existing resources, when remediation is configured

Microsoft’s diagnostic connector workflow provides a Remediation option that can create a remediation task for existing resources.

Exam scenario

A company has 200 existing storage accounts and wants the new diagnostic policy to configure them.

Simply assigning the policy may not be enough to immediately remediate all existing resources.

The administrator should consider:

Create a remediation task.

16. Azure Storage Connector Example

Azure Storage illustrates why understanding the resource hierarchy matters.

A storage account has child resources associated with:

• Blob
• File
• Queue
• Table

Microsoft’s current diagnostic connector guidance notes that configuring Azure Storage requires attention to both the parent storage account and the applicable child storage resources. The parent account requires the appropriate transaction metric, while the child storage types require their applicable logs and metrics.

Exam lesson

Do not assume:

“Configure the storage account”

automatically means:

“Every storage service’s logs are configured.”

Pay attention to the exact resource and child-resource requirements described in the scenario.

17. Choosing Which Logs to Collect

A major security engineering decision is determining which data should actually be collected.

Collecting everything may sound attractive, but it can create:

• Higher ingestion costs
• More noise
• More storage requirements
• More difficult investigations
• Lower signal-to-noise ratio

Microsoft recommends prioritizing data connectors and considering filtering when ingestion becomes unnecessarily expensive.

A good strategy

Collect data that provides meaningful:

• Detection value
• Investigation value
• Compliance value
• Operational value

Avoid collecting large quantities of irrelevant telemetry simply because it is available.

18. Data Connector Permissions

Permissions are an important part of connector configuration.

For diagnostic-settings-based connectors, the administrator needs appropriate access to the Sentinel Log Analytics workspace.

For standalone diagnostic-settings-based connections, Microsoft requires read/write permissions on the Log Analytics workspace enabled for Microsoft Sentinel.

For Azure Policy-managed diagnostic connections, the administrator also needs sufficient permission to create the policy assignment. Microsoft specifies Owner at the policy assignment scope for this scenario.

Exam distinction

If the question asks:

“What permission is needed to configure the Sentinel workspace connection?”

think about:

Log Analytics workspace permissions.

If it asks:

“What permission is needed to assign the Azure Policy?”

think about:

Policy assignment permissions.

19. Data Connector Installation and Content Hub

Many Sentinel data connectors are packaged as part of Sentinel solutions.

The general process is:

Content hub

↓

Install solution

↓

Data connector becomes available

↓

Open connector

↓

Configure connector

↓

Data begins flowing

Microsoft’s current connector guidance explicitly states that the related solution should be installed from Content hub when the connector is provided through a solution.

This connects the previous SC-500 topic—Content hub solutions—directly to this topic.

20. Verifying That Data Is Being Ingested

Connecting a data source is not the end of the process.

You should verify that data is actually arriving.

Useful validation techniques include:

• Checking the connector status
• Checking the Data received information
• Querying the expected Log Analytics table
• Reviewing timestamps
• Verifying the expected event types
• Checking for ingestion failures

Microsoft’s connector documentation notes that the connector page provides information about data received and connectivity status after successful configuration.

21. Querying Azure Activity Data

For example, Azure Activity data is stored in the AzureActivity table.

A simple KQL query is:

AzureActivity
| take 50

To investigate activity for a particular subscription, you could use:

AzureActivity
| where SubscriptionId == "<subscription-id>"
| order by TimeGenerated desc

This can help verify that Azure Activity data is reaching the workspace.

Microsoft’s troubleshooting guidance similarly recommends querying the AzureActivity table when validating Azure Activity ingestion.

22. Querying the Correct Table

Every connector has one or more associated destination tables.

This is another common exam scenario.

For example:

The connector shows as connected, but an analyst queries the wrong table.

The analyst may conclude incorrectly that data is not arriving.

Always determine:

1. Which connector is being used.
2. Which data types are enabled.
3. Which Log Analytics table receives that data.
4. Whether the expected records are present.

Microsoft’s data connector reference identifies the tables associated with individual connectors.

23. Connector Health Monitoring

Security teams should not assume that a connector that worked yesterday will continue working forever.

Microsoft Sentinel provides capabilities for monitoring connector health.

The data collection health monitoring workbook provides information such as:

• Overall ingestion status
• Data volume
• Events per second
• Last log received
• Data collection anomalies
• Agent information

Microsoft also provides the SentinelHealth table for supported connectors, allowing administrators to query connector health information and identify changes or failures.

Why this matters

A security control is ineffective if the underlying telemetry silently stops arriving.

For example:

Firewall connector stops collecting logs.

The firewall itself may still be protecting the network, but the SOC may lose visibility into what the firewall is seeing.

Therefore:

Connector monitoring is part of security monitoring.

24. Connector Status Is Not Always a Simple Permanent State

Some diagnostic-settings-based connectors determine their connected status based on recent ingestion.

For Azure Policy-managed diagnostic-settings-based connectors, Microsoft documents the connector as connected when data has been ingested within the previous 14 days. After 14 days without ingestion, the status changes to disconnected; when new data arrives, the connected status returns.

This means that a connector status should be interpreted in context.

A “disconnected” status does not necessarily mean the connector configuration was deleted.

It can indicate that expected data has not been received recently.

25. Data Connectors and Ingestion Costs

Every additional log source can increase the amount of data entering Sentinel.

Organizations should therefore consider:

• Which logs are necessary
• Which log categories provide security value
• Whether filtering is appropriate
• Retention requirements
• Compliance requirements
• Investigation requirements

Microsoft specifically recommends prioritizing connectors and considering log filtering when ingestion becomes too expensive.

Example

Suppose an Azure service produces:

• Detailed operational logs
• Security logs
• Debug logs
• Performance metrics

If only the security logs are needed for threat detection, sending every available category into Sentinel may unnecessarily increase ingestion volume.

26. Data Transformation

Microsoft Sentinel supports data transformation for certain ingestion architectures.

Data collected through Azure Monitor Agent or the Logs Ingestion API can use Data Collection Rules for processing and ingestion-time transformation.

Microsoft also documents workspace transformations for diagnostic-settings-based connections where supported.

This provides an additional opportunity to control and structure incoming data.

Conceptual flow

Source

↓

Connector

↓

DCR / transformation

↓

Log Analytics

↓

Microsoft Sentinel

The exact transformation capabilities depend on the connector type.

27. Common Connector Troubleshooting Sequence

When a connector isn’t producing expected data, use a structured process.

Step 1 — Verify the solution

If the connector is solution-based, confirm that the relevant Content hub solution is installed.

Step 2 — Verify permissions

Make sure the administrator has the required workspace/resource permissions.

Step 3 — Verify the connector configuration

Check:

• Correct source
• Correct subscription
• Correct workspace
• Correct authentication
• Correct configuration options

Step 4 — Verify diagnostic settings

If using a diagnostic-settings-based connector, confirm:

• Diagnostic setting exists
• Correct log categories are enabled
• Correct Log Analytics workspace is selected

Step 5 — Verify Azure Policy

If using policy-based deployment, check:

• Policy assignment exists
• Correct scope
• Correct parameters
• Compliance state
• Remediation status

Step 6 — Verify the destination table

Query the expected table.

Step 7 — Check timestamps

Make sure the query window includes the period when the data should have arrived.

Step 8 — Check connector health

Review connector status and available health information.

28. Common Mistakes to Avoid

Mistake 1: Confusing Activity Logs with Resource Logs

Azure Activity Log records management/control-plane activity.

Resource logs provide service/resource-specific telemetry.

Exam lesson: Identify what the question is asking to monitor.

Mistake 2: Using AMA for every Azure resource

AMA is not the universal mechanism for Azure resource logs.

Exam lesson: Azure resource diagnostic logs commonly use Diagnostic settings, while machine events commonly use AMA + DCR.

Mistake 3: Forgetting the Log Analytics workspace

Microsoft Sentinel relies on its associated Log Analytics workspace for traditional analytics-tier ingestion.

Exam lesson: Always identify the destination workspace.

Mistake 4: Installing a connector but not configuring it

Installing the solution does not necessarily establish the connection.

Exam lesson:

Install → Configure → Verify

Mistake 5: Assigning Azure Policy without considering existing resources

A policy can govern resources within its scope, but existing resources may require remediation.

Exam lesson: Look for the remediation task requirement.

Mistake 6: Querying the wrong table

A connector can be healthy while an analyst queries an unrelated table.

Exam lesson: Know the destination table associated with the connector/data type.

Mistake 7: Collecting every available log

More data does not necessarily mean better security.

Exam lesson: Balance security visibility with cost, relevance, and operational value.

Mistake 8: Failing to monitor connector health

A connector that stops sending data can create a significant security blind spot.

Exam lesson: Security monitoring includes monitoring the telemetry pipeline itself.

29. SC-500 Connector Decision Matrix

30. A Practical End-to-End Example

Suppose an organization has 300 Azure resources and wants to centralize security telemetry in Microsoft Sentinel.

The organization decides to collect diagnostic logs from supported Azure resources.

Architecture

300 Azure resources

↓

Azure Policy

↓

Diagnostic settings

↓

Log Analytics workspace

↓

Microsoft Sentinel

Implementation

1. Identify the Azure resource types requiring monitoring.
2. Identify the appropriate Sentinel data connectors.
3. Install required connector solutions from Content hub.
4. Open the appropriate connector configuration.
5. Determine required diagnostic log categories.
6. Create an Azure Policy assignment where centralized configuration is appropriate.
7. Select the Sentinel Log Analytics workspace as the destination.
8. Configure the desired diagnostic categories.
9. Create a remediation task for applicable existing resources.
10. Validate the configuration on existing resources.
11. Confirm new resources receive the desired configuration.
12. Query the expected Log Analytics tables.
13. Monitor connector health.
14. Adjust collection as necessary to balance security value and cost.

This is the kind of end-to-end scenario that can appear in a certification exam.

31. Key Takeaways

For SC-500, remember the following:

1. Data connectors bring data into Microsoft Sentinel.
2. Microsoft Sentinel currently uses several connector architectures, including API-based, diagnostic-settings-based, and Windows agent-based connectors.
3. Diagnostic settings are fundamental for collecting logs from Azure resources.
4. Diagnostic settings can send logs to the Log Analytics workspace used by Sentinel.
5. Azure Activity Log records subscription-level management activity.
6. Resource logs provide resource/service-specific telemetry.
7. Azure Monitor Agent (AMA) is used for supported machine-based data collection.
8. AMA uses Data Collection Rules (DCRs).
9. Non-Azure servers can use Azure Arc + AMA + DCR.
10. Azure Policy can configure diagnostic settings across resources at scale.
11. Existing resources may require a remediation task.
12. A solution may need to be installed from Content hub before its connector becomes available.
13. Installing a connector does not necessarily mean the data source is fully configured.
14. Always verify the destination Log Analytics table.
15. Use KQL to verify that data is actually arriving.
16. Monitor connector health rather than assuming ingestion continues indefinitely.
17. AzureActivity is the important table to recognize for Azure Activity data.
18. Connector status can depend on recent data ingestion.
19. Avoid collecting unnecessary logs because ingestion can increase cost and noise.
20. For exam questions, distinguish carefully between resource logs, Activity Logs, API connectors, and agent-based collection.

The most important mental model is:

Azure resource → Connector/Diagnostic setting → Log Analytics → Microsoft Sentinel → Detection/Investigation/Response

And for machine-based collection:

Machine → Azure Monitor Agent → DCR → Log Analytics → Microsoft Sentinel

Once you can identify which architecture belongs to each scenario, many SC-500 data-connector questions become substantially easier.

Practice Exam Questions

Question 1

A company wants to send diagnostic logs from an Azure resource to the Log Analytics workspace used by Microsoft Sentinel.

Which configuration should the security engineer use?

A. Azure Monitor Agent

B. Microsoft Entra Conditional Access

C. Azure Monitor diagnostic settings

D. Azure Bastion

Answer: C

Explanation:
Azure resource platform and resource logs are commonly sent to Microsoft Sentinel by configuring Azure Monitor diagnostic settings and selecting the appropriate Log Analytics workspace as the destination. AMA is primarily associated with supported machine-based collection scenarios.

Question 2

An organization needs to collect Windows Security Events from 200 Azure virtual machines and manage the collection configuration centrally.

Which solution should the organization implement?

A. Azure Monitor Agent with Data Collection Rules

B. Azure Activity Log with diagnostic settings

C. Microsoft Entra ID Protection

D. Azure Policy without Azure Monitor Agent

Answer: A

Explanation:
For supported machine-based collection such as Windows Security Events, Microsoft Sentinel uses the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs). DCRs allow collection configurations to be managed and associated with multiple machines.

Question 3

A security team needs to determine which administrator deleted an Azure virtual machine.

Which data source should the team investigate?

A. Azure Storage logs

B. Azure Activity Log

C. Windows Security Events

D. Azure Firewall logs

Answer: B

Explanation:
Deleting an Azure resource is a management-plane operation recorded in the Azure Activity Log. Resource-specific diagnostic logs are used for different types of service-level activity.

Question 4

An organization has hundreds of Azure resources of the same type. The security team wants to apply the same diagnostic-settings configuration to all existing and future resources.

What should the team use?

A. A separate diagnostic setting created manually on every resource

B. An Azure Monitor Agent installation on every resource

C. A workbook

D. Azure Policy with an appropriate diagnostic-settings policy and remediation where needed

Answer: D

Explanation:
Azure Policy can apply diagnostic-settings configurations to a collection of resources of a particular type. For applicable existing resources, a remediation task can be used to apply the policy configuration.

Question 5

A Sentinel administrator has installed a solution containing an Azure resource data connector. The connector is visible, but no data is appearing in the expected table.

What should the administrator do first?

A. Verify and configure the connector and its underlying data source

B. Delete the Sentinel workspace

C. Create a new Microsoft Entra tenant

D. Disable all Sentinel analytics rules

Answer: A

Explanation:
Installing a solution makes the connector available, but the connector may still require configuration. The administrator should verify the connector, source configuration, permissions, diagnostic settings or other required connection mechanism, and then validate ingestion.

Question 6

A security engineer wants to collect logs from an on-premises Windows server using an Azure Monitor Agent-based Sentinel connector.

What must be established before enabling the AMA-based connector?

A. Azure Bastion

B. Azure Arc

C. Azure Firewall Premium

D. Azure DDoS Protection

Answer: B

Explanation:
For supported systems that are not Azure virtual machines, the machine must have Azure Arc installed and enabled before using the Azure Monitor Agent-based connector.

Question 7

An administrator wants to verify that Azure Activity data is reaching the Log Analytics workspace.

Which table should the administrator query?

A. SecurityEvent

B. SigninLogs

C. AzureActivity

D. Heartbeat

Answer: C

Explanation:
Azure Activity data is stored in the AzureActivity table. A simple KQL query such as AzureActivity | take 50 can be used to verify that records are arriving. Microsoft’s troubleshooting guidance also uses the AzureActivity table for validating Activity Log ingestion.

Question 8

A company has assigned an Azure Policy that configures diagnostic settings for a set of Azure resources. The policy is intended to apply to resources that already exist.

What additional action may be required?

A. Install Azure Bastion

B. Create a remediation task

C. Enable Microsoft Entra ID Protection

D. Create a new Sentinel workspace

Answer: B

Explanation:
Azure Policy can govern resources within its scope, but existing resources may require a remediation task to apply the desired configuration. Microsoft’s Sentinel diagnostic connector workflow specifically provides a remediation option for this scenario.

Question 9

A security team wants to collect only security-relevant logs from an Azure service because sending every available log category would significantly increase ingestion volume and cost.

What is the best approach?

A. Enable every available log category

B. Disable Microsoft Sentinel

C. Select only the required log categories and consider appropriate filtering

D. Install Azure Arc on the Azure service

Answer: C

Explanation:
Security teams should balance visibility with ingestion cost and operational value. Microsoft recommends prioritizing data connectors and considering filtering when ingestion becomes unnecessarily expensive.

Question 10

A security operations team wants to detect when a Sentinel data connector stops receiving telemetry. Which capability should the team use?

A. Azure Resource Locks

B. Microsoft Entra Privileged Identity Management

C. Azure DDoS Protection

D. Microsoft Sentinel data collection health monitoring and supported SentinelHealth data

Answer: D

Explanation:
Microsoft Sentinel provides a data collection health monitoring workbook and, for supported connectors, the SentinelHealth table. These capabilities help identify ingestion problems, connector failures, data collection anomalies, and changes in connector health.

Go to the SC-500 Exam Prep Hub main page