15.2 Diagnostics, KQL & Workbooks

From portal triage to a monitoring pipeline

Section 15.1 taught interactive investigation in the Entra admin center. Production tenants need more: longer retention, SIEM correlation, alerts, and repeatable dashboards. Microsoft Entra diagnostic settings export log categories to Azure destinations. In Log Analytics, you query with KQL. Workbooks and built-in reports turn those streams into operational visibility.

/practice/azure-sc-300Practice questions with detailed explanations

Diagnostic settings: the export control plane

A diagnostic setting on Microsoft Entra ID specifies:

1. Which log categories to export (for example AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ProvisioningLogs—exact category names evolve with the product).
2. Which destination(s) receive the stream.
3. Optionally, metrics or additional categories your tenant supports.

You can maintain multiple diagnostic settings to fan out the same categories to different sinks (workspace for ops, Event Hub for SIEM, storage for cold archive).

Destination comparison

Exam trap: “Store logs forever in the Entra portal only” is not a retention architecture. Correct answers emphasize diagnostic settings to Log Analytics, storage, or Event Hubs.

What to export for identity operations

Minimum useful set for SC-300-style monitoring:

• AuditLogs — who changed directory/config.
• SignInLogs — interactive user authentications.
• NonInteractiveUserSignInLogs — token/refresh style user activity.
• ServicePrincipalSignInLogs (and related managed identity categories where listed) — workload auth.
• ProvisioningLogs — HR/app provisioning.
• Risk / ID Protection related categories when licensed and available for export.

Exporting only AuditLogs leaves you blind to authentication failures; exporting only SignInLogs leaves you blind to privilege grants.

Permissions and ownership

Configuring diagnostic settings and reading workspaces typically requires privileged Entra roles (for example Security Administrator / Global Administrator patterns for tenant diagnostics) plus Azure RBAC on the destination resource (Log Analytics Contributor, etc.). SC-300 cares that identity monitoring is a joint Entra + Azure resource operation: the workspace lives in a subscription; the log source is the tenant.

Log Analytics tables (conceptual)

Once diagnostics land in a workspace, data appears in tables you query. Conceptual mapping:

You do not need to memorize every column for the exam. You need to know that after diagnostic settings, investigations can use KQL against these tables in addition to the portal.

KQL for identity admins (teach concepts, not expert mode)

Kusto Query Language (KQL) is the query language for Log Analytics. SC-300 expects literacy, not certification-level KQL craft.

Building blocks

Example 1 — failed interactive sign-ins last day (concept)

SignInLogs
| where TimeGenerated > ago(1d)
| where ResultType != "0"
| summarize FailureCount = count() by UserPrincipalName, ResultDescription
| order by FailureCount desc
| take 20

Teaching point: start from the sign-in table, constrain time, filter failures, aggregate by user and reason, sort. Exact property names can vary slightly by schema version; exam items test the approach.

Example 2 — Conditional Access failure focus (concept)

SignInLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessStatus == "failure"
| summarize Attempts = count() by UserPrincipalName, AppDisplayName
| order by Attempts desc

Teaching point: CA impact analysis at scale uses exported sign-ins, not only opening one user in the portal. Report-only pilots can similarly be summarized when the schema exposes report-only results.

Example 3 — audit who changed groups (concept)

AuditLogs
| where TimeGenerated > ago(48h)
| where Category == "GroupManagement"
| project TimeGenerated, OperationName, Identity = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].displayName)
| order by TimeGenerated desc

Teaching point: audit queries answer accountability questions across the whole tenant window, useful for SOC reviews after a privilege or membership incident.

Example 4 — provisioning failures by app (concept)

AADProvisioningLogs
| where TimeGenerated > ago(3d)
| where ResultType != "Success"
| summarize Events = count() by JobId = tostring(JobId), ResultDescription
| order by Events desc

Teaching point: same pattern—filter non-success, summarize, prioritize the noisiest job or error.

KQL hygiene for SC-300 answers

• Always time-bound queries; unbounded scans are slow and expensive.
• Filter early (user, app, failure) before heavy joins.
• Use summarize for trends; use project for incident timelines.
• Alerts in Azure Monitor are often “run this KQL on a schedule; fire if threshold met” (for example spike in legacy auth failures).

You will not be asked to hand-write perfect production queries under every schema nuance. You will be expected to choose Log Analytics + KQL when the stem wants historical analysis, custom reporting, or automated detection beyond the default portal UX.

Workbooks and reporting

Azure workbooks (and Entra monitoring workbook experiences) are interactive dashboards built on Log Analytics queries and visualizations. Microsoft ships Entra-oriented workbook templates for topics such as:

Using workbooks well

1. Ensure diagnostic settings populate the workspace the workbook expects.
2. Open Entra workbooks / Azure Monitor workbooks gallery for identity templates.
3. Set time range and subscriptions/workspace parameters.
4. Drill from chart → grid → single sign-in/audit event.
5. Clone and customize for your org (add filters for privileged users, break-glass UPNs, Tier-0 apps).
6. Pin key views for weekly identity ops review.

Built-in reports vs workbooks vs raw KQL

SC-300 identity admin answers usually stop at diagnostic settings + Log Analytics/workbooks; full Sentinel engineering is more SC-200/SOC territory, but recognizing Sentinel as a consumer of Event Hub/workspace data is fair game.

Monitoring architecture patterns

Pattern A — Identity ops core

Entra diagnostics → Log Analytics → workbooks + Azure Monitor alerts (failed MFA spike, break-glass sign-in, privileged role assignment).

Pattern B — Enterprise SIEM

Entra diagnostics → Event Hubs → corporate SIEM; optional parallel → Log Analytics for identity team self-service.

Pattern C — Compliance archive

Entra diagnostics → Storage for long retention + Log Analytics for 90-day hot query; lifecycle policies on storage.

Alert ideas that map to earlier chapters

Operational checklist

1. Inventory which categories you currently export (many tenants export nothing).
2. Create or select a dedicated Log Analytics workspace with appropriate retention.
3. Configure Entra diagnostic settings to workspace (+ Event Hub/storage as needed).
4. Validate data latency with a known test sign-in and a simple KQL take query.
5. Deploy starter workbooks for sign-ins and CA.
6. Define three to five alerts tied to runbooks (who gets paged, what they check).
7. Review workbook trends in the same ops meeting as Identity Secure Score (next section).
8. Document workspace access (least privilege; not every helpdesk agent needs full query rights on all tables).

Common exam traps

• Confusing Azure activity logs (ARM resource operations) with Entra sign-in/audit logs.
• Choosing storage when the requirement is interactive KQL investigation (Log Analytics).
• Choosing only portal filters when the requirement is 12-month retention and SIEM.
• Believing workbooks work with full historical depth without diagnostic export.
• Writing that KQL is required for every single-user helpdesk ticket (portal is fine for one-off).

Summary of section 15.2

/practice/azure-sc-300Practice questions with detailed explanations