Free CCFA practice test: 30 questions with answers

Role-based access should follow least privilege, so a role limited to investigation permissions meets the need without policy or API rights. Shared logins and full administrator access break accountability or least privilege, and asking a user to avoid pages is not an access control.

An API client should be scoped to only the APIs the integration needs, and its secret must be stored safely because it is shown only once at creation. Personal administrator credentials and all-scope clients violate least privilege, and reusing an old secret keeps unnecessary access alive.

The secret is shown only once at creation, so it must be recorded securely, and scopes can be restricted per integration. Password changes do not rotate API client secrets, and API clients are not tied to the creator's console session.

Console menus and pages are controlled by role permissions, so a role missing prevention policy rights hides that page. Sensor versions on the analyst's workstation and host group membership do not control console navigation, and API clients have no bearing on page visibility.

Sensor installation depends on a supported operating system and kernel, and the sensor needs outbound connectivity to Falcon cloud to register. A desktop environment and identical hostnames are not requirements, and blocking outbound traffic prevents the sensor from communicating at all.

A custom policy assigned to a pilot host group lets the admin test changes while default policies stay untouched for the rest of the estate. Editing or deleting defaults affects hosts outside the test, and turning off the sensor removes protection from the pilot machines.

A sensor that never checks in usually points to connectivity problems or an install with the wrong Customer ID, so these are verified first. Reformatting the machine and upgrading the sensor skip diagnosis, and deleting a console record does not fix a sensor that cannot reach the cloud.

Uninstall protection requires a maintenance token, and removing the sensor leaves the endpoint unprotected, so the change must be planned. Deleting a console record does not touch the endpoint, and a password reset does not disable uninstall protection.

Host Management filters let admins narrow the inventory by attributes such as hostname and platform. Detection exports return alert data rather than the host inventory, restarting sensors does not create a filtered inventory, and a prevention policy does not organize host lists.

RFM means the sensor is operating with reduced capability, so administrators should find out why and restore full functionality. The other options describe full prevention with no telemetry, a removed sensor, or a bandwidth-saving setting, none of which match RFM.

Stale records for retired devices should be verified and then cleaned up so the inventory stays accurate. Moving the record to a dynamic group or lowering its prevention settings does not address the stale record, and disabling detections for a whole group would weaken coverage for active hosts.

Host management reports summarize hosts and their sensor status, which suits a periodic review. A prevention policy does not send summaries, RTR audit logs cover session commands rather than inventory, and an IOA rule detects behavior instead of labeling hosts.

Prevention policies group protection settings by category, and admins choose whether each one detects only or actively prevents. Prevention policies are assigned to host groups, a single setting never replaces other controls, and policy changes do not wait for a sensor upgrade.

Sensor update policies are assigned to host groups, so each group can run a different build. A single global policy removes the staged approach, while reinstalling or disabling prevention are disruptive and do not control versions.

Containment policies can include IP or subnet exclusions for trusted addresses that must stay reachable. An IOC would block the address, a group rule would not end containment, and a quarantine release applies to files rather than network traffic.

Verifying the file with its owner and then releasing it with a documented justification resolves the false positive in a controlled way. Turning off prevention everywhere weakens protection for all hosts, and deleting the quarantine record destroys evidence of the event.

A narrowly scoped exclusion suppresses the known-good activity on one group while keeping the rule active elsewhere. Deleting the rule removes coverage everywhere, uninstalling the sensor removes protection, and permanent detect-only mode weakens prevention across the estate.

Custom IOCs let admins define indicators and choose an action such as detect, prevent or allow. The other options misdescribe IOCs, which are not compiled, not limited to one viewed host, and not a replacement for prevention or sensor update policies.

A scoped allow indicator for a verified hash stops the repeat alerts on that one file while keeping detection active everywhere else. Lowering the default policy weakens every host, adding names to every rule is broad and unreliable, and disabling detections for the whole group hides activity from analysts.

Detect mode shows what a rule would match without blocking anything, so false positives can be tuned before prevention is turned on. The other options misstate how custom IOA rule actions and loading work.

Falcon Fusion workflows automate tasks: a defined trigger starts a sequence of actions. The other options describe data archiving, sensor installation, and role approval, none of which is the main purpose of workflows.

A Falcon Fusion workflow can start from a detection trigger and run notification and ticket actions automatically. Blocking a hash does not notify anyone, sensor update policies control builds rather than alerting, and audit logs record console activity rather than detections.

Workflows are event-driven: a trigger starts them and actions carry out the work. The option claiming workflows run without triggers and the option claiming they delete audit entries are both incorrect.

The trigger defines the event that starts a workflow, such as a new detection. The other options describe sensor updates, audit retention, and comments, none of which the trigger controls.

Sensor reports summarize which sensor versions are deployed across hosts, which answers the question directly. RTR history, policy assignments, and workflow runs show different activity and do not report version distribution.

Audit logs record configuration changes made by console users, including who changed what and when. Endpoint logs, detection summaries and saved view filters do not capture the administrative change history of a console policy.

Dashboards and reports present summarized console data, which helps teams spot trends without querying each host. Dashboards do not distribute installers, reports do not change settings, and dashboards do not replace audit logs for administrator actions.

Dynamic host groups add hosts automatically when they match assignment rules, so the right policies apply without manual work. Static groups need manual membership, per-server assignments are hard to maintain, and one catch-all group cannot apply targeted policies.

Grouping by function, platform or location makes each group's policy intent clear and reduces overlap. One group for everything cannot differentiate needs, per-employee groups are hard to maintain, and renaming groups does not remove policy assignments.

Limiting each policy type to one assigning group per host removes ambiguity about which setting applies. Overlap is not harmless when policies conflict, removing the sensor stops protection, and renaming a host does not change group assignment rules.