CrowdStrikeCCSE-2045 domains

CCSE-204 Exam Notes

Last-minute traps, must-know facts, and scenario tips for the CrowdStrike Certified SIEM Engineer exam.

General Exam Tips

1.The passing score is 80% — you can only miss about 12 of 60 questions. Treat every question as critical.
2.Read ALL answer options before selecting. Many wrong answers are almost-right: they use the correct tool but for the wrong scenario.
3.Parsing (30%) + Data Ingestion (27%) = 57% of the exam. If you master these two domains you are more than halfway to passing.
4.Scenario questions describe a specific symptom or constraint. Identify the symptom first, then eliminate answers that don't address it directly.
5.When a question involves choosing between a data connector vs Falcon Log Collector, the key discriminator is: cloud/API source = connector, on-premises/syslog source = Log Collector.
6.When a question involves field naming in CPS, ask: does ECS have this field? If yes, use the ECS name. If no, prefix with 'Vendor.'
7.Flag and skip questions you're unsure of. Come back with fresh eyes — there is no penalty for wrong answers so always answer every question.
8.Time management: 90 minutes for 60 questions = 90 seconds per question. Questions with CQL code are slower to read — budget extra time.
9.If two answers both seem correct, look for the one that is more specific to the scenario constraint described in the question.
10.The exam tests engineer-level judgment, not just recall. Ask yourself: what would a SIEM engineer actually do first in this scenario?

Quick Navigation

User Management Data Ingestion Parsing Content Creation Automation and Integration

Domain 17% of exam

User Management

Must-Know Facts

RBAC in Falcon Next-Gen SIEM uses platform-level roles (what features a user can access) AND repository-level access controls (what data a user can see) — both must be configured.
Custom roles must be explicitly created and assigned; there is no automatic role inheritance from organizational hierarchy or default roles.
The NG SIEM Analyst role grants case-reading and XDR-writing permissions but does NOT allow template modifications — this distinction appears in exam scenarios.
Principle of least privilege applies: SOC Tier 1 analysts should be able to query and view dashboards but not edit correlation rules or SOAR workflows.
User permissions affect data visibility, feature access, and what SOAR workflows a user can trigger — not just login capability.
Dormant/inactive accounts with repeated failed login attempts must be disabled promptly — this is a tested security hygiene scenario.

Common Traps

TrapPlatform-level roles control everything a user can do in Falcon

RealityPlatform-level roles control feature access (querying, dashboards, rules). Repository-level access controls are a separate layer that governs which data repositories a user can see. Both must be configured correctly for proper data isolation.

TrapCustom roles inherit permissions from the closest default role

RealityCustom roles start with no permissions. You explicitly add only the permissions required. There is no inheritance from default roles — you build the role from scratch.

TrapAssigning a read-only role prevents analysts from running CQL queries

RealityRead-only does not mean query-restricted. The correct granularity is to grant query and dashboard read permissions while withholding rule-edit and workflow-edit permissions. A blanket read-only role is too restrictive for operational analysts.

Confusing Pairs

Platform-Level RolesRepository-Level Access Controls

Platform roles = what features/actions a user can perform (run queries, edit rules, configure connectors). Repository access = what log data a user can see. An analyst can have query permissions (platform role) but only be able to query one business unit's repository (repository access). Both layers must be configured.

Scenario Tips

If the question asks about:

A SOC Tier 1 analyst needs to view dashboards and run CQL queries but must not modify correlation rules or SOAR workflows.

Answer:

Create a custom role with query and dashboard read permissions, explicitly excluding rule-edit and workflow-edit permissions. Assign to the analyst.

Distractor to avoid:

Assigning the default NG SIEM Analyst role may grant too many or too few permissions for the exact scenario — the exam expects you to recognize that custom roles provide precise granularity.

If the question asks about:

Different SIEM teams should only access log repositories relevant to their business unit.

Answer:

Configure repository-level access controls per team — this is separate from platform roles.

Distractor to avoid:

CQL query restrictions are not an access control mechanism. Platform roles alone cannot restrict data scope — repository-level controls are required.

Last-Minute Facts

1Two separate access control layers: platform roles (features) + repository-level controls (data scope).

2Custom roles: no inheritance, explicitly built from zero permissions.

3NG SIEM Analyst role: can read cases, write XDR, cannot modify templates.

4Dormant accounts with failed logins = security risk = must be disabled.

Domain 227% of exam

Data Ingestion

Must-Know Facts

First-party data (native Falcon telemetry from CrowdStrike products) is automatically ingested and parsed — no connector or parser configuration required.
Third-party data requires either an API-based data connector (for cloud/SaaS sources) or a Falcon Log Collector (for on-premises syslog/file sources).
Falcon Log Collector runs on Windows, Mac, and Linux. It listens for syslog using a configurable port (standard syslog default is 514; deployments commonly use 1514 to avoid requiring root/elevated privileges on Linux) and forwards data to the SIEM via HEC sinks.
HEC (HTTP Event Collector) is the transport endpoint that receives data from the Falcon Log Collector — it is NOT a data source itself.
Data ingest is measured as Average GB/day pre-parsing (before parsing is applied), not post-parsing or monthly totals.
Each Next-Gen SIEM connector has a maximum ingest capacity of 10,000 events per second (EPS).
Default HEC syslog UDP maxEventSize is 2048 bytes (configurable up to 1MB+). Know this number for sizing questions.
Fleet management = centralized management of deployed Falcon Log Collectors (NOT Falcon sensor agents on endpoints).
Third-party connector architecture standard components: source device, transport protocol (syslog/HEC), authentication, parsing pipeline, destination repository.
All Falcon Insight XDR customers receive a 10GB/day free tier for third-party data ingestion. Exceeding this stops ingestion unless extended subscription is active.
On-premises syslog sources require the HTTP Event Connector or Falcon Log Collector — NOT cloud-specific connectors.

Common Traps

TrapA data connector and Falcon Log Collector are interchangeable options for any data source

RealityThey serve fundamentally different ingestion patterns. Data connectors are API-based cloud-to-cloud integrations (for cloud APIs, SaaS platforms). Falcon Log Collector is deployed infrastructure that collects syslog or file-based logs from on-premises systems. Using the wrong method for a source type is a classic exam trap.

TrapHEC is a data source that feeds logs into the SIEM

RealityHEC is a transport mechanism — the HTTP endpoint where data is delivered TO the SIEM. The Falcon Log Collector uses HEC sinks as the delivery channel. HEC is not itself a source of log data.

TrapA healthy connector status confirms events are being ingested correctly

RealityA connector can show healthy connection status while producing zero events in the repository. If events arrive but fail to parse, they disappear silently. When no events appear despite a healthy connection, check the parser assignment and parsing errors first.

TrapFleet management means managing endpoint sensor agents

RealityIn the SIEM context, fleet management refers exclusively to managing Falcon Log Collector deployments — configuration updates, health monitoring, and scaling across multiple collector instances. Do not confuse with Falcon EDR sensor management.

TrapData ingestion volume is measured after parsing runs

RealityIngestion is measured as Average GB/day pre-parsing. Parsing happens after data is ingested. This distinction matters for sizing and billing questions.

Confusing Pairs

Data ConnectorsFalcon Log Collector

Data Connectors = API-based cloud integrations, configured in the Falcon console, no software deployment. Falcon Log Collector = software you deploy on a server, receives syslog/files from on-premises devices, forwards via HEC. Key question: is the source a cloud/SaaS API or an on-premises device sending syslog?

HEC (HTTP Event Collector)Syslog Listener

HEC = the HTTP endpoint the Log Collector sends data TO (output/sink). Syslog listener = where the Log Collector receives data FROM on-premises devices (input, standard port 514, commonly configured to 1514 to avoid root privileges). These are opposite directions in the data flow.

First-Party DataThird-Party Data

First-party = CrowdStrike product telemetry (EDR, identity, cloud), automatically ingested and parsed, no setup needed. Third-party = external tools and devices, requires connector/collector setup AND typically custom parser development.

Scenario Tips

If the question asks about:

Ingesting firewall logs from on-premises Palo Alto devices that send syslog.

Answer:

Deploy a Falcon Log Collector configured to receive syslog (commonly on port 1514 to avoid root-privilege requirements, though the standard syslog port is 514 and the port is configurable), forward via HEC sink to SIEM.

Distractor to avoid:

There is no API-based data connector for an on-premises syslog source. Falcon sensors cannot be installed on firewalls. Federated search queries existing data — it does not collect new data.

If the question asks about:

Connector shows 'Healthy' but no events appear in the target repository.

Answer:

First troubleshooting step: verify the parser is correctly assigned to the data source and check for parsing errors. Events may be arriving but failing to parse.

Distractor to avoid:

Restarting the Log Collector (wrong — this is a connector issue, not a collector issue), recreating API credentials (wrong — healthy status means auth is working), increasing sizing (wrong — that would affect throughput, not silent event loss).

If the question asks about:

A custom application running on-premises needs to send logs directly to the SIEM via HTTP.

Answer:

Configure the application to use the HTTP Event Connector (HEC endpoint), not a data connector or Falcon Log Collector.

Distractor to avoid:

Data connectors are for pulling data from external APIs, not receiving HTTP pushes from custom applications.

Last-Minute Facts

1Max connector ingest capacity: 10,000 EPS per connector.

2Falcon Log Collector syslog: standard default port is 514; commonly configured to 1514 to avoid elevated-privilege requirement on Linux. The exact port is configurable — know the distinction for sizing/config questions.

3Default HEC syslog UDP maxEventSize: 2048 bytes.

4Free ingestion tier for Falcon Insight XDR customers: 10 GB/day (pre-parsing).

5Data ingestion measured: Average GB/day, pre-parsing.

6Falcon Log Collector OS support: Windows, Mac, Linux.

7Retention default: 7 days. Maximum with licensing: 36 months.

8Fleet management = managing Log Collectors, NOT Falcon sensors.

Domain 330% of exam

Parsing

Must-Know Facts

CrowdStrike Parsing Standard (CPS) is based on Elastic Common Schema (ECS) 8.x but has documented deviations and extensions — it is NOT identical to ECS.
Fields that exist in ECS must use the ECS field name. Fields that do NOT exist in ECS must be prefixed with 'Vendor.' (e.g., 'Vendor.fw_action').
CPS requires ALL fields from the raw log to be preserved as LogScale fields — no fields should be dropped, even non-ECS ones.
Vendor. prefix rule: keep field names and values unchanged except replace spaces with underscores in field names.
Mandatory CPS fields that every parser must populate: event.module, event.dataset, event.kind. Additional key fields: event.action, source.ip, user.name.
Parser validation test cases with sample log data are REQUIRED for CPS compliance — a parser without test cases is not CPS-compliant.
Log format recognition is testable: JSON, CSV, syslog RFC 3164 and RFC 5424, CEF (Common Event Format), LEEF (Log Event Extended Format), key-value pairs, XML, unstructured text.
AI-assisted parser generation: useful starting point for structured JSON logs, but always requires manual validation, refinement, and additional test cases before production deployment.
Parser types: build from scratch (full control), clone and modify (good for similar sources), AI-assisted (fastest for structured logs).
Common parser failures: type mismatches (array vs string), invalid enum values for event.outcome, missing mandatory fields, incorrect regex that fails on edge cases.
Parser validation errors are visible in the Validation Errors pane — always check this after creating or modifying a parser.

Common Traps

TrapCPS and ECS are the same standard — what works in ECS works in CPS

RealityCPS is built on ECS 8.x but has documented deviations and CrowdStrike-specific extensions. You cannot assume all ECS rules apply directly. Exam questions test CPS-specific behavior, especially around vendor-prefixed fields and mandatory metadata fields.

TrapNon-ECS fields in raw logs should be dropped because they are not in the standard

RealityNon-ECS fields must be preserved, prefixed with 'Vendor.' The CPS principle is: make ALL raw log fields available as LogScale fields. Dropping fields violates CPS and loses potentially critical forensic data.

TrapAI-generated parsers can be deployed directly to production

RealityAI-assisted parsers are a starting point and typically require manual review, field mapping refinement, and additional test cases for edge cases before they are production-ready. The exam tests whether you know when AI parsers need human review.

TrapA parser is complete once it extracts fields — test cases are optional documentation

RealityParser validation test cases with sample log data are a REQUIRED component of CPS compliance. A parser without test cases is explicitly non-compliant. This is one of the most commonly missed requirements.

TrapCloning an existing syslog parser is the best approach for a new JSON log source

RealityCloning a syslog parser for a JSON source would require extensive modification because the parsing logic differs fundamentally. For structured JSON with consistent fields, AI-assisted generation is the most efficient approach. Clone when the source format is similar to an existing parser.

Confusing Pairs

ECS FieldsVendor-Prefixed Fields

ECS fields = standard Elastic Common Schema fields, use the exact ECS field name (e.g., source.ip, user.name, event.action). Vendor-prefixed fields = any field that has no ECS equivalent, prefixed with 'Vendor.' (e.g., Vendor.fw_action, Vendor.session_duration). Never drop a field — always assign one of these two forms.

Custom Parser (from scratch)AI-Assisted ParserCloned Parser

Custom from scratch = full control, use for unique/complex formats. AI-assisted = fastest for structured JSON/CSV, requires validation. Cloned = best when a new source is similar to an existing parsed source. The exam asks you to identify the MOST EFFICIENT approach for a given scenario.

Parser Validation Test CasesParser Debug Output

Validation test cases = sample log entries with expected field mappings that are bundled WITH the parser, required for CPS compliance. Debug output = the Validation Errors pane shown during development, used to catch issues. Test cases are a compliance artifact; debug output is a development tool.

Scenario Tips

If the question asks about:

A raw log contains a field 'fw_action' that does not exist in ECS. What should the parser do with it?

Answer:

Prefix it as 'Vendor.fw_action' and keep the value unchanged (replacing any spaces with underscores in the name).

Distractor to avoid:

Dropping the field violates CPS. Forcing a semantic mismatch by mapping to the 'nearest' ECS field creates correlation problems. Creating a new top-level ECS field is not permitted by individual parsers.

If the question asks about:

An engineer receives structured JSON logs from an unfamiliar source and needs a parser quickly.

Answer:

Use AI-assisted parser generation with sample logs, then validate and refine the output before deploying.

Distractor to avoid:

Writing from scratch is unnecessary for structured JSON. Cloning a syslog parser would require extensive rewriting. Submitting a request to CrowdStrike delays operations unnecessarily.

If the question asks about:

A parser is producing zero normalized events even though raw logs are arriving at the SIEM.

Answer:

Check the Validation Errors pane for the parser. Common causes: type mismatches, missing mandatory fields, invalid enum values, regex failing to match the actual log format. Verify parser test cases pass with the current log samples.

Distractor to avoid:

The issue is not in data ingestion (logs are arriving). Recreating credentials or restarting the collector won't fix a parsing logic failure.

If the question asks about:

Which parser approach is most efficient when the new source format is nearly identical to an already-parsed source?

Answer:

Clone the existing parser and modify the differing field mappings.

Distractor to avoid:

AI-assisted is faster for novel structures; cloning is faster when similarity is high. Building from scratch is never 'most efficient' when a baseline exists.

Last-Minute Facts

1CPS mandatory fields per parser: event.module, event.dataset, event.kind.

2Non-ECS fields: prefix with 'Vendor.' — never drop, never force-map to wrong ECS field.

3Vendor. prefix rule: replace spaces with underscores in field names, keep values unchanged.

4Parser test cases: REQUIRED for CPS compliance, not optional.

5CPS version: based on ECS 8.x with documented deviations.

6Log formats to recognize: JSON, CSV, syslog (RFC 3164, RFC 5424), CEF, LEEF, key-value, XML, unstructured.

7AI parsers: starting point only — always validate before production.

8Validation Errors pane: primary tool for diagnosing parser problems during development.

Domain 426% of exam

Content Creation

Must-Know Facts

CQL pipe syntax: operations chain left-to-right using '|'. The order matters — filter early, aggregate late for best performance.
In CQL, OR binds closer than AND — opposite of most programming languages. Use parentheses to ensure correct logic: (A AND B) OR C will behave differently than A AND (B OR C).
Field assignment in CQL uses ':=' not '='. The '=' operator is for comparison/filtering. eval(newField := value) creates a new field; field = value filters events.
top(field, limit=N) performs built-in counting and ranking in a single operation — do NOT add groupBy() before top() since top() already handles counting internally.
groupBy(field) deduplicates and counts. stats(count()) aggregates. top(field, limit=N) ranks. All are aggregation functions but serve different use cases.
Correlation rules are persistent detections that run continuously on incoming data and generate alerts. CQL search queries are ad-hoc, on-demand investigations. Both use CQL syntax.
Tuning a correlation rule means modifying its filter logic (adding exclusions, adjusting thresholds, refining time windows) — not disabling it or reducing severity.
Lookup files enrich events with additional context. Referenced in CQL queries and correlation rules using lookup-style joins.
Pre-built dashboards require the underlying data source to be ingested and parsed. A dashboard showing no data is NOT a dashboard error — it indicates the data connector or parser is not configured.
Vendor-native detections (from CrowdStrike modules: EDR, identity, cloud) come with full Falcon context and are already CPS-mapped. External detections (from third-party tools) may require additional parsing.
Correlation rules can be assigned MITRE ATT&CK technique tags and severity levels for triage and reporting context.
CQL key functions to know: groupBy(), stats(count()), top(), eval(), regex(), rename(), replace(), sort(), formatTime(), concat(), ioc:lookup().

Common Traps

TrapCQL uses the same AND/OR precedence as Java, Python, or SQL

RealityIn CQL, OR binds closer than AND. This is the inverse of most programming languages where AND binds closer. Without parentheses, 'A AND B OR C' evaluates as 'A AND (B OR C)', not '(A AND B) OR C'. Always use parentheses in complex boolean expressions.

TrapTo create a calculated field in CQL: field = expression

RealityThe '=' operator filters events (equality comparison). To create a new field you must use eval() with ':=': eval(newField := expression). This is one of the most commonly missed syntax details on the exam.

TrapAdding groupBy() before top() gives more accurate results

Realitytop() already performs counting and ranking internally. Adding groupBy() first is redundant and can actually cause incorrect behavior. top(field, limit=10) is the correct pattern for finding top N values.

TrapA pre-built dashboard showing no data means the dashboard is broken or misconfigured

RealityPre-built dashboards are correct by design. No data means the underlying data connector feeding that dashboard is not configured, or the data source is not ingesting events. Fix the data source, not the dashboard.

TrapTo fix a noisy correlation rule generating false positives, reduce its severity level

RealityReducing severity does not reduce alert volume — it just changes the label. To reduce false positives, add exclusion filters targeting the known-good sources (e.g., exclude a specific scanning server IP). Tuning = logic changes, not severity changes.

Confusing Pairs

Correlation RulesCQL Search Queries

Correlation rules = persistent, run continuously on live data, generate alerts in the detection pipeline, become a detection source. CQL search queries = on-demand, run against historical data when an analyst executes them, return results to the UI. Same syntax, fundamentally different runtime context.

eval() with :== (equals operator)

eval(field := value) creates or assigns a new field value (field creation/assignment). field = value is a filter that retains only events where field equals value. Using '=' where ':=' is needed will filter your events instead of creating a field — a silent bug.

Vendor-Native DetectionsExternal Detection Sources

Vendor-native = generated by CrowdStrike modules (EDR, identity, cloud security), automatically appear with full Falcon context, already CPS-normalized. External = forwarded from third-party tools (other EDRs, firewalls, cloud security platforms), may need additional parsing and normalization, less Falcon context.

top(field, limit=N)groupBy(field)

top() = aggregates AND ranks in one step, use for 'find the top N'. groupBy() = aggregates and counts but does not rank, use when you want all group counts without ranking. Adding groupBy before top() is redundant and incorrect.

Scenario Tips

If the question asks about:

Find the top 10 source IP addresses with the most failed login events in the last 24 hours.

Answer:

Filter first, then use top(): #event_simpleName=UserLogonFailed | top(src_ip, limit=10)

Distractor to avoid:

Adding groupBy(src_ip) before top() is redundant since top() handles counting. sort() does not limit results to 10. stat(count()) by itself doesn't rank.

If the question asks about:

A correlation rule fires alerts on a known internal scanning server, generating false positives.

Answer:

Add an exclusion filter for the scanning server's IP address to the rule's CQL logic.

Distractor to avoid:

Disabling the rule removes all detection coverage. Reducing severity to low still fires the same volume of alerts. Deleting historical alerts does not prevent future ones.

If the question asks about:

Create a calculated field 'connection' that combines source IP and destination port as 'IP:port'.

Answer:

| eval(connection := concat(src_ip, ":", dst_port))

Distractor to avoid:

connection = src_ip + ":" + dst_port uses '=' which is a filter, not a field creator. rename() changes a field's name, not its value. replace() substitutes substrings within a value.

If the question asks about:

A pre-built dashboard for firewall traffic shows no data after a new deployment.

Answer:

The data connector for the firewall source is likely not configured or not ingesting data. Configure the connector and verify events are arriving before investigating the dashboard itself.

Distractor to avoid:

The dashboard is not broken — pre-built dashboards are correct by design. Rebuilding the dashboard or changing widget types will not fix an ingestion problem.

Last-Minute Facts

1CQL operator precedence: OR binds closer than AND (inverse of most languages).

2Field assignment syntax: eval(field := value) — NOT field = value.

3top(field, limit=N): counts and ranks in one step, do not prepend groupBy().

4Correlation rules = persistent, run on live incoming data, generate alerts automatically. CQL queries = ad-hoc, run on demand against stored data. Exam trap: a correlation rule CANNOT replace an ad-hoc investigation and vice versa — the trigger context is different.

5Tuning = add exclusion filters, adjust thresholds. NOT reduce severity or disable.

6Pre-built dashboards require properly configured data connectors — no data = data source problem.

7Lookup files: enrichment reference data, referenced in CQL and correlation rules.

8ioc:lookup() = CQL function for IOC feed correlation in queries and rules.

91,000+ correlation rule templates available in CrowdStrike catalog.

Domain 510% of exam

Automation and Integration

Must-Know Facts

Falcon Fusion SOAR is a no-code visual workflow builder — it does NOT require programming. API integrations via FalconPy are a separate, code-based capability.
Falcon Fusion SOAR workflow trigger types: event-triggered (fires on correlation rule detection), scheduled (runs on a time schedule), and on-demand (manually launched).
Built-in SOAR action types: contain host, send email notification, create Jira ticket, write to log, query device list, execute custom HTTP actions.
HTTP Actions in SOAR support three authentication methods: API keys, OAuth 2.0, and CrowdStrike-specific authentication.
Falcon Fusion SOAR is available at no additional cost for first-party automation. Advanced third-party orchestration requires Next-Gen SIEM licensing.
FalconPy SDK authentication: OAuth 2.0 using Client ID and Client Secret — not username/password, not API-key-only.
FalconPy automatically manages OAuth token refresh. You provide Client ID and Client Secret once; token management is handled by the SDK.
FalconPy Service Classes: one class per API collection (e.g., Detections, Hosts, Incidents) — most specific interface for a known API.
FalconPy Uber Class: single class interface to all API operations — convenient but less type-specific.
SOAR workflows are configured separately from correlation rules. A rule generates detections; a workflow reacts to those detections. They are linked by trigger configuration, not embedded in each other.
API credentials (Client ID and Client Secret) are generated in the Falcon console under API Clients section. Scope permissions to least privilege.

Common Traps

TrapFalcon Fusion SOAR workflows are built by writing Python or automation scripts

RealityFalcon Fusion SOAR is explicitly no-code — workflows are built using a visual drag-and-drop builder with pre-built action blocks. Python (via FalconPy) is for programmatic API integration, not for building SOAR workflows.

TrapFalconPy requires you to manually refresh OAuth tokens in your code

RealityFalconPy handles OAuth token management automatically. You initialize with Client ID and Client Secret, and the SDK transparently fetches and refreshes tokens. This is a tested differentiator — you provide credentials once, not manage token lifecycle.

TrapCorrelation rules directly execute response actions like containment when they fire

RealityCorrelation rules generate detections/alerts — they do not execute response actions themselves. Response actions are handled by Falcon Fusion SOAR workflows that are triggered BY the correlation rule detection. The rule and the workflow are separate components.

TrapThe Uber Class is always the best FalconPy choice because it accesses all APIs

RealityService Classes are more appropriate when you know exactly which API collection you need — they provide a focused, type-specific interface. The Uber Class is more convenient for broad API access but is less specific. The exam distinguishes these use cases.

Confusing Pairs

Falcon Fusion SOAR (No-Code)FalconPy SDK (Python Code)

SOAR = visual workflow builder for automating response actions, no programming needed, triggered by detections or schedules. FalconPy = Python SDK for programmatic API access, requires writing code, used for custom integrations and querying the Falcon API. Choose SOAR for operational response playbooks; choose FalconPy for custom scripts and integrations.

FalconPy Service ClassFalconPy Uber Class

Service Class = one class per API collection, most specific, best when you know which API you need (e.g., only need Detections API). Uber Class = single interface to all API collections, convenient for broad access, less type-specific. Exam typically asks for the 'simplest' or 'most focused' interface for a specific API task.

Scenario Tips

If the question asks about:

Automatically contain a host and create a Jira ticket when a critical correlation rule fires.

Answer:

Create a Falcon Fusion SOAR workflow triggered by the correlation rule detection with two actions: contain host and create Jira ticket.

Distractor to avoid:

Writing a FalconPy polling script introduces delay and complexity. Correlation rules cannot directly execute containment. CQL queries cannot call external APIs.

If the question asks about:

Write a Python script to query the Falcon API specifically for recent detections.

Answer:

Use the FalconPy Service Class for the Detections API collection — it provides the most focused interface for this specific use case.

Distractor to avoid:

The Uber Class works but is less specific. Manual REST calls require managing OAuth tokens yourself. SOAR is no-code, not a Python SDK.

If the question asks about:

A SOAR workflow needs to integrate with an internal ticketing system via HTTP. What authentication methods are available?

Answer:

HTTP Actions in SOAR support three methods: API keys, OAuth 2.0, and CrowdStrike-specific authentication.

Distractor to avoid:

Basic username/password is not a listed method for SOAR HTTP Actions. SAML is not used here.

Last-Minute Facts

1Falcon Fusion SOAR: no-code, visual builder, three trigger types (event, scheduled, on-demand).

2SOAR available free for first-party automation; third-party SOAR requires NG-SIEM licensing.

3FalconPy auth: OAuth 2.0 Client ID + Client Secret — SDK handles token refresh automatically.

4FalconPy Service Class = per-API collection, most focused. Uber Class = all APIs, one interface.

5SOAR and correlation rules are separate: rules detect, workflows respond.

6SOAR built-in actions: contain host, email, Jira ticket, log write, device query, HTTP action.

7HTTP Action auth methods: API keys, OAuth 2.0, CrowdStrike-specific.

8API credentials generated in Falcon console, scoped to least privilege.

Feeling confident?

Put your knowledge to the test with a timed CCSE-204 mock exam.