CrowdStrike IDP CrowdStrike Certified Identity Specialist(CCIS) Exam Exam Practice Test

Falcon Identity Protection is designed toextend—not replace—existing MFA solutions. According to the CCIS curriculum, Identity Protection enhances MFA by adding arisk-driven, policy-based enforcement layerthat dynamically triggers MFA challenges when risky or abnormal identity behavior is detected.

Rather than applying MFA uniformly, Falcon evaluates authentication context such as behavioral deviation, privilege usage, and anomaly detection. When risk thresholds are exceeded, Policy Rules can enforce MFA through integrated connectors, providing adaptive, Zero Trust–aligned authentication.

The incorrect options misunderstand Falcon’s role. Identity Protection does detect risky behavior, does not replace MFA providers, and fully supports both cloud and on-premises MFA connectors.

Because Falcon adds intelligence-driven enforcement on top of MFA,Option Ais the correct and verified answer.

Falcon Identity Threat Detection (ITD) providesvisibility, analytics, and detectionof identity-based threats but doesnot include enforcement capabilities. According to the CCIS curriculum, ITD customers have access to investigative and analytical features such asEvent Analysis,Privileged Identities, and relevantSettingsfor visibility and monitoring.

Policy Rules, however, are part ofIdentity Threat Protection (ITP)and reside in theEnforcesection of the Falcon console. Policy Rules enable automated responses and enforcement actions, such as blocking access or enforcing MFA, which are not available under ITD-only subscriptions.

This distinction is critical in the CCIS material:

ITD = Detect and analyze identity threats

ITP = Detect + enforce policy actions

Because ITD does not include enforcement functionality,Policy Rules are not available, makingOption Dthe correct answer.

Falcon Identity Protection integrates with third-party MFA providers throughMFA connectorsto support conditional access and identity verification. The CCIS documentation explains that these connectors allow organizations to enforce MFA challenges based on identity risk, authentication behavior, or policy conditions.

One of the supported MFA authentication methods isPush, where a notification is sent to a registered device or application for user approval. Push-based MFA is widely used due to its balance of usability and security and is fully supported by Falcon Identity Protection when integrated with compatible MFA providers.

The other options are not valid MFA authentication methods within Falcon:

Page and Pull are not recognized MFA mechanisms.

Alarm is related to alerting, not authentication.

By enabling push-based MFA through an MFA connector, organizations can dynamically enforce identity verification in alignment with Zero Trust principles. Therefore,Option Bis the correct and verified answer.

TheDomain Security Overviewpage in Falcon Identity Protection presents domain risks in aprioritized, descending order, based on a combination ofseverity, likelihood, and consequence. The CCIS curriculum emphasizes that organizations should address risksfrom top to bottom, as the list is already optimized to reflect the most impactful identity risks first.

This ordering allows security teams to focus remediation efforts where they will produce the greatest reduction in overall domain risk score. Addressing risks sequentially ensures alignment with Falcon’s risk modeling and avoids misprioritization that could occur if teams focus only on color-based severity or individual detections.

The incorrect options reflect common misconceptions:

Medium risks should not be prioritized over higher-impact risks.

Detections are different from risks and should not be addressed independently of risk context.

Low risks are intentionally deprioritized by the platform.

By following the descending order provided in the Domain Security Overview, organizations align remediation with Falcon’sZero Trust–driven identity risk scoring methodology, makingOption Athe correct answer.

TheNIST SP 800-207 Zero Trust Architectureframework fundamentally rejects the concept of implicit trust based on network location. As outlined in both NIST guidance and reinforced in the CCIS curriculum,all users must be continuously validated and authenticated regardless of whether they are inside or outside the network perimeter.

Zero Trust assumes that threats can originate from anywhere, including internal networks. Therefore, authentication and authorization decisions must be made dynamically using identity, device posture, behavior, and risk signals—not network placement.

Falcon Identity Protection aligns directly with this principle by continuously evaluating identity behavior forall users, whether they authenticate from internal corporate networks, remote locations, or cloud environments.

Because Zero Trust applies universally,Option Cis the correct and verified answer.

Falcon Identity Protection automatically differentiateshuman and programmatic accountsby analyzingauthentication traffic patterns. According to the CCIS curriculum, the platform uses behavioral analytics to observe how accounts authenticate, including frequency, protocol usage, timing, and access patterns.

Human users typically authenticate interactively and exhibit variable behavior, while programmatic or service accounts authenticate predictably and non-interactively. Falcon leverages these differences to automatically classify account types without requiring manual tagging or administrative input.

This classification is critical for accurate risk scoring, privilege analysis, and detection logic. Programmatic accounts often carry elevated privileges and long-lived credentials, making them attractive targets for attackers. Automatically identifying them allows Falcon to apply appropriate risk models and detections.

Because Falcon usesauthentication traffic analysisto classify account types,Option Cis the correct and verified answer.

Authentication Traffic Inspection (ATI) is a foundational capability of Falcon Identity Protection that enables the platform to analyze authentication traffic from domain controllers. According to the CCIS documentation, ATI is enabled throughIdentity configuration policies.

Identity configuration policies define how the Falcon sensor captures and inspects authentication-related traffic, including Kerberos, NTLM, LDAP, and other identity protocols. Enabling ATI at this level ensures that domain controllers provide the necessary telemetry for identity risk analysis, detections, and behavioral profiling.

The other options are incorrect because:

Identity management settings focus on identity governance and administration.

Identity detection configuration controls detection logic, not traffic inspection.

Identity protection settings manage high-level configuration but do not directly enable ATI.

Because ATI must be explicitly enabled viaIdentity configuration policies,Option Ais the correct and verified answer.

Falcon Identity Protection enforcesrole-based access control (RBAC)to ensure that only authorized users can create, modify, or manage policy rules. Policy rules directly impact identity enforcement actions, making proper role separation critical.

According to the CCIS documentation, the ability toenable and disable policy rulesis granted to theIdentity Protection Policy Managerand theFalcon Administratorroles. These roles are explicitly designed to manage enforcement logic, triggers, and automated identity controls.

TheIdentity Protection Domain Administratorrole, however, is limited todomain-level visibility and management, such as reviewing domain configurations, monitoring risks, and assessing posture. This role doesnothave permissions to modify or control policy enforcement behavior.

This separation prevents accidental or unauthorized changes to identity enforcement rules. Therefore,Option Ais the correct and verified answer.

In Falcon Identity Protection,identity-based incidents are dynamicand can evolve over time as additional detections are associated with them. According to the CCIS curriculum, an incident’stype is automatically recalculatedbased on thedetections related to the incident, not by manual user actions.

As new identity-based detections are generated—such as credential misuse, lateral movement attempts, or abnormal authentication behavior—the platform continuously reassesses the incident. If the newly added detections indicate a different or more severe attack pattern, Falcon may automaticallychange the incident typeto better reflect the observed threat activity.

Manual actions such as adding exclusions or linking detections do not directly change the incident type. Similarly, users cannot manually override an incident’s classification. The classification logic is driven entirely by Falcon’s analytics engine to ensure consistent, objective threat categorization.

This automated behavior is emphasized in CCIS training to highlight Falcon’s ability toadapt incident context as attacks progress, makingOption Dthe correct answer.

Falcon Identity Protection enforces deterministic policy execution using a clear and predictable precedence model. As outlined in the CCIS curriculum, Policy Groups are evaluated top to bottom, based on their order in the console. Within each Policy Group, Policy Rules are evaluated sequentially, also from top to bottom.

This ordered evaluation ensures consistent enforcement behavior and allows administrators to design layered identity controls. When a rule’s conditions are met and an action is executed, subsequent rules may or may not be evaluated depending on rule logic and configuration. This model gives administrators precise control over enforcement priority.

The incorrect options misunderstand how precedence works. Policy enforcement is not unordered, nor are Policy Groups merely visual containers. Both grouping and rule order matter.

This precedence model is critical for avoiding conflicting enforcement actions and aligns with Zero Trust principles by ensuring predictable, auditable identity enforcement. Therefore, Option A is the correct answer.

Falcon Identity Protection continuously inspects authentication traffic and network behavior to establishbehavioral baselines for users and accounts. These baselines enable the platform to detect deviations that indicate potential compromise, misuse, or insider threat activity. This behavioral intelligence directly enhances the effectiveness ofFalcon Fusion workflows.

Falcon Fusion leveragesidentity and behavioral analyticsas decision points within workflows, allowing automated actions to be triggered when abnormal behavior is detected. For example, a workflow can automatically enforce MFA, notify administrators, isolate risky sessions, or initiate remediation when a user deviates from their established baseline.

The CCIS curriculum highlights that Falcon Fusion is designed tointegrate identity risk signals with IT policy enforcement, enabling Zero Trust-aligned automation. This capability goes far beyond simple notifications and supports coordinated responses across security and IT teams.

Options A, B, and C are incorrect because Falcon Fusion is fully identity-aware, applies broadly across users and entities, and supports a wide range of actions beyond email notifications. Therefore,Option Daccurately describes how behavioral profiling strengthens Falcon Fusion workflows.

To retrieve identity-based detections and incident-related data using the CrowdStrike APIs, the API key must include the correctpermission scope. According to the CCIS curriculum, theIdentity Protection Detectionsscope is required to access identity-based detection and incident information through GraphQL.

This scope allows API queries to retrieve:

Identity-based detections

Associated incident metadata

Detection attributes such as severity, status, and related entities

Incident data in Falcon Identity Protection isderived from detections, making the Detections scope the authoritative permission set for this information. Without this scope, GraphQL queries related to identity detections and incidents will fail authorization.

The other scopes are either too narrow or unrelated to detection retrieval. Therefore,Option Ais the correct and verified answer.

Within the Domain Security Overview,Goalsare used to tailor how identity risks are grouped, evaluated, and reported. TheReduce Attack Surfacegoal is the only option thatincorporates all identity risks into a single, comprehensive security assessment.

The CCIS curriculum explains that Reduce Attack Surface provides a holistic view of identity exposure by aggregating risks related to authentication paths, account hygiene, privileges, misconfigurations, and legacy identity weaknesses. This goal is designed for organizations seeking an overall understanding of their identity security posture rather than focusing on a specific domain such as privileged users or directory hygiene.

Other goals are more specialized:

AD Hygienefocuses on directory configuration issues.

Privileged User Managementconcentrates on high-privilege identities.

Pen Testingaligns more with adversarial simulation than continuous risk assessment.

Reduce Attack Surface aligns directly withZero Trust principles, helping organizations identify and eliminate unnecessary identity access paths. Therefore,Option Cis the correct and verified answer.

Falcon Identity Protection provides flexible control over how identity-based detections are handled through theDetection Exclusionsframework. According to the CCIS curriculum, administrators can eitherdisable an entire detection typeor, where supported,exclude specific entitiessuch as users, service accounts, or endpoints from triggering that detection.

Not all detections support entity-level exclusions. For detections that do, exclusions allow organizations to suppress known benign behavior without disabling the detection globally. This is particularly useful for service accounts or legacy systems that generate expected but non-malicious activity. When entity-level exclusion is not supported, administrators may choose todisable the detection entirely, which stops it from generating alerts across the environment.

The CCIS documentation clearly explains this dual model:

All detections can be disabled, regardless of type

Only some detections support entity-based exclusions

This approach balances operational flexibility with security integrity and avoids the misconception that exclusions automatically create security gaps. Therefore,Option Cis the correct and verified answer.

The Domain Security Overview in Falcon Identity Protection usesGoalsto frame identity risks into focused security assessment perspectives. These goals allow organizations to evaluate identity posture based on specific security priorities such as directory hygiene, privilege exposure, or overall attack surface reduction.

According to the CCIS curriculum, theavailable GoalsincludePrivileged Users Management,AD Hygiene,Pen Testing, andReduce Attack Surface. These goals are predefined by CrowdStrike and determine how risks are grouped, weighted, and presented in reports.

Business Privileged Users Managementisnot an available Goalwithin the Domain Security Overview. While Falcon Identity Protection does support the concept ofbusiness privilegesand evaluates their impact on users and entities, this concept is handled through risk analysis and configuration—not as a selectable Domain Security Goal.

The CCIS documentation clearly distinguishes betweenGoals(which control reporting and assessment views) andbusiness privilege modeling(which influences risk scoring). Therefore,Option Bis the correct and verified answer.

Falcon Fusion workflows integrate directly with Falcon Identity Protection throughidentity-based triggers, allowing automated responses to identity threats. The correct trigger that activates a Falcon Fusion workflow from Identity Protection isAlert > Identity detection.

Identity detections are generated when Falcon observes suspicious or malicious identity behavior, such as credential abuse, abnormal authentication patterns, lateral movement attempts, or policy violations related to identity risk. These detections are distinct from endpoint-only detections or incidents and are specifically designed to representidentity-based attack activity.

WhileNew incidentandNew endpoint detectionare valid Falcon Fusion triggers in other Falcon modules, they are not the primary triggers for identity-focused automation. Similarly,Spotlight user action > Hostrelates to vulnerability management workflows rather than identity analytics.

The CCIS curriculum emphasizes that Falcon Fusion enablesautomated identity response, such as notifying security teams, disabling accounts, enforcing MFA, or triggering SOAR actions, based onidentity detections. Therefore, workflows tied toAlert > Identity detectionallow organizations to respond quickly and consistently to identity threats, makingOption Cthe correct answer.

Falcon Identity Protection evaluatesdomain riskby analyzing identity-related weaknesses such as insecure authentication protocols, legacy directory configurations, and exposure to credential-based attacks. Actions that harden Active Directory and authentication mechanisms will directly reduce domain risk scores.

Measures such asenabling SMB signing,enforcing NTLMv2, andupgrading unsupported operating systemsremove common identity attack paths and are explicitly recommended in the CCIS curriculum as effective domain risk remediation steps.

In contrast,upgrading end-of-life Acrobat Readeraddresses anendpoint application vulnerability, not an identity or directory-related risk. While important for endpoint hygiene, it does not influence identity telemetry, authentication behavior, or domain controller security assessed by Falcon Identity Protection.

Because domain risk scoring is strictly tied to identity infrastructure and authentication posture,Option Bdoes not contribute to lowering the domain risk score and is therefore the correct answer.