Module 7 — Check My Knowledge (20 questions)
1. What is the relationship between a Log Analytics workspace and Microsoft Sentinel?
Sentinel is a security solution enabled on top of a Log Analytics workspace. The workspace stores the data in tables and provides KQL query capability. Sentinel adds analytics rules, incidents, automation, hunting, workbooks, and TI. You cannot have Sentinel without a workspace.
They are the same product with different names
Sentinel replaces Log Analytics
Log Analytics is only for non-security data
Layered architecture: workspace (data) + Sentinel (security). Workspace settings directly affect Sentinel capabilities.
2. Your organisation has offices in the UK and Germany with data residency requirements. How many workspaces do you need?
Two — one in UK South for UK data, one in West Europe for German/EU data. Use cross-workspace queries for correlation when needed. Data residency mandates regional storage, which requires separate workspaces.
One — RBAC handles data separation
Three — one per data type
It depends on the number of employees
Data residency requirements drive multi-workspace decisions. RBAC controls access, not data location.
3. You set a daily cap on your production workspace. At 14:00 the cap triggers. What happens?
All data ingestion stops until midnight UTC. Analytics rules cannot detect threats in data that was not ingested. The SOC has no visibility from 14:00 to midnight. This is why daily caps should never be set in production.
Data continues but at reduced quality
Only high-priority data continues
Data is queued for ingestion tomorrow
Daily caps stop ALL ingestion. No exceptions, no queuing, no priority system. The workspace goes blind.
4. What is the key limitation of Basic tier compared to Analytics tier?
Basic tier does not support the join operator or analytics rule evaluation. This means Basic tier data cannot be used for cross-product investigation (which requires joins) or automated detection (which requires analytics rules). Only tables that you never join and never run detection rules against should be on Basic tier.
Basic tier data is deleted after 24 hours
Basic tier cannot be queried at all
Basic tier only stores Microsoft data
No join + no analytics rules = the critical constraints. Basic tier does support limited KQL (where, extend, project, simple summarize) and has 30-day retention.
5. Your ingestion is 150 GB/day. Which commitment tier should you select?
100 GB/day. Set the tier at your minimum consistent daily volume, not average or peak. At 150 GB/day average, some days may drop to 120 GB. The 100 GB tier ensures you benefit from the discount every day. The remaining 50+ GB above the commitment is billed at pay-as-you-go rates.
200 GB/day — always round up
Pay-as-you-go — commitment tiers waste money
500 GB/day — maximum headroom
Minimum consistent daily volume. Over-committing wastes money on days you ingest less. Under-committing is impossible — overage is billed at PAYG rates.
6. A manager asks you to move SigninLogs to Basic tier to save 30% of ingestion cost. What do you do?
Decline. SigninLogs is the foundation of every identity investigation — it is joined with CloudAppEvents, OfficeActivity, AzureActivity, and SecurityAlert. Moving it to Basic removes join capability and analytics rule evaluation. Instead, optimise cost by moving non-security tables (AzureMetrics, ContainerLog) to Basic, or adjusting the Windows Security Event collection level.
Move it — cost saving is significant
Move half the data
Move it to Archive instead
Core investigation tables must stay on Analytics. Optimise cost on tables that do not support security detection.
7. What does the _GetWatchlist() function do in KQL?
Returns the contents of a named watchlist as a KQL table that can be joined, filtered, and used in analytics rules. Watchlists are uploaded as CSV files and provide dynamic reference data (VIP users, approved IPs, high-value assets) without hardcoding values into queries.
Downloads a file from the internet
Creates a new watchlist
Deletes entries from a watchlist
_GetWatchlist() returns watchlist data as a queryable table. Update the CSV to update the data — no query modifications needed.
8. Which threat intelligence source provides the highest confidence indicators with lowest configuration effort?
Microsoft Defender Threat Intelligence (MDTI). Enable the data connector and indicators flow automatically. High confidence because they are curated by Microsoft's security research teams. Lowest effort because no TAXII server configuration, API credentials, or feed management is needed.
STIX/TAXII community feeds
Manual entry by analysts
All sources are equal in confidence
MDTI is Microsoft's curated TI. Highest confidence, lowest effort. Community feeds provide broader coverage but lower confidence and higher false positive risk.
9. You install a Content Hub solution with 15 analytics rule templates. How many rules are actively detecting threats?
Zero. Content Hub deploys templates, not active rules. Each template must be explicitly activated — reviewed, configured, and created as an active rule. This prevents untested rules from generating alerts in your environment.
All 15 — automatically activated
Only high-severity rules
Depends on the solution
Templates require explicit activation. This is by design — review before detection.
10. What is the primary benefit of the unified security operations platform (Sentinel + Defender XDR in Defender portal)?
Single investigation interface with unified incident queue and Advanced Hunting across both Defender XDR and Sentinel data sources. Eliminates portal switching and enables cross-platform KQL queries without the workspace() function.
Sentinel is free in the unified platform
It replaces KQL with a graphical interface
It eliminates the need for data connectors
Unified interface, unified data access, unified incident queue. Sentinel is not free, KQL remains, and connectors are still needed for non-Defender data.
11. Your SigninLogs ingestion dropped to zero 4 hours ago. What is the first thing you check?
The Entra ID data connector status in Sentinel → Data connectors. If the connector shows "Disconnected," reconnect it. If "Connected" with no data, check workspace-level settings (daily cap) and Azure service health. The 4-hour gap is a security blind spot that must be closed as quickly as possible.
The analytics rules — they may be filtering the data
Wait — data may be delayed
Check if users stopped signing in
Connector health is the first check for ingestion drops. Analytics rules do not filter incoming data. 4-hour delays are not normal for Entra ID data.
12. Which Sentinel role should a Tier 1 SOC analyst have?
Microsoft Sentinel Responder. View incidents + triage (assign, change status, run playbooks). Cannot modify analytics rules or data connectors — those are Tier 2/3 tasks.
Reader — view only is sufficient
Contributor — full access for flexibility
Owner — maximum permissions
Responder: view + triage. Reader is too restrictive. Contributor is too permissive for Tier 1.
13. An MSSP manages 10 customer tenants. Should they use one workspace or ten?
Ten — one per customer. Customer data must be isolated for contractual, regulatory, and data protection reasons. RBAC within a single workspace does not provide the data isolation that customer agreements require. Use Azure Lighthouse for delegated access from the MSSP tenant.
One — RBAC separates customer data
Two — one for large customers, one for small
It depends on the data volume
Customer isolation = separate workspaces. Always. This is a non-negotiable MSSP architecture requirement.
14. You need to retain AzureActivity logs for 3 years for SOX compliance. Active investigation needs 90 days. What tier configuration?
Analytics tier with 90-day interactive retention, then Archive for the remaining period to reach 3 years total. First 90 days on Analytics for full KQL investigation. After 90 days, data transitions to Archive for low-cost compliance retention. Restore from Archive if needed for audit.
Analytics tier for 3 full years
Basic tier for 3 years
Archive for the full 3 years
Two-tier: Analytics for active investigation + Archive for compliance retention. Cost-optimal pattern for long-term retention.
15. Your analytics rule references a table on Basic tier. What happens?
The rule fails. Analytics rules cannot evaluate Basic tier data. The rule execution returns an error (or returns zero results if the query silently fails). Move the table back to Analytics tier or rewrite the rule to exclude the Basic tier table.
The rule works but slower
The rule works with limited results
The Basic tier data is automatically promoted to Analytics
Analytics rules do not run against Basic tier. This is the critical constraint for tier selection — never move a table used by analytics rules to Basic.
16. What is a STIX/TAXII feed?
A standardised format (STIX) and transport protocol (TAXII) for exchanging threat intelligence indicators between systems. Many TI providers publish indicators via STIX/TAXII. Sentinel ingests from TAXII feeds through the Threat Intelligence data connector, populating the ThreatIntelligenceIndicator table for automated matching against your log data.
A type of Sentinel analytics rule
A Microsoft proprietary TI format
A data connector for Syslog data
STIX = format, TAXII = transport. Industry standard for TI exchange. Not Microsoft-specific.
17. SecurityEvent accounts for 45% of ingestion. The collection level is "All Events." How do you reduce cost?
Change the collection level to "Common." This retains the security-relevant events (authentication, process creation, privilege changes) while excluding verbose operational events. Typical reduction: 50-70% of SecurityEvent volume. Security investigation capability is preserved because the Common level includes the events used in analytics rules and investigation queries.
Move SecurityEvent to Basic tier
Set a daily cap
Disconnect the Windows Security Events connector
Collection level adjustment is the correct cost optimisation for SecurityEvent. Basic tier removes detection capability. Daily cap stops ingestion. Disconnecting eliminates all Windows security visibility.
18. What is the cross-workspace query function in KQL?
The workspace() function. It queries data from another Log Analytics workspace: workspace("other-workspace-name").SigninLogs. Used in multi-workspace architectures for cross-region correlation. Slower and more expensive than single-workspace queries — use only when necessary.
The union() operator
The join() operator with a workspace parameter
Cross-workspace queries are not possible
workspace() function enables cross-workspace queries. Union and join work within a single workspace by default.
19. When should you use a watchlist instead of hardcoding values in a KQL query?
When the reference data changes over time (VIP users join/leave, IP ranges change, asset lists are updated). Watchlists are maintained in one place — update the CSV, and all queries and analytics rules that reference the watchlist automatically use the current data. Hardcoding requires editing every query when values change.
Only when the list has more than 100 entries
Watchlists are always better than hardcoding
Only for IP addresses, not for user lists
Watchlists for dynamic data that changes. Hardcoding is acceptable for static values that never change (like a specific ResultType code).
20. After completing Module 7, what is the correct description of Microsoft Sentinel's role in security operations?
Sentinel is a cloud-native SIEM + SOAR platform built on Log Analytics. It ingests security data from all sources, stores it in queryable tables, runs analytics rules for automated threat detection, generates incidents for investigation, and automates response through playbooks. It integrates with Defender XDR in the unified security operations platform. The workspace configuration — architecture, log tiers, retention, RBAC, TI, and Content Hub — determines the platform's capability, cost, and effectiveness.
Sentinel is a replacement for Defender XDR
Sentinel is only for Azure resources
Sentinel is a threat intelligence platform
SIEM + SOAR, cloud-native, built on Log Analytics, integrated with Defender XDR. Configuration determines capability. This is the complete description.
