In this section
Setting Up Your Lab Environment
You have written your first KQL query, read the results for attack patterns, and adapted the four-operator structure to three different tables. You understand the course structure and what each phase teaches. This section ensures you have a working lab environment where you can run every KQL query in the course against real security telemetry — either your own or Microsoft's demo data.
Scenario
Priya wants to start Module 1 but is not sure she has the right access. She has a Sentinel workspace at work but has never opened the query editor. She also heard there is a free Microsoft demo environment somewhere. She needs to know: which environment should she use, how does she verify it works, and what should she do if the verification query returns zero results?
Three lab paths
Every module in this course includes KQL queries that you type, run, and analyze. You need an environment with security telemetry (real or sample) where you can execute those queries. Three paths are available, each suited to different access levels and objectives.
Three lab paths — production workspace (best), demo environment (easiest), or developer tenant (most complete). All support the course exercises.
The choice matters less than you think. Every path gives you a query editor, security telemetry, and the ability to run the exercises. Production is the best option because you learn against your data, and every query you write transfers directly to your daily work. The demo environment is the fallback when you do not have production access. It gives you sample data within two minutes, no subscription required. The developer tenant is the most complete option if you want full control over connectors, analytics rules, and detection deployment.
Path 1 — Your production Sentinel workspace
If you have access to your organization's Sentinel workspace, this is the best lab environment. You learn KQL against your data, with your tables, in your security context. Every query you write during the course immediately transfers to your daily investigation workflow because it already runs against your environment.
Minimum permission. Microsoft Sentinel Reader role (or Log Analytics Reader) is sufficient for every exercise in this course. Both are read-only. You can query any table in the workspace but cannot modify analytics rules, data connectors, or workspace settings. If you already have Contributor or Responder permissions, those work too. Ask your Sentinel administrator if you are unsure which role you have.
Where to query. Microsoft is consolidating Sentinel into the unified Defender portal at security.microsoft.com. The standalone Sentinel experience in the Azure portal (portal.azure.com) will be retired on March 31, 2027. If your organization has already onboarded Sentinel to the Defender portal, use Advanced Hunting there. It queries both Sentinel Log Analytics tables and Defender XDR tables from a single interface. If you are still in the Azure portal, use the Logs blade inside your Sentinel workspace. The KQL syntax is identical in both environments. This course's queries run in either place without modification.
Verification. Run this query to confirm your workspace has identity telemetry:
If this returns a row with both values greater than zero, your workspace has identity data and you are ready to start Module 1. The specific numbers depend on your organization's size. A 500-person company might show 50,000 events and 400 unique users over seven days, while a 5,000-person enterprise might show half a million events and 3,000 users. The numbers do not matter for this course. What matters is that the query ran successfully and returned data.
Path 2 — The Log Analytics demo environment
Microsoft provides a free, read-only demo workspace pre-populated with sample security data. No Azure subscription required. No setup beyond signing in with a Microsoft account. Navigate to aka.ms/LADemo in your browser, sign in, and the query editor opens with the demo workspace already selected. The word "Demo" appears in the upper-left scope indicator to confirm you are in the right place.
What the demo contains. The demo workspace includes populated tables across multiple security domains: SigninLogs and AADNonInteractiveUserSignInLogs for identity, SecurityEvent for Windows event logs, Syslog for Linux, AzureActivity for Azure management plane operations, AzureDiagnostics for resource diagnostics, and several monitoring tables. The sample data is refreshed periodically and covers enough volume for meaningful query results.
Not every Sentinel table is present. DeviceProcessEvents and other Defender for Endpoint tables require an MDE deployment and do not appear in the demo workspace. For modules that reference Defender tables (K7 deep dives, K11 hunting exercises), the course provides alternative queries against tables that exist in the demo environment. You will not be blocked from completing any module.
Verification. Run the same verification query from Path 1. In the demo workspace, you should see tens of thousands of sign-in events across hundreds of sample users. If SigninLogs returns no data, try expanding the time range (the demo workspace sometimes has gaps in the most recent hours. SecurityEvent | take 5 is the fallback test) the demo always has Windows event log data.
Limitations worth knowing. The demo workspace is read-only and does not support saving queries, creating stored functions, or deploying analytics rules. You can write and run any query, but you cannot persist your work inside the workspace. Save your queries locally. A text file, a Git repository, or a note-taking application. You will build a query library throughout this course, and local storage ensures you keep every query you write. The demo environment's retention is also shorter than a production workspace, so queries with ago(90d) or ago(180d) might return less data than expected. Adjust the time window downward if you see sparse results.
Path 3 — M365 developer tenant
If you want a full Sentinel and Defender XDR environment that you control (with the ability to create analytics rules, configure data connectors, and deploy detection logic) an M365 developer tenant provides that. This is the most complete lab, but it takes the most time to set up, and eligibility has narrowed.
Eligibility. The M365 Developer Program provides a free E5 sandbox with 25 user licenses. Access requires membership in a qualifying Microsoft partner program (ISV Success, eligible MAICPP tiers, Solutions Partner designation) or a Visual Studio Professional or Enterprise subscription. Microsoft significantly restricted the program starting in 2024 (individual developers, students, and organizations without qualifying partnerships are often ineligible. Check your eligibility at developer.microsoft.com/en-us/microsoft-365/dev-program by signing in with your corporate email. If the option to create a sandbox does not appear after sign-in, you do not currently qualify. Use Path 1 or Path 2 instead) this course is fully completable with either.
Setup sequence. Register at the Developer Program portal and create an instant sandbox. The sandbox provisions with 25 sample users, mailboxes, and Teams channels. In the Azure portal, create a free-tier Log Analytics workspace, enable Microsoft Sentinel on it (31-day free trial), then connect data connectors: Entra ID for SigninLogs and AuditLogs, and Microsoft 365 for OfficeActivity. Sign in with several sample user accounts across different browsers to generate authentication events. Wait 24 to 48 hours for initial data ingestion — connectors need time to begin streaming, and the first records will not appear immediately.
Cost after the trial. The developer tenant itself is free. Sentinel is free for 31 days on the first workspace. After the trial, a developer tenant with 25 sample users generates approximately 50 to 100 MB of data per day, costing roughly $2 to $5 per month at analytics-tier pricing. Disable data connectors you are not actively using to minimize cost. The workspace retains existing data even when connectors are paused, so you do not lose data by toggling connectors off between study sessions.
Tenant renewal. Developer tenants expire after 90 days of inactivity. Sign in at least once every 90 days and perform some activity (send an email, create a Teams message, run a query) to keep the tenant active. The Developer Program dashboard shows your renewal status and remaining days.
The query editor — your primary workspace
Whichever path you chose, you will spend most of this course in the query editor. Understanding the interface before Module 1 saves time on every exercise that follows.
The editor occupies the center of the screen. Type KQL here and press Run (or Shift+Enter) to execute. The editor supports IntelliSense autocomplete — press Ctrl+Space after typing a table name to see available columns, or after a pipe to see available operators. IntelliSense is context-aware: it suggests column names from the table in your current query, not from every table in the workspace.
The time range selector sits in the top-right corner. The default is "Last 24 hours." You can change it to preset ranges (last 30 minutes, last 4 hours, last 7 days) or define a custom range with specific start and end timestamps. Your in-query where TimeGenerated clause overrides this selector. If the query specifies ago(1h), the results cover only the last hour regardless of the selector setting. Use the selector for broad exploration and the where clause for precise investigation. Throughout this course, every query includes an explicit time filter so the results are deterministic and reproducible.
The results pane appears below the editor after execution. Each row is one event. Click the expand arrow (>) on any row to see all columns, including those you excluded with project. The results pane shows up to 30,000 rows by default. If your query returns more, add | take 1000 to limit the output during development. You can always remove the limit when you need the full result set.
The table browser on the left lists every table in the workspace, grouped by solution. Expand a table to see its columns and data types. Double-click a table or column name to insert it at the cursor position in the editor. This is faster than typing table names from memory and avoids the case-sensitivity errors discussed in Section 0.4.
If your verification query returns something like the output above (a total event count and a unique user count, both greater than zero) your lab is working. A production workspace might show millions of events. The demo workspace shows tens of thousands. A developer tenant shows a few thousand. Any non-zero result means the environment is ready.
Building your query library from day one
Every module in this course produces queries you will want to reuse. The habit of saving queries starts now, not later.
Create a local folder — kql-library/ in a Git repository is ideal, but a directory of .kql files works too. For each query, save the KQL with a short header comment describing the investigation question it answers and the table it targets. By Module 13, you will have approximately 50 queries organized by investigation type: identity, endpoint, email, cross-table, detection, and hunting. A structured library is the artifact you carry forward from this course into production work.
Troubleshooting common setup issues
"No results found" on SigninLogs. Three causes cover 95% of cases. First, the Entra ID data connector is not enabled (in the Azure portal, check Microsoft Sentinel → Data connectors and confirm the "Microsoft Entra ID" connector shows a status of "Connected." In the Defender portal, check Settings → Microsoft Sentinel → Data connectors. Second, data ingestion has not started yet) newly enabled connectors take 15 minutes to 48 hours for initial data to appear, depending on the table and tenant volume. Third, the time range is too narrow — expand to "Last 7 days" and rerun. If all three check out and you still see zero results, your organization may not have the required license. SigninLogs requires at minimum an Entra ID P1 license (included in M365 E3/E5 and EMS E3/E5).
"Access denied" or "Insufficient permissions." You need at least the Log Analytics Reader role on the workspace. In the Azure portal, the workspace administrator assigns this under Access Control (IAM). In the Defender portal, Sentinel Reader permissions are managed through Microsoft Defender XDR unified RBAC. If your organization uses custom RBAC roles, ask for read-only access to the Log Analytics workspace that backs your Sentinel deployment.
Query times out after 10 minutes. The query is scanning too much data without a time filter. Every query in this course includes a where TimeGenerated clause. If you are experimenting without one, add | where TimeGenerated > ago(1h) as the first filter after the table name. Against a large production workspace, unfiltered queries against tables like DeviceProcessEvents or SigninLogs can attempt to scan tens of millions of rows. The 10-minute timeout is a platform safeguard, not an error. It means the query needs a narrower scope.
DeviceProcessEvents or other Defender tables return errors. These tables require Microsoft Defender for Endpoint data ingestion into the workspace. If your organization uses MDE, the tables should be available in both Sentinel and Advanced Hunting. If the Defender for Endpoint data connector is configured but you still get errors, the table might be named differently in your query surface — DeviceProcessEvents in Advanced Hunting versus the streaming version in Sentinel. Check the table browser for the exact table names available in your workspace. If you are using the demo workspace (Path 2), some Defender tables are not present. The course provides alternative queries for each affected exercise.
The demo environment says "Failed to retrieve schema." This intermittent error typically resolves by signing out, clearing the browser cache, and signing back in. If it persists, try an InPrivate or Incognito window. The demo workspace is a shared resource — occasional access issues are not uncommon and usually resolve within a few hours.
The analyst reads Module 0 and Module 1, intending to set up the lab "later." By Module 2, every section includes queries that reference specific results — row counts that change under different filters, aggregation patterns that reshape when you modify the grouping column, join results that reveal investigation pivots the prose alone cannot convey. Reading a query without running it is understanding the steps without internalizing the mechanics. Set up your lab now. Run the verification query. Confirm it returns data. Then proceed to Module 1 knowing that every example in this course is something you can execute immediately.
KQL Principle
KQL is a hands-on language. You learn it by running queries, reading results, and modifying filters — not by reading about operators. Every module in this course provides the query and the expected output side by side. Your job is to run the query, compare your results to the expected output, then modify the query and observe what changes. The modification is where learning happens. The lab environment is not supplementary. It is the primary learning mechanism.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.