How should a scheduled KQL job write to an existing Sentinel data lake table?

SC-200 By islever Editorial Last updated

Configure the Microsoft Sentinel SIEM and platform

Short answer

D Ensure that Job1's query output matches the schema of Table1 before the scheduled KQL job writes to that existing Sentinel data lake table.

Question

You have a Microsoft Sentinel workspace named Workspace1 that is connected to the Microsoft Sentinel data lake and contains a table named Table1.
You need to create a scheduled KQLjob named Job1 that runs hourly, queries data across multiple Microsoft Sentinel workspaces, and writes the output of Job1 to Table1.
What should you do?
  1. Assign the Microsoft Sentinel Reader role on Workspace1 to the managed identity of Job1.
  2. Add a project statement to Job1.
  3. Append the _KQL_CL_ suffix to Table1.
  4. Ensure that the output of Job1 matches the schema of Table1. Correct Answer

Key Takeaways

This question tests how scheduled KQL jobs write to existing Sentinel data lake tables; the trap is assuming a project statement or workspace role solves the destination schema requirement.

Microsoft Sentinel data lake scheduled KQL jobs can write query results to an existing table, but Job1's output must align with Table1's schema. This page explains why option D is correct and why cross-workspace permissions or column projections do not replace destination schema validation.

Common mistake: Choosing B and thinking a project statement automatically adapts Job1 output to Table1, when projection only selects columns and does not guarantee the destination schema match.

Expert Analysis

Why the Answer Is Correct

When a scheduled KQL job in the Microsoft Sentinel data lake writes to an existing destination table, the query output schema must line up with the table definition. Table1 already exists, so Job1 must produce columns and data types that are compatible with Table1 rather than relying on the job to reshape data automatically. That makes option D the decisive action: verify and, if necessary, adjust the query so its output matches Table1's schema. Cross-workspace querying affects where the data comes from, but it does not remove the requirement that the final write target accepts the output shape.

Why the Other Options Are Wrong

Option A is tempting because a job identity needs read access to the workspaces it queries, but assigning Microsoft Sentinel Reader on Workspace1 alone does not satisfy the destination-schema requirement and may not cover every source workspace. Option B is insufficient because a project statement selects or renames columns; it does not prove that the resulting schema matches an existing table's full definition. Option C is a distractor: appending a suffix such as _KQL_CL_ is not the mechanism for making Job1 output compatible with Table1, especially when Table1 is already defined. None of these options addresses the actual write-compatibility rule.

Community Comment Notes

Mebyxu's comment captures the key rule: “the query results must match the schema of the existing table”. That aligns directly with why D is the best answer and why the other options are supporting or unrelated actions rather than the required step. The comment also reinforces that the issue is writing into an existing table, not simply reading across workspaces or changing the query presentation.

Exam Strategy

When a question says a job writes to an existing named table, scan the options for schema alignment; permissions and query syntax options are often distractors. For cross-workspace reads, remember the job identity needs access to every source workspace, not only one.

Frequently Asked Questions

Why doesn't assigning Microsoft Sentinel Reader to Job1's managed identity solve this?

It grants read access to Workspace1 data, but the question's issue is writing Job1 output into existing Table1, which requires matching Table1's schema.

Does appending _KQL_CL_ to Table1 fix the scheduled KQL job?

No, the table already exists and the suffix is not a mechanism for aligning Job1's output columns and types.

More SC-200 FAQ →

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

  1. Mebyxu 👍 1 Answered D
    When adding to an existing table, the query results must match the schema of the existing table

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Creating a Microsoft Sentinel bookmark from the Hunting page to support an incident investigation

S-grade

Identifying Affected Entities in Microsoft Defender XDR Incidents

S-grade

Containing a Defender for Identity pass-the-ticket alert by quarantining only the affected device

S-grade

Limiting Microsoft Defender device discovery to specific onboarded devices by creating a device tag first

S-grade

Practice All SC-200 Questions

Access 80 questions with complete answers and detailed explanations.

View Full SC-200 Practice Test →

← Back to SC-200 Study Guide