General Exam Tips
- 1.Read ALL answer options before choosing — many questions are designed so the first plausible option is wrong, and the correct one requires understanding nuance
- 2.No penalty for wrong answers — never leave a question blank; guess if you must
- 3.Drag-and-drop and multi-select questions count as single questions — read the instructions carefully before committing your answer
- 4.When stuck between two answers, ask: does this preserve telemetry? Does this follow least privilege? The option that maintains visibility and uses minimum permissions is usually correct
- 5.Policy questions almost always hinge on 'first match wins, not most restrictive wins' — watch for answer options that incorrectly say the more restrictive or more specific policy applies
- 6.Any question about remote access to an endpoint requires BOTH conditions to be true: the right policy setting AND the right user role — if the question omits one, the answer is that the missing condition is the problem
- 7.Dashboard and UI-specific questions trip up many candidates — study the exact console section names (Activity, Investigate, Configuration, Support and Resources) and what lives under each
- 8.When a question describes a false positive scenario, the correct answer always involves creating an exclusion, not just closing the alert
- 9.Sensor questions that mention 'not working' or 'limited' on Linux almost always point to kernel compatibility and RFM, not a misconfigured CID
Quick Navigation
Policy Configuration and Management
Must-Know Facts
- Cloud ML and sensor ML are completely independent slider settings — each has its own levels (Disabled, Cautious, Moderate, Aggressive, Extra Aggressive) and each must be configured separately
- When a host is offline, ONLY sensor ML can analyze files — cloud ML requires an active CrowdStrike cloud connection
- Policy precedence = the first policy in the ordered list whose host group matches the host — NOT the most restrictive, NOT the most specific, the first match wins
- Every policy type has a default policy that catches hosts not covered by any other policy assignment — always configure defaults with at least a baseline security posture
- Containment blocks ALL outbound traffic except to CrowdStrike cloud — IP exclusions must be set BEFORE containment if critical services (DNS, SIEM) need to remain reachable
- Device control targets USB mass storage class by default — keyboards, mice, and audio USB devices are NOT blocked unless explicitly configured
- Firewall rules are evaluated top-down with first match wins — a broad ALLOW above a narrow DENY permits the traffic
- Response policy enables RTR on the endpoint side — but RTR role must also be assigned to the user; both are required (see user-access-management domain for RTR role details)
- Sensor update policy stages: N (latest, test environments), N-1 (standard production), N-2 (critical/conservative servers)
Common Traps
Confusing Pairs
Scenario Tips
A host belongs to the 'Servers' group (Policy A, ranked #1) and the 'Critical' group (Policy B, ranked #3). The question asks which policy applies.
Policy A applies because it has higher precedence (rank #1). Rank position is the only deciding factor — not the name, not restrictiveness, not group specificity.
Policy B because Critical servers should have stricter policy. Wrong — precedence is determined by list position, not semantics.
A laptop goes offline and encounters a never-before-seen malware sample. Cloud ML is set to Aggressive, sensor ML to Moderate. What happens?
Sensor ML at Moderate analyzes the file. Cloud ML is unavailable — it requires CrowdStrike cloud connectivity. The sensor provides the only protection.
Cloud ML at Aggressive level because it is the highest configured. Wrong — cloud ML requires connectivity; offline hosts can only use sensor ML.
A contained host needs to reach the internal ticketing system at 192.168.1.100 during incident response. How is this achieved?
Add 192.168.1.100 as a containment IP exclusion BEFORE containing the host. IP exclusions allow specific IPs to remain reachable during network isolation.
Lift containment, add the rule, then re-contain. This creates a gap in isolation. IP exclusions should be pre-configured before initiating containment.
A new script-based attack is being enabled in Prevent mode before any tuning. What is the correct practice?
Enable in Detect mode first. Monitor for false positives over a tuning period. Only switch to Prevent after confirming legitimate tools are not affected.
Enable in Prevent mode immediately since Detect doesn't stop attacks. Wrong — false positives in Prevent mode can block critical business applications.
Last-Minute Facts
Sensor Deployment and Management
Must-Know Facts
- Windows sensor requires no reboot after installation — protection begins immediately
- macOS requires a system extension approval (SEXT) via MDM profile deployed BEFORE the sensor — without it, the sensor runs in Reduced Functionality Mode
- Linux requires kernel compatibility verification before deployment — the sensor version must support the running kernel; incompatible kernels trigger RFM
- Uninstalling the sensor requires an uninstall token retrieved from the Falcon console — this anti-tamper protection prevents adversaries from disabling endpoint coverage
- CID (Customer ID) includes a checksum suffix — the full CID+checksum is required during installation for the sensor to register to the correct tenant
- RFM (Reduced Functionality Mode) means the sensor is installed and running but with limited capability — it is NOT the same as the sensor being offline or unregistered
- Large-scale deployment tools: GPO, SCCM/MECM, Intune (Windows), Jamf/Intune (macOS), Ansible/Puppet/Chef (Linux)
Common Traps
Confusing Pairs
Scenario Tips
Multiple Linux hosts appear in the console with RFM status after a fresh sensor deployment. What is the most likely cause?
The running Linux kernel version is not supported by the installed sensor version. RFM on Linux is almost always a kernel compatibility issue. Check the sensor support matrix and either update the kernel or downgrade the sensor version.
The CID was entered incorrectly. Wrong — an incorrect CID would prevent registration entirely; the host would not appear in the console at all.
An IT team deploying to macOS via Jamf reports sensors are installing but operating in RFM. What was missed?
The PPPC and System Extension MDM profiles were not deployed before the sensor installation. The MDM profile must be pushed via Jamf BEFORE the sensor is installed so macOS auto-approves the extension.
A reboot is required on macOS after installation. Wrong — no reboot is required. The issue is the missing MDM approval profile.
An administrator tries to uninstall the sensor from a Windows laptop but the command fails with an access denied error. What is needed?
An uninstall token generated from the Falcon console (Support and Resources or Host Management section). The token must be provided as a parameter to the uninstall command to bypass the anti-tamper protection.
Run the uninstall as a local administrator. Wrong — even with local admin rights, the anti-tamper mechanism requires the console-generated token.
Last-Minute Facts
User and Access Management
Must-Know Facts
- RTR Active Responder and RTR Administrator are different roles — Administrator is a superset with additional write capabilities including custom scripts, file uploads, and put commands
- Roles are additive — a user assigned both Analyst and Administrator roles has the combined permissions of both
- RTR requires TWO conditions: the response policy must have RTR enabled AND the user must have an RTR role — one condition alone is insufficient
- API clients use OAuth2 and have granular scopes (read vs. write per resource type) — a client with Hosts:Read cannot modify host groups; it needs Host Groups:Write
- SSO/SAML: always maintain at least one local administrator account for break-glass access — if the IdP goes down, all SSO users lose access
- API client scopes follow least privilege — assign only the scopes the client actually needs, not a broad 'admin' scope
Common Traps
Confusing Pairs
Scenario Tips
A user reports they can view detections and investigate alerts but cannot start an RTR session on a host. RTR is enabled in the response policy. What is the cause?
The user does not have an RTR role (Active Responder or Administrator) assigned to their account. Both the policy setting and the user role are required — the policy alone does not grant access.
The host must be contained first before RTR can be used. Wrong — containment is not a prerequisite for RTR.
A script needs to automate creation of new host groups based on CMDB data. What API scope is needed?
Host Groups: Write scope. Creating or modifying host groups requires write access to the Host Groups resource. Read scope only allows querying existing groups.
Hosts: Write scope. Wrong — the Hosts scope controls host management operations, not host group management.
After enabling SSO for all users, the identity provider suffers an outage. No one can log in to the Falcon console. What should have been done?
Maintain at least one local administrator account as a break-glass account. This account bypasses SSO and allows console access during IdP outages.
Configure a backup SAML certificate. Wrong — a backup certificate does not help if the IdP infrastructure is down.
Last-Minute Facts
Platform Navigation and Core Functionality
Must-Know Facts
- Four main console sections: Activity (detections dashboard), Investigate (deep investigation and event search), Configuration (all policies, host groups, exclusions, allowlists), Support and Resources (docs, audit logs, API docs)
- Activity shows DETECTIONS and security events — it does NOT show all raw sensor telemetry; raw telemetry is in Investigate > Event Search
- Host Management shows all registered endpoints: sensor version, OS, last seen timestamp, applied policies, host group membership — use it to find stale/offline sensors
- The process tree in a detection highlights in red the specific node where malicious behavior was detected — this is the detection point, NOT necessarily the root cause or the first infected process
- Detection severity (Informational, Low, Medium, High, Critical) is set by CrowdStrike Intelligence — administrators cannot change the severity of a detection
- Searching by hash in Investigate shows ALL endpoint activity related to that file across the organization — more comprehensive than Activity > Detections which only shows detection events
Common Traps
Confusing Pairs
Scenario Tips
A CISO wants to see all High and Critical detections from the past 48 hours for a board report. Where in the console should they look?
Activity > Detections, filtered by severity (High, Critical) and time range (48 hours). This section is designed for detection triage and management with filtering capabilities.
Investigate > Event Search. Wrong — Event Search shows raw telemetry, not organized detection alerts. It is for forensic investigation, not executive reporting.
A threat analyst wants to find every endpoint that has executed a specific suspicious file (known SHA256) in the past 30 days across the entire organization.
Investigate > search by hash. Investigate shows all endpoint activity related to the hash across the org, including hosts where the file appeared, execution history, and any related detections.
Activity > Detections filtered by hash. Partial — this only shows detections, not all occurrences where the file may have run without triggering a detection.
Last-Minute Facts
Detection and Prevention
Must-Know Facts
- IOA (Indicator of Attack) = behavioral-based — detects malicious patterns and TTPs regardless of specific malware. Custom IOA rules let admins define organization-specific behavioral detections
- IOC (Indicator of Compromise) = artifact-based — matches specific known SHA256 hashes, domains, or IP addresses uploaded to Falcon
- Custom IOC action options: 'Detect' generates an alert but allows execution; 'Prevent' blocks execution. Always test with Detect before switching to Prevent
- Marking a detection as 'false positive' ONLY closes that alert — it does NOT prevent future detections of the same activity. A separate exclusion must be created
- Releasing a quarantined file returns it to its original location — add it to the allowlist BEFORE releasing to prevent immediate re-quarantine
- Three exclusion types in order of impact: IOA exclusions (suppress behavioral alerts), ML exclusions (suppress machine learning verdicts), Sensor Visibility exclusions (eliminates ALL telemetry — use as last resort)
Common Traps
Confusing Pairs
Scenario Tips
An admin marks a detection as false positive but the same application triggers the same detection the next day. What is missing?
An exclusion was not created. Marking false positive only dismisses that specific alert instance. To prevent recurring alerts, create an IOA exclusion (if behavioral) or ML exclusion (if machine learning flagged it) for the application.
The sensor needs to be updated for the false positive to take effect. Wrong — false positive status is a workflow marker, not a configuration change.
You need a rule that alerts when any process matching 'cmd.exe' spawns 'powershell.exe' with an encoded command. Which feature handles this?
Custom IOA rule. This is a behavioral pattern (parent-child process relationship with suspicious arguments). Custom IOA rules detect TTPs without requiring a specific file hash.
Custom IOC with a SHA256 hash of powershell.exe. Wrong — hashing powershell.exe would block all PowerShell usage, and IOCs match specific files, not behavioral patterns.
A legitimate IT tool is being repeatedly quarantined by sensor ML. You want the tool to stop generating ML alerts but still have the sensor monitor its file activity. Which exclusion type is correct?
ML exclusion. This suppresses the machine learning verdict for the specific file while the sensor continues to collect telemetry. Sensor visibility exclusion would eliminate all monitoring of the file — that is too aggressive for this case.
Sensor visibility exclusion for better performance. Wrong — sensor visibility exclusions eliminate all telemetry from the sensor, which eliminates investigation capability if the tool is later compromised.
Last-Minute Facts
Reporting and Administration
Must-Know Facts
- Audit logs track all administrative actions in the Falcon console: who made changes, which object was changed, and when — used for compliance accountability
- Scheduled reports can be configured with specific content, frequency, and email recipients — they continue running even if a recipient leaves the organization until manually deleted
- Dashboard data is subject to the platform's retention period — data older than the retention window is not visible; Falcon Data Replicator (FDR) is required for long-term raw event retention
- Sensor health monitoring: use Host Management to find offline sensors, RFM hosts, outdated sensors, and coverage gaps
- Notification thresholds should be tuned — alerting on every low-severity detection creates noise and alert fatigue
Common Traps
Confusing Pairs
Scenario Tips
A compliance officer asks who changed a prevention policy configuration on a specific date. Where should the Falcon administrator look?
Audit logs under Support and Resources. Audit logs record all administrative actions including policy changes, with the user, action type, and timestamp.
Activity > Detections. Wrong — this shows security events, not administrative change history.
A CISO wants automatic weekly email reports on detection trends without logging into the console. What is the correct configuration?
Configure a Scheduled Report with detection summary content, weekly frequency, and the CISO's email as the recipient. This delivers automated reports without requiring console access.
Set up FDR to stream data to the CISO's email. Wrong — FDR streams raw event data to cloud storage, not formatted email reports.