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
      --> Create custom log tables in the workspace to store ingested data

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.

Overview

Microsoft Sentinel is built on Azure Monitor Logs, with a Log Analytics workspace serving as the underlying data store. While Microsoft Sentinel provides many predefined tables for common security data sources, organizations frequently need to ingest data that doesn’t fit an existing schema.

For these situations, you can create custom log tables in the Log Analytics workspace and use Data Collection Rules (DCRs) to control how the incoming data is collected, transformed, and routed into those tables.

This topic is part of the Manage and monitor security posture (20–25%) skill area of the SC-500 exam, specifically the Implement activity and event collection in Microsoft Sentinel area.

The key concepts to understand are:

• Custom Log Analytics tables
• The _CL naming convention
• Table schemas and column data types
• TimeGenerated
• Data Collection Rules (DCRs)
• Data Collection Endpoints (DCEs)
• Logs Ingestion API
• Ingestion-time transformations
• Table plans
• Analytics, Basic, and Auxiliary/Lake tables
• Custom columns
• Schema changes
• KQL querying of custom tables
• Cost and performance considerations

1. Why Create Custom Log Tables?

Microsoft Sentinel can ingest data from many Microsoft and third-party sources. Standard connectors typically send information into predefined tables such as:

• SecurityEvent
• CommonSecurityLog
• Syslog
• SigninLogs
• AzureActivity

However, an organization may have a proprietary application, security product, network device, or custom process that produces information in a format that doesn’t correspond to an existing table.

For example, a company might have an internally developed security application that produces records like:

Timestamp
ApplicationName
UserName
RiskScore
SourceIP
Action
ThreatCategory

Rather than attempting to force this information into an unrelated standard table, the organization can create a custom table such as:

ContosoSecurityEvents_CL

The custom table defines the schema needed to store the incoming data.

Custom tables are particularly useful for:

• Custom applications
• Proprietary security solutions
• Third-party security products
• Custom scripts
• Application telemetry
• Specialized audit data
• Logs received through the Logs Ingestion API
• Data that requires a specialized schema

Azure Monitor provides custom tables specifically for situations where the predefined Azure table schemas don’t meet the requirements of the incoming data.

2. Microsoft Sentinel and the Log Analytics Workspace

One of the most important SC-500 concepts is understanding the relationship between Microsoft Sentinel and Azure Monitor Logs.

Conceptually:

                Data Sources
                     |
                     v
          Data Collection / Ingestion
                     |
                     v
          Data Collection Rules
              (DCRs)
                     |
                     v
          Azure Monitor Logs
                     |
                     v
           Log Analytics Workspace
                     |
          +----------+----------+
          |                     |
    Standard Tables       Custom Tables
          |                     |
          +----------+----------+
                     |
                     v
             Microsoft Sentinel
                     |
          +----------+----------+
          |          |          |
       Queries    Analytics   Incidents

Microsoft Sentinel does not maintain a completely separate log database. Sentinel uses Azure Monitor Logs, and the logs are stored in the associated Log Analytics workspace.

Therefore, when an SC-500 question asks you to create a custom table “in the workspace,” think:

Log Analytics workspace → custom table → DCR/ingestion → Microsoft Sentinel queries and analytics

3. What Is a Custom Log Table?

A custom table is a Log Analytics table whose schema is defined by the organization rather than being a predefined Azure service schema.

A typical custom table might be:

ContosoSecurityEvents_CL

The _CL suffix identifies a custom log table.

For example:

Table: ContosoSecurityEvents_CL
Columns:
    TimeGenerated       datetime
    ApplicationName     string
    UserName            string
    SourceIP            string
    RiskScore            int
    Action              string
    ThreatCategory      string

The table schema determines the structure of the data that can be stored and queried.

The Azure portal automatically adds _CL when you create a custom table through the portal. When creating a custom table through other methods, such as APIs or CLI, the _CL suffix needs to be specified.

SC-500 Exam Tip

If a question asks:

“Which table naming convention should be used for a custom Log Analytics table?”

The expected answer is generally:

_CL

For example:

NetworkThreats_CL
ApplicationAudit_CL
CustomSecurityEvents_CL

4. Custom Table Schema

The schema defines the columns and data types available in the table.

Common data types include:

For example:

ContosoSecurityEvents_CL
TimeGenerated       datetime
ApplicationName     string
UserName            string
SourceIP            string
RiskScore            int
IsMalicious         boolean
EventData            dynamic

The choice of data type matters because it affects how the information can be queried and analyzed.

For example, if RiskScore is stored as an integer, queries can perform numerical comparisons:

ContosoSecurityEvents_CL
| where RiskScore >= 80
| order by RiskScore desc

If the same value were stored as a string, numerical analysis would be more cumbersome.

5. The Importance of TimeGenerated

A particularly important requirement is the TimeGenerated column.

Log Analytics tables use TimeGenerated to represent the time associated with the log record. Custom tables must have a TimeGenerated column.

If the incoming sample data doesn’t contain an appropriate TimeGenerated value when creating a custom table, Azure Monitor can create a transformation to add one.

For example:

TimeGenerated       datetime
EventType           string
SourceIP            string
UserName            string
Action              string

This allows queries such as:

ContosoSecurityEvents_CL
| where TimeGenerated > ago(24h)
| summarize Count=count() by Action

Exam Tip

Remember:

Every Log Analytics table needs TimeGenerated.

It is one of the easiest details for an SC-500 question to test.

6. Data Collection Rules (DCRs)

Creating the table is only part of the process.

You also need a mechanism to control how the incoming data reaches the table.

That is where Data Collection Rules (DCRs) come into play.

A DCR defines how data is:

1. Collected
2. Filtered
3. Transformed
4. Routed
5. Sent to a destination

Conceptually:

Source Data
    |
    v
+----------------------+
| Data Collection Rule |
|                      |
| Collect              |
| Filter               |
| Transform            |
| Route                |
+----------------------+
    |
    v
Custom Table
    |
    v
Log Analytics Workspace

DCRs can therefore provide an ingestion-time processing layer between the source and the destination table.

7. DCR Data Flows

A DCR can define the relationship between an incoming data stream and the destination table.

For example:

CustomSecurityStream
        |
        v
       DCR
        |
        +---- Transformation
        |
        v
ContosoSecurityEvents_CL

The destination table name in the DCR must correspond to the custom table.

For example:

ContosoSecurityEvents_CL

The DCR data flow must target:

ContosoSecurityEvents_CL

A mismatch between the table definition and the DCR is a common configuration problem.

8. Ingestion-Time Transformations

One of the most powerful capabilities associated with custom ingestion is ingestion-time transformation.

A DCR can use a KQL transformation to manipulate incoming records before they are stored.

For example, suppose incoming records contain:

UserName
SourceIP
RiskScore
Action

A transformation could:

• Remove unwanted records
• Rename or derive values
• Normalize information
• Add calculated information
• Mask sensitive information
• Convert values
• Enrich records
• Reduce unnecessary data

Conceptually:

Raw Data
   |
   v
DCR
   |
   v
KQL Transformation
   |
   +---- Filter unwanted records
   |
   +---- Transform fields
   |
   +---- Enrich/normalize data
   |
   v
Custom Table

Microsoft Sentinel supports DCR-based transformations for custom data ingestion, and transformations can filter, enrich, or mask incoming data before it is stored.

9. Example Transformation

Suppose incoming data contains a numeric risk score:

RiskScore

You might want to classify the event during ingestion.

Conceptually, a transformation could produce:

RiskLevel

based on the score.

For example:

source
| extend RiskLevel =
    case(
        RiskScore >= 90, "Critical",
        RiskScore >= 70, "High",
        RiskScore >= 40, "Medium",
        "Low"
    )

The resulting record can then be stored in the destination custom table.

This approach is useful because the data is normalized before analysts and Sentinel analytics rules consume it.

10. Logs Ingestion API

The Logs Ingestion API provides another important method for sending custom-format data into Azure Monitor Logs.

It is particularly useful when an application or external system needs to send data programmatically.

Conceptually:

Custom Application
       |
       | HTTPS
       v
Logs Ingestion API
       |
       v
DCR
       |
       v
Transformation
       |
       v
Custom Table

The Logs Ingestion API can send custom-format logs into Log Analytics tables, including custom tables, while DCRs define the data flow and transformations.

Example Scenario

A company has an internally developed fraud-detection application.

The application generates:

{
    "user": "jsmith",
    "sourceIP": "10.10.20.15",
    "riskScore": 94,
    "action": "Blocked"
}

The application could send these records through the Logs Ingestion API.

The DCR could transform the data and route it to:

FraudDetection_CL

Microsoft Sentinel could then query that table for detections.

11. Data Collection Endpoints (DCEs)

A Data Collection Endpoint (DCE) can provide an ingestion endpoint for Azure Monitor data collection scenarios.

A common architecture is:

Application
     |
     v
Data Collection Endpoint
     |
     v
Data Collection Rule
     |
     v
Log Analytics Workspace
     |
     v
Custom Table

Not every DCR scenario requires a separately created DCE. For example, current Azure Monitor documentation describes a DCR with kind set to Direct that can create its own Logs Ingestion endpoint.

Exam Tip

Do not automatically assume:

“Every custom table requires a DCE.”

Instead, determine what ingestion mechanism the scenario specifies.

12. Creating a Custom Table in the Azure Portal

A typical portal workflow is:

Step 1 — Open the Log Analytics workspace

Navigate to the appropriate:

Log Analytics workspace

Step 2 — Open Tables

Select:

Tables

Step 3 — Create a table

Select:

Create

Step 4 — Specify the table name

For example:

ContosoSecurityEvents

The portal creates the custom table as:

ContosoSecurityEvents_CL

Step 5 — Select the table plan

Choose the appropriate table plan.

Step 6 — Associate a DCR

Select an existing DCR or create a new one.

Step 7 — Select the DCE if required

Depending on the ingestion scenario, select an appropriate Data Collection Endpoint.

Step 8 — Provide sample data

A JSON sample can be used to help define the schema.

For example:

{
    "TimeGenerated": "2026-09-13T14:30:00Z",
    "ApplicationName": "FraudDetection",
    "UserName": "jsmith",
    "SourceIP": "10.10.20.15",
    "RiskScore": 94,
    "Action": "Blocked"
}

Step 9 — Configure transformations

If required, use the transformation editor.

Step 10 — Review the schema

Verify:

• Column names
• Data types
• TimeGenerated
• Destination table
• Transformation
• Table plan

Step 11 — Create the table

After validation, create the custom table.

This workflow is supported directly through the Log Analytics workspace Tables experience.

13. Custom Table Naming Rules

There are several schema rules worth remembering.

A custom table uses:

<TableName>_CL

For example:

FirewallEvents_CL

Custom column names have their own restrictions. They must:

• Start with a letter
• Use letters, digits, and underscores
• Avoid spaces
• Avoid dots
• Avoid dashes
• Avoid other punctuation
• Follow the applicable length restrictions

Custom column names added to Azure tables use the _CF suffix.

Good examples

SourceIP
UserName
RiskScore
ThreatCategory
DeviceName

Poor examples

Source-IP
Source IP
Source.IP
123SourceIP

14. Updating a Custom Table Schema

Custom tables aren’t necessarily static.

For example, you might initially have:

TimeGenerated
UserName
SourceIP
Action

Later, the application begins producing:

ThreatCategory

You may add a custom column to accommodate the new information.

However, there is an important consideration:

When the table schema changes, the DCR that sends data to the table must also be updated as appropriate.

Azure Monitor does not automatically update your DCR simply because you modified the destination table schema.

This is a very useful SC-500 exam distinction.

Think of it this way:

Table Schema
     ^
     |
Must remain compatible with
     |
     v
DCR Schema / Data Flow
     ^
     |
Incoming Data

If these components don’t agree, ingestion can fail or produce unexpected results.

15. Table Plans

A custom table can use different table plans depending on the organization’s requirements.

Current Azure Monitor Logs supports:

Analytics is the default plan when creating a custom table through the standard workflow. DCR-based custom tables support the available table plans, subject to the capabilities and limitations of each plan.

Choosing a plan

Consider:

• How frequently the data will be queried
• Whether the data supports active security detections
• Query capabilities required
• Data volume
• Retention requirements
• Cost

For example:

High-value security events

Authentication failures
Critical threat alerts
Security detections

These are likely candidates for an Analytics plan when frequent investigation and detection are required.

Large-volume historical data

Verbose application telemetry
Long-term diagnostic information
High-volume historical records

A lower-cost storage-oriented plan may be more appropriate, depending on the required capabilities.

16. Custom Tables Versus Standard Tables

Understanding the difference is important for the SC-500 exam.

The general principle is:

Use a standard table when the data naturally belongs to an existing Microsoft schema; use a custom table when the data requires its own schema.

17. Querying a Custom Table with KQL

Once data is successfully ingested, it can be queried using Kusto Query Language (KQL).

Suppose the table is:

ContosoSecurityEvents_CL

A simple query is:

ContosoSecurityEvents_CL
| take 100

To retrieve recent events:

ContosoSecurityEvents_CL
| where TimeGenerated > ago(24h)
| order by TimeGenerated desc

To identify high-risk events:

ContosoSecurityEvents_CL
| where RiskScore >= 80
| project TimeGenerated, UserName, SourceIP, RiskScore, Action
| order by RiskScore desc

To summarize events by action:

ContosoSecurityEvents_CL
| summarize EventCount=count() by Action
| order by EventCount desc

18. Custom Tables and Microsoft Sentinel Analytics Rules

Once data exists in a custom table, Microsoft Sentinel can use that data for security monitoring.

For example:

Custom Application
       |
       v
SecurityEvents_CL
       |
       v
Microsoft Sentinel
       |
       +---- Analytics Rule
       |
       +---- Hunting Query
       |
       +---- Workbook
       |
       +---- Investigation
       |
       +---- Automation

Suppose an organization wants to detect:

A user generating three or more high-risk fraud events within 10 minutes.

A Sentinel analytics rule could query:

FraudDetection_CL
| where TimeGenerated > ago(10m)
| where RiskScore >= 90
| summarize EventCount=count() by UserName
| where EventCount >= 3

This illustrates an important concept:

Creating the custom table does not itself create a security detection.

The table stores the data. Sentinel analytics rules, hunting queries, workbooks, and other capabilities consume the data.

19. Permissions

Managing tables requires appropriate permissions on the Log Analytics workspace.

For example, permissions such as:

Microsoft.OperationalInsights/workspaces/*

at the appropriate workspace scope can allow table management. The Log Analytics Contributor role is an example of a built-in role that can provide the necessary permissions.

This should not be confused with permission to simply query the data.

There is an important distinction between:

Managing the table

and:

Reading/querying the data

An SC-500 scenario may therefore provide a user who can query logs but cannot create or modify a table.

20. Security and Privacy Considerations

Custom tables can contain sensitive information.

Avoid placing sensitive information in:

• Table names
• Column names unnecessarily
• Diagnostic metadata
• Uncontrolled raw log fields

For example, don’t name a table:

CustomerSocialSecurityNumbers_CL

even if the table happens to contain that information.

Instead, use a neutral operational name such as:

CustomerSecurityEvents_CL

Azure documentation specifically cautions against including sensitive information in custom table names because table names are used for billing.

DCR transformations can also be used to reduce unnecessary data, mask information, or remove irrelevant records before they are stored.

21. Controlling Ingestion Volume

One of the biggest operational concerns with custom logging is simply collecting too much data.

Suppose an application produces:

10 million events/day

but only:

100,000 events/day

are relevant to security monitoring.

Sending everything to Sentinel may increase:

• Ingestion costs
• Storage requirements
• Query time
• Noise
• Investigation complexity

A DCR transformation can help filter irrelevant information before storage.

Conceptually:

10,000,000 Events
        |
        v
       DCR
        |
   Filter/Transform
        |
        v
  100,000 Useful Events
        |
        v
   Custom Table

This is one of the strongest reasons to understand DCRs rather than thinking of them simply as “connectors.”

22. Example: Custom Security Application

Consider an organization with an internal security application called ThreatWatch.

ThreatWatch produces:

Timestamp
DeviceName
UserName
SourceIP
ThreatType
Severity
Action

The security team wants the data available in Microsoft Sentinel.

Step 1 — Create the table

ThreatWatchEvents_CL

Step 2 — Define the schema

TimeGenerated       datetime
DeviceName          string
UserName            string
SourceIP            string
ThreatType          string
Severity            int
Action              string

Step 3 — Configure ingestion

The application sends records through an appropriate Azure Monitor ingestion mechanism.

Step 4 — Configure the DCR

The DCR:

• Defines the incoming stream
• Maps the fields
• Applies transformations
• Routes the records to ThreatWatchEvents_CL

Step 5 — Validate ingestion

Run:

ThreatWatchEvents_CL
| take 20

Step 6 — Create detections

For example:

ThreatWatchEvents_CL
| where Severity >= 8
| summarize HighSeverityEvents=count() by DeviceName
| where HighSeverityEvents >= 5

The resulting data can then participate in Sentinel investigations and detections.

23. Troubleshooting Custom Table Ingestion

When data isn’t appearing in a custom table, troubleshoot from the source toward the destination.

Step 1 — Verify the source

Is the application actually generating the expected data?

Step 2 — Verify the ingestion mechanism

Is the application correctly sending records?

Step 3 — Verify the DCE, if applicable

Is the ingestion endpoint correctly configured and reachable?

Step 4 — Verify the DCR

Check:

• Data source
• Stream
• Transformation
• Destination
• Table name
• Schema

Step 5 — Verify the table

Confirm:

TableName_CL

exists in the intended workspace.

Step 6 — Verify the schema

Make sure the incoming data matches the expected column types.

Step 7 — Query the table

For example:

ThreatWatchEvents_CL
| take 10

Step 8 — Check the time range

Don’t forget that the portal’s default query time range may exclude newly arriving data.

24. Common SC-500 Exam Traps

Trap 1: Confusing a custom table with a DCR

A DCR controls data collection and processing.

A custom table stores the resulting data.

They are related but are not the same thing.

Trap 2: Forgetting _CL

Custom tables use the _CL suffix.

MySecurityData_CL

Trap 3: Forgetting TimeGenerated

Custom Log Analytics tables require a TimeGenerated column.

Trap 4: Assuming the table automatically changes the DCR

It doesn’t.

If the table schema changes, review and update the DCR as necessary.

Trap 5: Assuming all data belongs in standard tables

If a data source has a unique schema that doesn’t fit an existing table, a custom table may be appropriate.

Trap 6: Confusing ingestion with detection

A custom table stores data.

A Sentinel analytics rule detects conditions in that data.

Creating the table doesn’t automatically create an incident.

Trap 7: Assuming all custom data must use the same table plan

Table-plan selection should be based on how the data will be used, queried, and retained.

Trap 8: Assuming a DCE is mandatory in every scenario

The required ingestion architecture depends on the ingestion mechanism and DCR configuration.

25. Best Practices

1. Design the schema before collecting data

Determine:

• What fields are actually required
• Appropriate data types
• Which fields analysts will query
• Which fields support detections

2. Use meaningful table names

For example:

FirewallThreats_CL
IdentityRiskEvents_CL
ApplicationSecurity_CL

3. Keep schemas consistent

Avoid frequently changing schemas unless there is a genuine requirement.

4. Use appropriate data types

Don’t store numeric values as strings unless there is a reason to do so.

5. Use DCR transformations

Filter unnecessary records and normalize data before ingestion when appropriate.

6. Minimize sensitive information

Don’t collect or retain sensitive information unnecessarily.

7. Select the table plan based on actual usage

Consider query frequency, detection requirements, retention, and cost.

8. Validate ingestion before creating detections

First confirm:

Data source
   ↓
DCR
   ↓
Custom table
   ↓
KQL query

Then build analytics rules.

9. Monitor ingestion volume

Unexpected increases in custom log volume can have both financial and operational consequences.

10. Treat the DCR and table schema as a coordinated design

A healthy ingestion architecture requires the source, DCR, transformation, and destination schema to agree.

26. SC-500 Exam-Focused Summary

For this topic, remember the following relationships:

The most important architectural model is:

                DATA SOURCE
                     |
                     v
          +---------------------+
          | Ingestion Mechanism |
          +---------------------+
                     |
                     v
          +---------------------+
          |        DCR          |
          |                     |
          | Collect             |
          | Transform           |
          | Filter              |
          | Route               |
          +---------------------+
                     |
                     v
          +---------------------+
          | Custom Log Table    |
          |     *_CL            |
          +---------------------+
                     |
                     v
          Log Analytics Workspace
                     |
                     v
            Microsoft Sentinel
                     |
          +----------+----------+
          |          |          |
       Hunting   Analytics   Workbooks
                     |
                     v
                Incidents

27. Key Takeaways

Before taking the SC-500 exam, make sure you can explain:

1. Why an organization would create a custom Log Analytics table.
2. How a custom table differs from a standard Azure Monitor table.
3. Why custom tables use the _CL suffix.
4. Why TimeGenerated is important.
5. How a DCR controls data collection and routing.
6. How ingestion-time transformations work.
7. When the Logs Ingestion API can be used.
8. The purpose of a DCE in applicable ingestion architectures.
9. How table schemas and DCR schemas must remain consistent.
10. How to choose between Analytics, Basic, and Auxiliary/Lake table plans.
11. How to query a custom table using KQL.
12. Why controlling ingestion volume is important for both cost and security operations.
13. The difference between storing security data and creating a Sentinel detection.
14. How to troubleshoot a custom ingestion pipeline from source to destination.

Practice Exam Questions

Question 1

A security team has developed an internal application that generates security events in a proprietary JSON format. No existing Microsoft Sentinel table has an appropriate schema for the data.

The team wants to store the events in the Log Analytics workspace.

What should you create?

A. A Microsoft Sentinel workbook
B. A custom Log Analytics table
C. An automation rule
D. A resource lock

Answer: B

Explanation

A custom Log Analytics table is appropriate when incoming data has a schema that doesn’t fit an existing standard table. The table allows the organization to define the columns and data types required for the proprietary data.

A workbook visualizes data, an automation rule responds to conditions, and a resource lock protects Azure resources; none provides the required storage schema.

Question 2

A security engineer creates a custom Log Analytics table named:

NetworkThreats

The table is created through an Azure management interface that requires the complete table name.

Which name should be used?

A. NetworkThreats_LOG
B. NetworkThreats_CUSTOM
C. NetworkThreats_SENTINEL
D. NetworkThreats_CL

Answer: D

Explanation

Custom Log Analytics tables use the _CL suffix.

Therefore, the table should be:

NetworkThreats_CL

The Azure portal can add the suffix automatically when creating the table through the portal, but when using other creation mechanisms, the _CL suffix must be specified as required.

Question 3

A company creates a custom table for application security events. The application sends records containing:

UserName
SourceIP
RiskScore
Action

The records don’t contain a timestamp.

Which column must be available in the custom table to satisfy the Log Analytics table requirement?

A. TimeGenerated
B. EventID
C. SourceComputer
D. Severity

Answer: A

Explanation

Log Analytics tables require a TimeGenerated column. If the incoming sample does not provide an appropriate TimeGenerated value, Azure Monitor can create a transformation to add one during the custom-table creation process.

The other columns aren’t universally required for custom tables.

Question 4

A company sends custom application logs to Microsoft Sentinel. Before the logs are stored, the security team wants to remove irrelevant records and calculate a new field called RiskLevel.

Which capability is most appropriate?

A. Microsoft Sentinel workbook
B. Azure resource lock
C. DCR-based ingestion-time transformation
D. Microsoft Entra Conditional Access

Answer: C

Explanation

A DCR-based ingestion-time transformation can process incoming records before they are stored. KQL can be used to filter records, calculate values, normalize data, enrich records, or mask information.

A workbook operates on data after ingestion, a resource lock protects Azure resources, and Conditional Access controls identity access.

Question 5

A developer needs to send proprietary application logs programmatically to a custom table in a Log Analytics workspace.

Which Azure capability is specifically designed for programmatic ingestion of custom-format logs?

A. Logs Ingestion API
B. Azure Resource Graph
C. Microsoft Sentinel workbook API
D. Azure Policy

Answer: A

Explanation

The Logs Ingestion API allows applications and other data sources to send custom-format log data into Azure Monitor Logs. DCRs can define the data flow and transformations, and the data can be stored in a custom table.

Azure Resource Graph is primarily used to query Azure resource metadata, while Azure Policy governs resource configuration.

Question 6

An administrator adds a new column to an existing custom table. The DCR that sends data to the table has not been modified.

What should the administrator do?

A. Delete the Microsoft Sentinel workspace
B. Review and update the DCR so its schema/data flow remains compatible with the table
C. Recreate every Sentinel analytics rule
D. Disable Microsoft Sentinel and enable it again

Answer: B

Explanation

When the schema of a custom table changes, the associated DCRs should also be reviewed and updated as necessary. Azure Monitor doesn’t automatically update DCRs when the destination table schema changes.

This is an important exam concept:

Table schema changes and DCR schema/data-flow definitions must remain synchronized.

Question 7

A security operations team needs to store a very high volume of verbose application telemetry. The data is primarily intended for inexpensive long-term storage and aggregated trend analysis rather than frequent interactive security investigations.

Which table plan is most appropriate to investigate first?

A. Analytics
B. Premium
C. Basic
D. Auxiliary/Lake

Answer: D

Explanation

The Auxiliary/Lake plan is designed for high-volume, verbose data scenarios where inexpensive long-term storage and aggregated analysis are important.

Analytics is generally better suited to frequently queried operational and security analytics workloads. Basic can provide cost-effective storage for less frequently accessed data, but the scenario specifically emphasizes high-volume verbose data and inexpensive long-term storage.

Question 8

A security team wants a custom table containing security events that analysts will query frequently and that will be used for continuous monitoring and threat detection.

Which table plan is generally the best starting point?

A. Analytics
B. Auxiliary/Lake
C. Basic
D. Archive-only

Answer: A

Explanation

The Analytics plan is designed for active querying, continuous monitoring, real-time detection, and more comprehensive analytics capabilities.

Because the scenario emphasizes frequent querying and security detections, Analytics is the most appropriate choice.

Question 9

A security engineer successfully creates:

ThreatEvents_CL

in a Log Analytics workspace.

However, when running:

ThreatEvents_CL
| take 10

no records are returned.

The engineer verifies that the table exists.

What should be investigated next?

A. The ingestion source, DCR, transformation, destination mapping, and schema
B. Whether the workspace has a resource lock
C. Whether a Sentinel workbook has been created
D. Whether Conditional Access requires MFA

Answer: A

Explanation

Creating a table does not automatically populate it.

The administrator should trace the ingestion pipeline:

Source
  ↓
Ingestion mechanism
  ↓
DCR
  ↓
Transformation
  ↓
Destination table

The DCR configuration, stream, transformation, destination table name, and schema should all be validated.

Question 10

A company wants to use custom security data in Microsoft Sentinel to generate incidents when suspicious activity is detected.

Which statement correctly describes the relationship between the custom table and the Sentinel analytics rule?

A. Creating the custom table automatically creates an analytics rule
B. The analytics rule replaces the custom table after the first detection
C. The custom table stores the data, while the analytics rule evaluates the data for detection conditions
D. The custom table can only be queried by workbooks

Answer: C

Explanation

The custom table stores the ingested data.

A Microsoft Sentinel analytics rule can query that data and determine whether a specified security condition has occurred. If configured appropriately, the analytics rule can generate an alert or incident.

The two components therefore serve different purposes:

Custom Table
     ↓
Stores security data
Analytics Rule
     ↓
Evaluates security data
     ↓
Generates detection/alert/incident

This distinction is fundamental to understanding Microsoft Sentinel’s architecture.

Go to the SC-500 Exam Prep Hub main page