Quick Navigation
Platform Overview and User Management (7%)Data Ingestion — Source Types (27%)Falcon Log Collector — ConfigurationCrowdStrike Parsing Standard (CPS) — 30%Parser Development — Custom LogicCQL (CrowdStrike Query Language) — Syntax and OperatorsCQL — Aggregation and FunctionsContent Creation — Dashboards and Lookup Files (26%)Content Creation — Correlation Rules (26%)Falcon Fusion SOAR — Automation and Integration (10%)FalconPy SDK — API IntegrationTroubleshooting — Ingestion and ParsingKey Exam Distinctions and Traps
Platform Overview and User Management (7%)
- RBAC (Role-Based Access Control)
- Assign predefined or custom roles to control what each user can see and do in Falcon Next-Gen SIEM; roles are additive and can be combined.
- Custom Role Creation
- Build granular roles tailored to team needs — for example, a SOC Tier 1 role with query/dashboard read access but no correlation rule or SOAR edit rights.
- Repository-Level Access Control
- Separate from platform roles; controls which data repositories each user or team can access, enabling multi-tenant data isolation.
- Platform Role vs. Repository Access
- Platform roles govern feature access (queries, rules, SOAR); repository access governs data visibility — both must be configured independently.
- Principle of Least Privilege
- Grant users only the minimum permissions required for their job function; never assign administrator roles to analysts who only need query access.
- API Authentication Credentials (OAuth 2.0)
- Client ID and Client Secret pairs generated in the Falcon console grant programmatic API access; scope each credential to only the required API collections.
- No Automatic Role Inheritance
- Custom roles must be explicitly created and assigned to users — roles do not inherit from organizational hierarchy or parent roles automatically.
- User Permissions Beyond Login
- Platform roles control access to features, dashboards, SOAR workflows, and data sources — not just login; a user with login access but insufficient role cannot view dashboards or trigger workflows.
Data Ingestion — Source Types (27%)
- First-Party Data
- Native Falcon telemetry from CrowdStrike products (EDR, identity, cloud security); automatically ingested, normalized, and parsed without additional configuration.
- Third-Party Data
- External data from firewalls, cloud services, network devices, and other security tools; requires configuring connectors or deploying log collectors plus custom parsers.
- Data Connectors (API-Based)
- Cloud-to-cloud integrations that pull data from SaaS/cloud APIs (AWS, Azure, Okta, etc.) directly into Falcon Next-Gen SIEM with built-in authentication and scheduling.
- Falcon Log Collector (On-Premises)
- Software deployed on Windows, macOS, or Linux to collect syslog and file-based logs from on-premises sources and forward them to SIEM via HEC sinks.
- Sensor-Native Log Collection
- Uses existing Falcon endpoint sensors to collect and forward logs, eliminating the need to deploy separate Falcon Log Collector infrastructure.
- Connector vs. Log Collector Decision
- Use data connectors for cloud/API-accessible sources; use Falcon Log Collector for on-premises or syslog-only sources — do not confuse the two methods.
- HEC is NOT a Data Source
- HEC (HTTP Event Collector) is the transport endpoint that receives data forwarded by collectors — it is not a data source itself; the actual source is the syslog sender or API connector upstream.
Falcon Log Collector — Configuration
- Syslog UDP Source (port 1514)
- Configure a syslog_udp source in the collector config to receive UDP syslog from network devices; default listening port is 1514.
- Syslog TCP Source (port 1514)
- Configure a syslog_tcp source for reliable TCP syslog delivery; preferred over UDP when log integrity is required.
- HEC Sink Configuration
- The collector forwards events to Falcon Next-Gen SIEM via an HTTP Event Collector sink; requires a token and the CrowdStrike ingest endpoint URL.
- HEC Sink Example
- type: humio-hec, token: <HEC_TOKEN>, url: https://<tenant>.us-1.crowdstrike.com — the sink delivers data over HTTPS.
- Log Collector Sizing (EPS)
- Scale CPU, memory, disk, and network resources based on target events-per-second throughput; undersizing causes event drops, not backpressure.
- Fleet Management
- Centralized management of all deployed Falcon Log Collectors — push config updates, monitor health, and scale deployments from the Falcon console.
- Fleet vs. Sensor Management
- Falcon Log Collector fleet management controls log collector agents, NOT Falcon endpoint sensors — these are entirely separate management planes.
CrowdStrike Parsing Standard (CPS) — 30%
- CPS (CrowdStrike Parsing Standard)
- Data normalization schema based on Elastic Common Schema (ECS) 8.x with CrowdStrike-specific deviations and extensions that standardize fields across all log sources.
- CPS vs. ECS
- CPS is based on ECS 8.x but is NOT identical — it has documented deviations, additional CrowdStrike-specific fields, and stricter parser metadata and test-case requirements.
- Vendor-Prefixed Fields
- Fields with no ECS equivalent are prefixed with 'Vendor.' (e.g., Vendor.fw_action) to maintain clean namespace separation — they are NEVER dropped.
- All Raw Fields Must Be Preserved
- Every field present in the raw log must be surfaced as a LogScale field; CPS compliance requires no data loss even for non-ECS fields.
- Parser Validation Test Cases
- CPS-compliant parsers must include sample log entries as test cases to verify correct field extraction and normalization — parsers without tests are non-compliant.
- Log Format Recognition
- Identify the source format before building a parser: JSON, CSV, syslog RFC 3164/5424, CEF, LEEF, key-value pairs, XML, or unstructured text each require different extraction logic.
- Cloning an Existing Parser
- Duplicate an existing parser as a starting point for a similar log source; modify field mappings and test cases rather than building from scratch.
- AI-Assisted Parser Generation
- Submit sample log data to the AI Parser feature to auto-generate a parser configuration; always validate and refine AI output before production deployment.
Parser Development — Custom Logic
- Regex Field Extraction
- Use regex patterns to extract fields from unstructured log text; capture group names become LogScale field names in the parser output.
- Regex Pattern Example
- /src=(?P<source_ip>[\d.]+) dst=(?P<dest_ip>[\d.]+)/ — named capture groups map directly to LogScale fields.
- Conditional Parsing Logic
- Use conditional branches in parser logic to handle multiple log formats from the same source (e.g., syslog messages with different severity indicators).
- Field Assignment in Parsers
- Assign parsed values to CPS-compliant field names (e.g., map raw 'src' to ECS 'source.ip') and prefix non-ECS fields with 'Vendor.'.
- AI Parser vs. Custom Parser
- AI-assisted parsers are fastest for structured JSON with consistent fields; custom parsers give full control for complex or multi-format unstructured logs.
- Parser Troubleshooting
- Events arriving but not appearing in results usually indicates a parsing failure — check parser error logs, validate test cases, and confirm field mapping.
CQL (CrowdStrike Query Language) — Syntax and Operators
- CQL Pipe Syntax
- Queries chain operations with pipe operators; each stage transforms the result set: filter | aggregate | transform | visualize.
- Basic Filter Query
- #event_simpleName=UserLogonFailed | src_ip=* — filter to event type then further restrict by field value using pipe-chained expressions.
- OR Binds Closer Than AND
- In CQL, 'A AND B OR C' evaluates as 'A AND (B OR C)' — use explicit parentheses to enforce intended logic when combining AND/OR operators.
- Field Assignment: := vs. =
- Use := to create/assign a new field (eval); use = for comparison/filtering — confusing these two is the most common CQL mistake on the exam.
- Wildcard and Regex Matching
- field=* matches any value; use regex() function for pattern matching: | regex("pattern", field=src_ip)
- Time Range Filtering
- Specify time ranges to limit query scope and improve performance; queries without time bounds scan all retained data.
- Comment Syntax
- Use // for single-line comments and /* ... */ for multi-line comments inside CQL queries.
CQL — Aggregation and Functions
- top() — Ranked Frequency
- | top(src_ip, limit=10) — counts occurrences of each value and returns the top N; handles both grouping and ranking in a single operation.
- groupBy() — Deduplication/Grouping
- | groupBy(user.name) — groups events by field value and counts; use when you need grouped results without limiting to top N.
- stats() — Statistical Aggregation
- | groupBy(src_ip, function=stats(count())) — combines grouping with aggregate statistics such as count, sum, avg, min, max.
- eval() — Calculated Fields
- | eval(connection := concat(src_ip, ":", dst_port)) — creates a new field from an expression; always uses := for field assignment.
- rename() — Field Renaming
- | rename(field=old_name, as=new_name) — renames an existing field without changing its value.
- replace() — Substring Substitution
- | replace("pattern", with="replacement", field=field_name) — substitutes regex matches within a field value.
- formatTime() — Time Formatting
- | formatTime("yyyy-MM-dd HH:mm:ss", field=@timestamp) — formats a timestamp field into a human-readable string for display.
- sort() — Result Ordering
- | sort(field=count, order=desc, limit=100) — sorts result rows by a field in ascending or descending order.
Content Creation — Dashboards and Lookup Files (26%)
- Lookup Files
- Reference data files (CSV) uploaded to Falcon Next-Gen SIEM for enriching events with additional context such as IP reputation or asset metadata.
- Lookup File Usage in CQL
- | match(file="lookup_name.csv", field=src_ip, column=ip) — enriches events by joining on a field value from the uploaded lookup file.
- IOC Lookup in CQL
- | ioc:lookup(field=src_ip, type="ip_address") — checks a field value against CrowdStrike IOC intelligence directly within a CQL query.
- Pre-Built Dashboards
- CrowdStrike-provided dashboards for common use cases; require the underlying data connector to be active — if the source data is missing, the dashboard shows no data.
- Custom Dashboard Widgets
- Bind a CQL query to a widget (table, bar chart, time series, pie chart, stat) to visualize data; widgets update in real time or at a configured refresh interval.
- Dashboard Drill-Down
- Configure interactive click-through on dashboard widgets to filter to relevant events in the event search view for deeper investigation.
Content Creation — Correlation Rules (26%)
- Correlation Rule vs. CQL Query
- Correlation rules are persistent, always-on detections that fire alerts automatically; CQL queries are ad-hoc investigations run on demand — both use CQL syntax.
- Creating a Correlation Rule
- Define CQL-based detection logic, set severity, assign MITRE ATT&CK technique, configure alert actions, and save — the rule runs continuously against incoming data.
- MITRE ATT&CK Tagging
- Assign ATT&CK tactic and technique IDs to correlation rules to enable threat-framework-based filtering and reporting in the Falcon console.
- Correlation Rule Tuning
- Reduce false positives by adding exclusion filters (e.g., exclude known scanner IPs), adjusting time windows, or raising thresholds — never disable a rule to stop false positives.
- Exclusion Filter Example
- Add 'NOT src_ip=10.1.2.3' to a correlation rule's CQL logic to suppress alerts from a known internal scanning host.
- Vendor-Native Detections
- Alerts generated by CrowdStrike Falcon modules (EDR, identity, cloud) are auto-mapped to CPS with full Falcon context; no parser configuration required.
- External Detection Sources
- Detections forwarded from third-party tools (other EDRs, firewalls, SIEMs) via connectors or log collectors; may require additional parsing and normalization.
- Correlation Rule Templates
- Over 1,000 pre-built CrowdStrike-authored detection templates covering endpoint, cloud, network, and identity; clone and customize rather than build from scratch.
Falcon Fusion SOAR — Automation and Integration (10%)
- Falcon Fusion SOAR
- No-code visual workflow automation engine for orchestrating investigation and response actions triggered by detections, schedules, or manual execution.
- Workflow Trigger Types
- Three trigger modes: event-triggered (fires on a detection or alert), scheduled (runs on a cron-like schedule), and on-demand (manually launched by an analyst).
- Built-In SOAR Actions
- Native actions include: contain host, run RTR command, create Jira ticket, send email/Slack notification, query events, update detection status, and write to a log.
- HTTP Action Authentication
- SOAR HTTP actions support three auth methods: API key in header, OAuth 2.0 client credentials, and CrowdStrike-specific token — enabling integration with external tools.
- SOAR vs. FalconPy
- Falcon Fusion SOAR is no-code (visual builder); FalconPy SDK requires Python code — use SOAR for automated playbooks, FalconPy for custom programmatic integrations.
- SOAR Workflow Generation Agent
- Natural-language AI feature that generates SOAR workflow definitions from a text description; generated workflows still require valid API credentials and testing.
- SOAR and Correlation Rules
- SOAR workflows can be triggered by correlation rule detections but are configured separately from the rule — the rule fires the detection, the workflow handles the response.
FalconPy SDK — API Integration
- OAuth 2.0 Authentication
- All CrowdStrike APIs use OAuth 2.0 with Client ID and Client Secret — never username/password or static API keys for production integrations.
- FalconPy Service Class
- Per-API-collection class (e.g., Detections, Hosts, Incidents) providing type-safe, focused access to a specific API; preferred for single-API integrations.
- FalconPy Uber Class
- Single interface (APIHarnessV2) that provides access to all Falcon API collections through one authenticated object; convenient for multi-API scripts.
- Service Class Example
- from falconpy import Detections; falcon = Detections(client_id="ID", client_secret="SECRET") — instantiate and FalconPy manages OAuth tokens automatically.
- Automatic Token Management
- FalconPy handles OAuth token acquisition and renewal automatically after initial credential supply — do not implement manual token refresh logic.
- API Credential Scoping
- Scope each API Client to only the resource types and permissions (read/write) required; follow least privilege for programmatic credentials.
Troubleshooting — Ingestion and Parsing
- Connector Healthy — No Events
- If a connector shows connected status but no events appear, check parser assignment and parser error logs — events may be arriving but failing to normalize.
- Log Collector — Missing Events
- Check EPS throughput vs. collector sizing (undersizing drops events), verify syslog source IP/port binding, and confirm HEC sink token validity.
- Authentication Failure Symptom
- A connector with authentication errors shows unhealthy/disconnected status — not missing events with a healthy status; regenerate credentials and re-test.
- Parser Error Debugging Workflow
- Submit sample log lines to the parser test harness, check field extraction output, validate CPS field names, and confirm Vendor. prefix on non-ECS fields.
- HEC Token Validation
- Test the HEC sink token and ingest URL with a curl command to confirm connectivity before troubleshooting the log collector configuration.
- Fleet Collector Health Monitoring
- Use fleet management in the Falcon console to view per-collector status, EPS throughput, error rates, and last-seen timestamps for all deployed log collectors.
Key Exam Distinctions and Traps
- top() is NOT the same as groupBy() + sort()
- top() performs counting and ranking in one step and is more efficient; do not prepend groupBy() before top() as top() already handles aggregation.
- eval() field creation syntax
- | eval(new_field := expression) — the := operator creates a new field; using = (equals) performs a filter comparison, not field assignment.
- CPS does NOT drop non-ECS fields
- Non-ECS fields must be preserved with 'Vendor.' prefix — a parser that silently drops unknown fields is NOT CPS-compliant.
- AI parsers require validation before production
- AI-generated parsers are starting points only; they require manual review, refinement, and confirmed test cases before being deployed to a production data source.
- SOAR requires no coding; FalconPy requires Python
- Falcon Fusion SOAR automation is built with a no-code visual builder; FalconPy SDK integrations are Python scripts — these serve different automation needs.
- Pre-built dashboards need active data sources
- A pre-built dashboard showing no data is NOT a dashboard configuration error — it means the underlying data connector has not been configured or is not ingesting data.
- 80% passing threshold — every question counts
- With 60 questions and an 80% passing score, you can miss at most 12 questions — Parsing (30%) and Data Ingestion (27%) must be mastered first.