Final assessment (12 questions)
1. You have budget for 20 GB/day. Which data sources give you the most detection coverage?
M365 Defender (~10 GB) + Entra ID (~2 GB) + Azure Activity (free) + Office 365 audit (free) = ~12 GB billable. Enables the widest range of pre-built and custom detections with 8 GB of headroom.
Firewalls — maximum volume
Windows Event Logs from all servers
Detection value per GB is highest for identity and email data. Microsoft sources work with hundreds of pre-built Content Hub detections immediately. Firewalls require custom rules before producing alerts.
2. Your firewall generates 50 GB/day. 80% is permitted traffic. What is the first cost optimization?
A DCR that filters to denied traffic, IDS alerts, and authentication events — dropping ~40 GB/day before ingestion. Monthly savings: ~$6,624.
Move CommonSecurityLog to Basic tier
Reduce retention to 30 days
DCR filtering eliminates cost at the source. Basic tier reduces cost on ingested data but still pays per GB. Retention does not reduce ingestion cost. DCR first, then Basic tier on the remainder.
3. You need MailItemsAccessed data. Which connector?
M365 Defender
Office 365 — OfficeActivity table
Entra ID
MailItemsAccessed lives in OfficeActivity (Office 365 connector). CloudAppEvents (Defender connector) captures inbox rules and app events. Both required for complete investigation coverage.
4. A DCR drops 40 GB/day of firewall data. An investigation needs the dropped data. Options?
Restore from Sentinel archive
Re-ingest from backup
DCR-dropped data was never ingested. Check the firewall's local log retention (typically 7-30 days). If the event falls within that window, retrieve from the device. If not, the data is permanently gone.
DCR filtering is irreversible from Sentinel's perspective. The source device's local storage is the only recovery path. Include device-side retention in your DCR filtering strategy.
5. Why choose CEF over Syslog format?
CEF provides structured fields (SourceIP, DeviceAction) queryable with standard KQL. Syslog requires parse/extract — more complex, error-prone, and slower at scale.
CEF uses less bandwidth
CEF is more secure
Structure = queryability. Filtering by SourceIP is a column operation in CEF. In Syslog, it requires regex parsing against raw text.
6. CommonSecurityLog shows zero events. Green connector status. First diagnostic step?
SSH to forwarder, run tcpdump on port 514. Packets arriving = problem is Zone 2/3. No packets = problem is the source device.
Recreate the connector
Wait 24 hours
Start at the source, work downstream. tcpdump halves your troubleshooting scope in one command.
7. A colleague modified a DCR yesterday. Today, zero data in the target table. No errors. What happened?
DCR syntax error silently drops all data. No error messages, no alerts. Revert the transformation and verify data flows.
The table was deleted
The firewall stopped
Silent DCR failures are one of the most dangerous failure modes. Version-control your transformations and test changes in a dev workspace.
8. Your forwarder VM disk is 95% full. Root cause and risk?
rsyslog is buffering because AMA cannot send (network, crash, or throttle). At 100%, rsyslog drops events = data loss. Fix the AMA connection; the buffer drains automatically.
Normal behavior — resize the disk
Too many log files
Full disk = imminent data loss. This is an emergency. Fix the delivery problem (AMA), not the symptom (disk).
9. Your custom web app can POST JSON. Simplest ingestion approach?
Logs Ingestion API — custom table + DCR + app registration. No forwarder, no Functions, no CCP.
CCP connector
Syslog forwarder
When the source can POST, the Logs Ingestion API is always simplest. Zero additional infrastructure.
10. Volume anomaly query shows SigninLogs at -85%. Priority?
Highest priority — fix immediately. Every minute without sign-in data means token replay, brute force, and impossible travel detections are blind.
Medium — investigate during the next maintenance window
Low — other tables are still flowing
Data drops are the highest-priority operational issue. Your security posture degrades silently. Fix ingestion gaps before building new detections, tuning rules, or anything else.
11. Why run monitoring queries weekly instead of relying on the connector status page?
The connector status page shows "Connected" even when data has stopped flowing (Problem 1 in 6.6). The status indicates the connector configuration exists — not that data is actually arriving. Only table-level queries confirm actual data flow.
The status page updates too slowly
Queries are more accurate for billing
Connector status and actual data flow are different things. A "Connected" status with zero events is the most dangerous failure mode — you believe you have coverage when you do not. Table-level queries are the only reliable health check.
12. What is the detection-first principle and why does it matter for cost management?
Before connecting a data source, identify the specific analytics rules or investigation workflows that will use it. Data without detections is ingestion cost with no security return. This prevents the common failure of ingesting terabytes that no rule ever queries.
Build detections before deploying Sentinel
Only connect free data sources
The detection-first principle ties cost to value. Every GB of ingestion should have a detection purpose. "We might need it" is not a purpose. "We will detect DNS tunneling with this data" is.
