forescout fscp practice test
Forescout Certified Professional
Question 1
Which CLI command gathers historical statistics from the appliance and outputs the information to a
single *.csv file for processing and analysis?
- A. fstool tech-support
- B. fstool appstats
- C. fstool va stats
- D. fstool stats
- E. fstool sysinfo stats
Answer:
E
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
The fstool sysinfo stats command is the correct CLI command used in Forescout platforms to gather
and export historical statistics from the appliance to a single CSV file for processing and analysis.
According to the Forescout CLI Commands Reference Guide (versions 8.1.x through 8.5.3), the fstool
sysinfo command is listed under the Machine Administration category of fstool commands. The
command's primary purpose is to "View Extensive System Information about the Appliance".
When used with the stats parameter, the command fstool sysinfo stats specifically:
Gathers historical statistics - The command collects comprehensive time-series data and historical
statistics from the Forescout appliance
Outputs to a CSV file - The information is exported to a *single .csv file format, making it suitable for
import into spreadsheet applications and data analysis tools
Enables processing and analysis - The CSV format allows administrators and engineers to perform
offline analysis, trend analysis, and detailed troubleshooting
Why Other Options Are Incorrect:
fstool tech-support - This command is used to send logs and diagnostic information to Forescout
Customer Support, not to output appliance statistics
fstool appstats - This command is not documented in any official Forescout CLI reference guides
fstool va stats - This command variant is not a recognized fstool command in Forescout
documentation
fstool stats - This standalone command variant is not a recognized fstool command in Forescout
documentation
Referenced Documentation:
Forescout CLI Commands Reference Guide v8.1.x, 8.2.x, 8.4.x, 8.5.2, and 8.5.3
Forescout Administration Guide v8.3 and v8.4
Machine Administration fstool Commands section - Forescout Official Documentation Portal
Question 2
When using Remote Inspection for Windows, which of the following properties require fsprocsvc.exe
interactive scripting?
- A. User Directory Common Name
- B. Update Microsoft Vulnerabilities
- C. Windows Expected Script Result
- D. Antivirus Running
- E. Windows Service Running
Answer:
C
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
The Windows Expected Script Result property is the correct answer. According to the
official Forescout CounterACT Endpoint Module: HPS Inspection Engine Configuration Guide Version
10.8, the fsprocsvc.exe service is required to run interactive scripts for several CounterACT tasks
during Remote Inspection operations on Windows endpoints.
The documentation explicitly lists the following Properties requiring the fsprocsvc service (with
Remote Inspection, i.e., not via SecureConnector):
Windows Expected Script Result
✓
Device Interfaces
Number of IP Addresses
External Devices
Windows File MD5 Signature
Windows Is Behind NAT
Microsoft Vulnerabilities
About fsprocsvc.exe Service:
The fsprocsvc.exe service is a proprietary ForeScout service utility that is downloaded by the HPS
Inspection Engine to endpoints. It is used to run interactive scripts for several CounterACT tasks. Key
characteristics include:
Size on disk: Approximately 250KB
Memory acquired during runtime: 2 MB
Runs under: System context
Start type: Automatic
Inactivity timeout: After 2 hours of inactivity, the service stops automatically
Communication: Does not open any new network connection. Communication is carried out over
Microsoft's SMB/RPC (445/TCP and 139/TCP) with domain credentials authentication
Why Other Options Are Incorrect:
A . User Directory Common Name - This property is derived from User Directory plugin queries and
does not require fsprocsvc interactive scripting
B . Update Microsoft Vulnerabilities - This is an action, not a property. While Microsoft
Vulnerabilities property does require fsprocsvc, "Update" is not the property name listed
D . Antivirus Running - This is a basic WMI-based property that does not require interactive scripting
via fsprocsvc
E . Windows Service Running - This is a basic property that can be determined through WMI queries
without requiring fsprocsvc interactive scripting
Interactive Scripts Requirement:
According to the HPS Inspection Engine Configuration Guide, WMI does not support interactive
scripts on all Windows endpoints. When WMI is used for Remote Inspection, CounterACT uses the
fsprocsvc service to run interactive scripts on endpoints that require them. The Windows Expected
Script Result property specifically requires running a custom script on the endpoint, which
necessitates the fsprocsvc service for proper execution.
Referenced Documentation:
Forescout CounterACT Endpoint Module: HPS Inspection Engine Configuration Guide Version 10.8
Section: "About fsprocsvc.exe" and "Properties requiring the service (With remote inspection, i.e. not
via SecureConnector)"
Question 3
Which of the following is true regarding the Windows Installed Programs property which employs
the "for any/for all" logic mechanism?
- A. Although the condition has multiple sub-properties, when "ANY" is selected it evaluates the programs for any of the configured sub-properties.
- B. The condition does not have any sub-properties. The "any/all" refers to the multiple programs.
- C. Although the condition has sub-properties which could refer to a single program on multiple endpoints, the "any/all" refers to the program's properties.
- D. Although the condition has multiple sub-properties, the "any/all" refers to the sub-properties and not the programs.
- E. Although the condition has multiple sub-properties, the "any/all" refers to the programs and not the sub-properties.
Answer:
E
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
The Windows Installed Programs property condition utilizes multiple sub-
properties including Program Name, Program Version, Program Vendor, and Program Path. However,
when using the "for ANY/for ALL" logic mechanism, the "any/all" refers to the PROGRAMS and not to
the sub-properties.
How the "Any/All" Logic Works with Windows Installed Programs:
When configuring a policy condition with the Windows Installed Programs property, the "any/all"
logic determines whether an endpoint should match the condition based on:
"For ANY" - The endpoint matches the policy condition if ANY of the configured programs are
installed on the endpoint
"For ALL" - The endpoint matches the policy condition if ALL of the configured programs are installed
on the endpoint
Example: If an administrator creates a condition like:
Windows Installed Programs contains "Microsoft Office" OR "Adobe Reader"
Using "For ANY": The endpoint matches if it has EITHER Microsoft Office OR Adobe Reader installed
Using "For ALL": The endpoint matches only if it has BOTH Microsoft Office AND Adobe Reader
installed
The sub-properties (Program Name, Version, Vendor, Path) are used to define and identify which
specific programs to match against, but the "any/all" logic applies to the PROGRAMS themselves, not
to the sub-properties.
Why Other Options Are Incorrect:
A - Incorrectly states the "any/all" evaluates the programs for the sub-properties
B - Factually incorrect; the condition definitely has multiple sub-properties (Name, Version, Vendor,
Path)
C - Confuses the scope; the "any/all" does not refer to "program's properties" but to multiple
programs
D - Inverted logic; the "any/all" refers to the programs, not the sub-properties
Referenced Documentation:
Forescout Administration Guide v8.3, v8.4
Working with Policy Conditions - List of Properties by Category
Windows Applications Content Module Configuration Guide
Question 4
What is the best practice to pass an endpoint from one policy to another?
- A. Use operating system property
- B. Use sub rules
- C. Use function property
- D. Use groups
- E. Use policy condition
Answer:
B
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
According to the Forescout Platform Administration and Deployment Documentation, the best
practice to pass an endpoint from one policy to another is to use SUB-RULES.
Sub-Rules and Policy Routing:
Sub-rules are conditional branches within a Forescout policy that allow for sophisticated endpoint
routing and handling. When an endpoint matches a sub-rule condition, it can be directed to perform
specific actions or be passed to another policy group for further evaluation.
Key Advantages of Using Sub-Rules:
Granular Control - Sub-rules enable precise segmentation of endpoints based on multiple properties
and conditions
Hierarchical Processing - Once an endpoint matches a sub-rule, it proceeds down the sub-rule
branch; later sub-rules of the policy are not evaluated for that endpoint
Efficient Endpoint Routing - Sub-rules allow endpoints to be efficiently routed to appropriate policy
handlers without evaluating unnecessary conditions
Policy Chaining - Sub-rules facilitate the logical flow and routing of endpoints through multiple policy
layers
Best Practice Implementation:
The documentation emphasizes that when designing policies for endpoint management,
administrators should:
Use sub-rules to create conditional branches that evaluate endpoints against multiple criteria
Route endpoints to appropriate policy handlers based on their properties and compliance status
Avoid using simple property-based routing when complex multi-step evaluation is needed
Why Other Options Are Incorrect:
A . Use operating system property - While OS properties can be used in conditions, they are not the
mechanism for passing endpoints between policies
C . Use function property - Function properties are not used for inter-policy endpoint routing
D . Use groups - While groups are useful for organizing endpoints, they are not the primary best
practice for passing endpoints between policies
E . Use policy condition - Policy conditions define what endpoints should be evaluated, but sub-rules
provide the actual routing mechanism
Referenced Documentation:
Forescout Platform Administration Guide - Defining Policy Sub-Rules
"Defining Forescout Platform Policy Sub-Rules" - Best Practice section
Sub-Rule Advanced Options documentation
Question 5
Which of the following User Directory server settings is necessary to enable guest approval by
sponsors?
- A. Policy to control
- B. Guest Tags
- C. Sponsor Group
- D. Guest password policy
- E. Authentication Server
Answer:
C
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
The Sponsor Group is the necessary User Directory server setting required to enable guest approval
by sponsors. According to the Forescout User Directory Plugin Configuration Guide and Guest
Management Portal documentation, Sponsor Groups must be created and configured to define the
corporate employees (sponsors) who are authorized to approve or decline guest network access
requests.
Sponsor Group Configuration:
In the Guest Management pane, the Sponsors tab is used to define the corporate employees who are
authorized to log into the Guest Management Portal to approve network access requests from
guests. These employees are assigned to specific Sponsor Groups, which control which sponsors can
approve guest access requests.
How Sponsor Groups Enable Guest Approval:
Sponsor Definition - Corporate employees must be designated as sponsors and assigned to a Sponsor
Group
Approval Authority - Sponsors in assigned groups can approve or decline guest network access
requests
Authentication - When "Enable sponsor approval without authentication via emailed link" is
selected, sponsors in the designated group can approve guests based on email link authorization
Guest Registration - Guest registration options connect Sponsor Groups to the guest approval
workflow
Why Other Options Are Incorrect:
A . Policy to control - While policies are used for guest control, they do not define which sponsors can
approve guests
B . Guest Tags - Guest Tags are used to classify and organize guest accounts, not to enable sponsor
approval
D . Guest password policy - This setting controls password requirements for guests, not sponsor
approval authority
E . Authentication Server - Authentication servers verify credentials but do not establish sponsor
approval groups
Referenced Documentation:
Forescout User Directory Plugin Configuration Guide - Create Sponsors section
Guest Management Portal - Sponsor Configuration documentation
"Create sponsors" - Forescout Administration Guide section
Question 6
Which of the following is an advantage of FLEXX licensing?
- A. License is centralized by an appliance by combining hardware and software
- B. Licensing is centralized and managed by an Enterprise Manager
- C. With FLEXX license, you can add See + Control + Resiliency as a base License
- D. FLEXX licensing is offered with V7 and V8 Resiliency and Advanced Compliance licenses
- E. FLEXX licensing works in V7 or on CTxx appliances
Answer:
B
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
According to the Forescout Licensing and Sizing Guide and official licensing documentation, the key
advantage of FLEXX licensing is that licensing is centralized and managed by an Enterprise Manager,
providing centralized license administration across the entire Forescout platform deployment.
FLEXX Licensing Key Advantages:
FLEXX licensing represents a significant departure from the legacy per-appliance licensing model. The
primary advantages of FLEXX licensing include:
Centralized License Pool - Licenses are independent of hardware appliances and form a centralized,
shared pool that can be deployed across multiple appliances and network segments
Enterprise Manager Management - License entitlements and allocations are centrally administered
and managed by the Enterprise Manager
Portable Licenses - Licenses can be ubiquitously deployed and shared across different device types,
appliance locations, and deployment scenarios (campus, data center, cloud, OT)
Flexible Capacity Sharing - Licensed capacity can be shared across campus, data center, cloud, and OT
environments without appliance-specific restrictions
Scalability - Unlimited virtual appliance instances can be spun up as needed without purchasing
additional appliance hardware licenses
Unified Customer Portal - Centralized access to license management, software downloads,
documentation, and support
FLEXX Licensing Deployment Model:
With FLEXX licensing, organizations can:
Order software licenses separately and independent from appliances
Centrally manage and allocate licenses from a unified portal
Redistribute license capacity across appliances without manual reallocation
Support virtual and physical appliances equally
Why Other Options Are Incorrect:
A - Incorrect; FLEXX licenses are NOT controlled by individual appliances but are managed centrally at
the Enterprise Manager level
C - Base licenses cannot simply be added together; FLEXX licensing is purchased as a unified license
pool
D - FLEXX is offered with V8 appliances (5100 and 4100 series), not V7; CT series appliances support
per-appliance licensing
E - FLEXX is available for 5100/4100 series and CT series (with Flexx upgrade option) in V8.0 or higher,
not in V7
Referenced Documentation:
Forescout Licensing and Sizing Guide
Forescout Flexx Licensing - What it Offers
Forescout Platform License Management documentation
Question 7
Where are the plugin logs located in the CounterACT CLI?
- A. /usr/local/forescout/plugin/<plugin ID>/log
- B. /usr/local/forescout/plugin/log/<plugin ID>
- C. /usr/local/forescout/log
- D. /usr/local/log/plugin/<plugin ID>
- E. /usr/local/forescout/log/plugin/<plugin ID>
Answer:
E
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
According to the Forescout CLI Commands Reference Guide and official documentation, the plugin
logs in the CounterACT CLI are located at the path /usr/local/forescout/log/plugin/<plugin ID>.
CLI Log File Structure:
The Forescout CLI organizes log files in a hierarchical directory structure. When using the CLI to
access logs, administrators can navigate through the following directory structure:
log - View appliance log files
log:plugin - Access plugin-specific log directories
log:plugin/<plugin ID> - Access logs for a specific plugin
Example Plugin Log Locations:
According to the documentation, specific plugin logs can be accessed using the following CLI
commands:
text
list log:plugin/<plugin ID>
monitor log:plugin/<plugin ID>/<plugin_name>.log
For example, the Python server logs for the Connect Module are located
at: /usr/local/forescout/plugin/connect_module/python_logs
CLI Commands for Accessing Plugin Logs:
The correct CLI syntax for accessing plugin logs includes:
text
list log:plugin/<plugin ID> – Lists plugin log directory contents
monitor log:plugin/<plugin ID>/<plugin_name>.log – Monitors plugin log in real-time
view log:plugin/<plugin ID>/<plugin_name>.log – Views plugin log file contents
search <pattern> log:plugin/<plugin ID>/<plugin_name>.log – Searches within plugin logs
Why Other Options Are Incorrect:
A . /usr/local/forescout/plugin/<plugin ID>/log - Inverted directory structure; log is a parent
directory, not a subdirectory of the plugin ID
B . /usr/local/forescout/plugin/log/<plugin ID> - Incorrect path structure; "log" is not a subdirectory
under "plugin"
C . /usr/local/forescout/log - Too generic; this path refers to appliance-wide logs, not plugin-specific
logs
D . /usr/local/log/plugin/<plugin ID> - Incorrect root path; Forescout logs are stored under
/usr/local/forescout, not /usr/local
Referenced Documentation:
Forescout CLI Commands Reference Guide - List Directories and Log Files section
Python Log Location documentation
FS-CLI Commands - File and Log Management section
Examples showing log:plugin path structure in CLI reference guides
Question 8
What is the automated safety feature to prevent network wide outages/blocks?
- A. Stop all policies
- B. Disable policy
- C. Disable Policy Action
- D. Action Thresholds
- E. Send an Email Alert
Answer:
D
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
Action Thresholds is the automated safety feature designed to prevent network-wide outages and
blocks. According to the Forescout Platform Administration Guide, Action Thresholds are specifically
designed to automatically implement safeguards when rolling out sanctions (blocking actions) across
your network.
Purpose of Action Thresholds:
Action thresholds work as an automated circuit breaker mechanism that prevents catastrophic
network-wide outages. The feature establishes maximum percentage limits for specific action types
on a single appliance. When these limits are reached, the policy automatically stops executing
further blocking actions to prevent mass network disruption.
How Action Thresholds Prevent Outages:
Consider a scenario where a policy is misconfigured and would block 90% of all endpoints on the
network due to a false condition match. Without Action Thresholds, this could cause a network-wide
outage. With Action Thresholds configured:
Limit Definition - An administrator sets an action threshold (e.g., 20% of endpoints can be blocked by
Switch action type)
Automatic Enforcement - When this percentage threshold is reached, the policy automatically stops
executing the blocking action for any additional endpoints
Alert Generation - The system generates alerts to notify administrators when a threshold has been
reached
Protection - This prevents the policy from cascading failures that could affect the entire network
Action Threshold Configuration:
Each action type (e.g., Switch blocking, Port blocking, External port blocking) can be configured with
its own threshold percentage. This allows granular control over the maximum impact any single
policy can have on the network.
Why Other Options Are Incorrect:
A . Stop all policies - This is a manual intervention, not an automated safety feature; also, it's too
drastic and would disable legitimate policies
B . Disable policy - This is a manual action, not an automated safety mechanism
C . Disable Policy Action - While you can disable individual actions, this is not an automated
threshold-based safeguard
E . Send an Email Alert - Alerts notify administrators but do not automatically prevent outages; they
require manual intervention
Referenced Documentation:
Forescout Platform Administration Guide - Working with Action Thresholds
Forescout Platform Administration Guide - Policy Safety Features
Section: "Action Thresholds are designed to automatically implement safeguards when rolling out
such sanctions across your network"
Question 9
Which of the following logs are available from the GUI?
- A. Host Details, Policy, Blocking, Event Viewer, Audit Trail
- B. Switch, Policy, Blocking, Event Viewer, Audit Trail
- C. Switch, Discovery, Threat Protection, Event Viewer, Audit Trail
- D. HPS, Policy, Threat Protection, Event Viewer, Audit Trail
- E. Host Details, Policy, Today Log, Threat Event Viewer, Audit Trail
Answer:
A
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
According to the Forescout Platform Administration Guide, the logs available from the GUI Console
include: Host Details, Policy, Blocking, Event Viewer, and Audit Trail.
Available Logs from the Forescout Console GUI:
Host Details Log - Provides detailed information about individual endpoints discovered on the
network. This log displays comprehensive host properties and status information directly accessible
from the console.
Policy Log - Shows policy activity and records how specific endpoints are handled by policies. The
Policy Log investigates endpoint activity, displaying information about policy matches, actions
executed, and policy evaluation results.
Blocking Log - Displays all blocking events that occur on the network, including port blocks, host
blocks, and external port blocks. This log provides an at-a-glance display of blocked endpoints with
timestamps and reasons.
Event Viewer - A system log that displays severity, date, status, element, and event information.
Administrators can search, export, and filter events using the Event Viewer.
Audit Trail - Records administrative actions and changes made to the Forescout platform
configuration and policies.
How to Access Logs from the GUI:
From the Forescout Console GUI, administrators access logs through the Log menu by selecting:
Blocking Logs to view block events
Event Viewer to display system events
Policy Reports to investigate policy activity
Why Other Options Are Incorrect:
B . Switch, Policy, Blocking, Event Viewer, Audit Trail - "Switch" is not a standalone log type available
from the GUI; switch data is captured through plugin logs and reports
C . Switch, Discovery, Threat Protection, Event Viewer, Audit Trail - "Discovery" and "Threat
Protection" are report categories, not GUI logs in the standard log menu
D . HPS, Policy, Threat Protection, Event Viewer, Audit Trail - HPS logs are accessed through CLI, not
the GUI; "Threat Protection" is a report, not a GUI log
E . Host Details, Policy, Today Log, Threat Event Viewer, Audit Trail - "Today Log" and "Threat Event
Viewer" are not standard log names in the Forescout GUI
Referenced Documentation:
Forescout Platform Administration Guide - Generating Reports and Logs
Policy Reports and Logs section
Work with System Event Logs documentation
View Block Events documentation
Question 10
What should be done after the Managed Windows devices are sent to a policy to determine the
Windows 10 patch delivery optimization setting?
- A. Push out the proper DWORD setting via GPO
- B. Non Windows 10 devices must be called out in sub-rules since they will not have the relevant DWORD
- C. Manageable Windows devices are not required by this policy
- D. Non Windows 10 devices must be called out in sub-rules so that the relevant DWORD value may be changed
- E. Write sub-rules to check for each of the DWORD values used in patch delivery optimization
Answer:
E
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
After managed Windows devices are sent to a policy to determine the Windows 10 patch delivery
optimization setting, the best practice is to write sub-rules to check for each of the DWORD values
used in patch delivery optimization.
Windows 10 Patch Delivery Optimization DWORD Values:
Windows 10 patch delivery optimization is configured through DWORD registry settings in the
following registry path:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization
The primary DWORD value is DODownloadMode, which supports the following values:
0 = HTTP only, no peering
1 = HTTP blended with peering behind the same NAT (default)
2 = HTTP blended with peering across a private group
3 = HTTP blended with Internet peering
63 = HTTP only, no peering, no use of DO cloud service
64 = Bypass mode (deprecated in Windows 11)
Why Sub-Rules Are Required:
When implementing a policy to manage Windows 10 patch delivery optimization settings,
administrators must create sub-rules for each possible DWORD configuration value because:
Different Organizational Requirements - Different departments or network segments may require
different delivery optimization modes (e.g., value 1 for some devices, value 0 for others)
Compliance Checking - Each sub-rule verifies whether a device has the correct DWORD value
configured according to organizational policy
Enforcement Actions - Once each sub-rule identifies a specific DWORD value, appropriate
remediation actions can be applied (e.g., GPO deployment, messaging, notifications)
Granular Control - Sub-rules allow for precise identification of devices with non-compliant delivery
optimization settings
Implementation Workflow:
Device is scanned and identified as Windows 10 managed device
Policy queries the DODownloadMode DWORD registry value
Multiple sub-rules evaluate the current DWORD value:
Sub-rule for value "0" (HTTP only)
Sub-rule for value "1" (Peering behind NAT)
Sub-rule for value "2" (Peering across private group)
Sub-rule for value "3" (Internet peering)
Sub-rule for value "63" (No peering, no cloud)
Matching sub-rule triggers appropriate policy actions
Why Other Options Are Incorrect:
A . Push out the proper DWORD setting via GPO - This is what you do AFTER checking via sub-rules,
not what you do after sending devices to the policy
B . Non Windows 10 devices must be called out in sub-rules since they will not have the relevant
DWORD - While non-Windows 10 devices should be excluded, the answer doesn't address the core
requirement of checking each DWORD value
C . Manageable Windows devices are not required by this policy - This is incorrect; managed
Windows devices are the focus of this policy
D . Non Windows 10 devices must be called out in sub-rules so that the relevant DWORD value may
be changed - This misses the point; you check the DWORD values first, not change them in sub-rules
Referenced Documentation:
Microsoft Delivery Optimization Reference - Windows 10 Deployment
Forescout Administration Guide - Defining Policy Sub-Rules
How to use Group Policy to configure Windows Update Delivery Optimization
Question 11
Which of the following switch actions cannot both be used concurrently on the same switch?
- A. Access Port ACL & Switch Block
- B. Switch Block & Assign to VLAN
- C. Endpoint Address ACL & Assign to VLAN
- D. Access Port ACL & Endpoint Address ACL
- E. Access Port ACL & Assign to VLAN
Answer:
D
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
According to the Forescout Switch Plugin Configuration Guide, Access Port ACL and Endpoint Address
ACL cannot both be used concurrently on the same endpoint. These two actions are mutually
exclusive because they both apply ACL rules to control traffic, but through different mechanisms, and
attempting to apply both simultaneously creates a conflict.
Switch Restrict Actions Overview:
The Forescout Switch Plugin provides several restrict actions that can be applied to endpoints:
Access Port ACL - Applies an operator-defined ACL to the access port of an endpoint
Endpoint Address ACL - Applies an operator-defined ACL based on the endpoint's address (MAC or
IP)
Assign to VLAN - Assigns the endpoint to a specific VLAN
Switch Block - Completely isolates endpoints by turning off their switch port
Action Compatibility Rules:
According to the Switch Plugin Configuration Guide:
Endpoint Address ACL vs Access Port ACL - These CANNOT be used together on the same endpoint
because:
Both actions modify switch filtering rules
Both actions can conflict when applied simultaneously
The Switch Plugin cannot determine priority between conflicting ACL configurations
Applying both would create ambiguous filtering logic on the switch
Actions That CAN Be Used Together:
Access Port ACL + Assign to VLAN -
Can be used concurrently
✓
Endpoint Address ACL + Assign to VLAN -
Can be used concurrently
✓
Switch Block + Assign to VLAN - This is semantically redundant (blocking takes precedence) but is
allowed
Access Port ACL + Switch Block -
Can be used concurrently (though Block takes precedence)
✓
Why Other Options Are Incorrect:
A . Access Port ACL & Switch Block - These CAN be used concurrently; Switch Block would take
precedence
B . Switch Block & Assign to VLAN - These CAN be used concurrently (though redundant)
C . Endpoint Address ACL & Assign to VLAN - These CAN be used concurrently
E . Access Port ACL & Assign to VLAN - These CAN be used concurrently; they work on different
aspects of port management
ACL Action Definition:
According to the documentation:
Access Port ACL - "Use the Access Port ACL action to define an ACL that addresses one or more than
one access control scenario, which is then applied to an endpoint's switch port"
Endpoint Address ACL - "Use the Endpoint Address ACL action to apply an operator-defined ACL,
addressing one or more than one access control scenario, which is applied to an endpoint's address"
Referenced Documentation:
Forescout CounterACT Switch Plugin Configuration Guide Version 8.12
Switch Plugin Configuration Guide v8.14.2
Switch Restrict Actions documentation
Question 12
When configuring policies, which of the following statements is true regarding this image?
- A. The NOT checkbox means the "Evaluate Irresolvable as" should be set to True
- B. The external NOT does not change the meaning of "evaluate irresolvable as"
- C. Has no effect on irresolvable hosts
- D. Negates the criteria inside the property
- E. The NOT checkbox means the "Evaluate Irresolvable as" should be set to False
Answer:
D
Explanation:
The NOT checkbox negates the criteria inside the property. According to the Forescout
Administration Guide, when the NOT checkbox is selected on a policy condition criteria, it reverses
the logic of that specific criterion evaluation.
Understanding the NOT Operator in Policy Conditions:
In Forescout policy configuration, the NOT operator is a Boolean logic operator that inverts the result
of the property evaluation. When you select the NOT checkbox:
Logical Inversion - The condition is evaluated normally, and then the result is inverted
Criteria Negation - If a criteria would normally match an endpoint, selecting NOT causes it NOT to
match
Property-Level Operation - The NOT operator applies specifically to that individual
property/criterion, not to the entire rule
Example of NOT Logic:
Without NOT:
Condition: "Windows Antivirus Running = True"
Result: Matches endpoints that HAVE antivirus running
With NOT:
Condition: "NOT (Windows Antivirus Running = True)"
Result: Matches endpoints that DO NOT have antivirus running
NOT vs. "Evaluate Irresolvable As":
According to the documentation, the NOT operator and "Evaluate Irresolvable As" are independent
settings:
NOT operator - Negates/inverts the criteria evaluation itself
"Evaluate Irresolvable As" - Defines what happens when a property CANNOT be resolved (is
irresolvable)
These serve different purposes:
NOT determines what value to match
Evaluate Irresolvable As determines how to handle unresolvable properties
Handling Irresolvable Criteria:
According to the administration guide documentation:
"If you do not select the Evaluate irresolvable criteria as option, the criteria is handled as irresolvable
and the endpoint does not undergo further analysis."
The "Evaluate Irresolvable As" checkbox allows you to define whether an irresolvable property
should be treated as True or False when the property value cannot be determined. This
is independent of the NOT checkbox.
Why Other Options Are Incorrect:
A . The NOT checkbox means the "Evaluate Irresolvable as" should be set to True - Incorrect; NOT and
Evaluate Irresolvable As are independent settings
B . The external NOT does not change the meaning of "evaluate irresolvable as" - While technically
true that NOT doesn't change the Evaluate Irresolvable setting, the answer doesn't explain what NOT
actually does
C . Has no effect on irresolvable hosts - Incorrect; NOT negates the criterion logic regardless of
whether it's resolvable
E . The NOT checkbox means the "Evaluate Irresolvable as" should be set to False - Incorrect; NOT
and Evaluate Irresolvable As are independent
Policy Condition Structure:
According to the documentation, a policy condition consists of:
Property criteria combined with Boolean logic operators
Individual criterion settings including NOT operator
Irresolvable handling options that are separate from the NOT operator
Referenced Documentation:
Forescout Administration Guide - Define policy scope
Forescout eyeSight policy sub-rule advanced options
Handling Irresolvable Criteria section
Working with Policy Conditions
Question 13
Which of the following is a User Directory feature?
- A. Guest authentication
- B. Dashboard
- C. Radius authorization
- D. Query Switches
- E. Assets portal
Answer:
A
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
Guest authentication is a User Directory feature. According to the Forescout Authentication Module
Overview Guide and the User Directory Plugin Configuration Guide, the User Directory Plugin
enables guest authentication and management through configured directory servers.
User Directory Plugin Features:
The User Directory Plugin (version 6.4+) provides the following core features:
Endpoint User Resolution - Resolves endpoint user details by querying directory servers
User Authentication - Performs user authentication via configured internal and external directory
servers (Active Directory, LDAP, etc.)
Guest Authentication - Enables authentication and registration of guest users on the network
Guest Sponsorship - Allows corporate employee sponsors to approve guest network access
Guest Management Portal - Provides functionality for managing guest hosts and guest portal access
Directory Server Integration - Integrates with enterprise directory servers for credential validation
Guest Management Capabilities:
The User Directory Plugin specifically enables:
Guest user registration and authentication
Guest approval workflows through sponsor groups
Guest session management
Guest password policies
Guest tag management for categorization
Why Other Options Are Incorrect:
B . Dashboard - This is a general console feature, not specific to the User Directory plugin
C . Radius authorization - This is the function of the RADIUS plugin, not the User Directory plugin
(though they work together in the Authentication Module)
D . Query Switches - This is a function of the Switch plugin, not the User Directory plugin
E. Assets portal - This is a general Forescout platform feature, not specific to the User Directory
plugin
Authentication Module Structure:
According to the documentation, the Authentication Module consists of two plugins:
RADIUS Plugin - Handles 802.1X authentication, authorization, and accounting
User Directory Plugin - Handles user resolution, authentication, and guest management
These work together but have distinct responsibilities. The User Directory Plugin specifically handles
guest authentication among its feature set.
Referenced Documentation:
Forescout Authentication Module Overview Guide Version 1.1
About the User Directory Plugin documentation
User Directory Plugin Server and Guest Management Configuration Guide
Question 14
When troubleshooting a SecureConnector management issue for a Windows host, how would you
determine if SecureConnector management packets are reaching CounterACT successfully?
- A. Use the tcpdump command and filter for tcp port 10005 traffic from the host IP address reaching the monitor port
- C. Use the tcpdump command and filter for tcp port 10003 traffic from the host IP address reaching the monitor port
- D. Use the tcpdump command and filter for tcp port 2200 traffic from the host IP address reaching the management port
- E. Use the tcpdump command and filter for tcp port 10003 traffic from the host IP address reaching the management port
Answer:
E
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
According to the Forescout Quick Installation Guide and official port configuration
documentation, SecureConnector for Windows uses TCP port 10003, and the management packets
should be captured from the host IP address reaching the management port (not the monitor port).
Therefore, the correct command would use tcpdump filtering for tcp port 10003 traffic reaching the
management port.
SecureConnector Port Assignments:
According to the official documentation:
SecureConnector Type
Port
Protocol
Function
Windows
10003/TCP
TLS (encrypted)
Allows SecureConnector to create a secure encrypted TLS
connection to the Appliance from Windows machines
Allows SecureConnector to create a secure encrypted TLS
OS X
10005/TCP
TLS (encrypted)
connection to the Appliance from OS X machines
TLS 1.2
Allows SecureConnector to create a secure connection over
Linux
10006/TCP
(encrypted)
TLS 1.2 to the Appliance from Linux machines
Port 2200 is for Legacy Linux SecureConnector (older versions using SSH encryption), not for
Windows.
Forescout Appliance Interface Types:
Management Port - Used for administrative access and SecureConnector connections
Monitor Port - Used for monitoring and analyzing network traffic
Response Port - Used for policy actions and responses
SecureConnector connections reach the management port, not the monitor port.
Troubleshooting SecureConnector Connectivity:
To verify that SecureConnector management packets from a Windows host are successfully reaching
CounterACT, use the following tcpdump command:
bash
tcpdump -i [management_interface] -nn "tcp port 10003 and src [windows_host_ip]"
This command:
Monitors the management interface
Filters for TCP port 10003 traffic
Captures packets from the Windows host IP address reaching the management port
Verifies bidirectional TLS communication
Why Other Options Are Incorrect:
A . tcp port 10005 from host IP reaching monitor port - Port 10005 is for OS X, not Windows; should
reach management port, not monitor port
B . tcp port 2200 reaching management port - Port 2200 is for legacy Linux SecureConnector with
SSH, not Windows
C . tcp port 10003 reaching monitor port - Port 10003 is correct for Windows, but should reach
management port, not monitor port
D . tcp port 2200 reaching management port - Port 2200 is for legacy Linux SecureConnector, not
Windows
SecureConnector Connection Process:
According to the documentation:
SecureConnector on the Windows endpoint initiates a connection to port 10003
Connection is established to the Appliance's management port
When SecureConnector connects to an Appliance or Enterprise Manager, it is redirected to the
Appliance to which its host is assigned
Ensure port 10003 is open to all Appliances and Enterprise Manager for transparent mobility
Referenced Documentation:
Forescout Quick Installation Guide v8.2
Forescout Quick Installation Guide v8.1
Port configuration section: SecureConnector for Windows
Question 15
What is the command to monitor system memory and CPU load with 5 second update intervals?
- A. watch -t 5 vmstat
- B. vmstat 5
- C. vmstat -t 5
- D. watch uptime
- E. watch -n 10 vmstat
Answer:
B
Explanation:
Comprehensive and Detailed Explanation From Exact Extract of Forescout Platform Administration
and Deployment:
The correct command to monitor system memory and CPU load with 5 second update intervals
is vmstat 5. According to the official Linux documentation and Forescout CLI reference materials,
the vmstat command uses a straightforward syntax where the first numerical parameter specifies the
delay interval in seconds.
vmstat Command Syntax:
The vmstat (Virtual Memory Statistics) command uses the following syntax:
bash
vmstat [options] [delay] [count]
Where:
delay - The time interval (in seconds) between updates
count - The number of updates to display (optional; if omitted, displays indefinitely)
vmstat 5 Command:
When you execute vmstat 5:
Updates are displayed every 5 seconds
Continues indefinitely until manually stopped
Shows memory and CPU statistics in each update
Example output:
text
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 1166396 70768 2233228 0 0 0 13 10 24 0 0 100 0 0
0 0 0 1165568 70776 2233352 0 0 0 8 121 224 0 0 99 0 0
0 0 0 1166608 70784 2233352 0 0 0 53 108 209 0 0 100 0 0
Each line represents a new report generated at 5-second intervals.
Memory and CPU Information Provided:
The vmstat output includes:
Memory Columns:
free - Amount of idle memory
buff - Amount of memory used as buffers
cache - Amount of memory used as cache
swpd - Amount of virtual memory used
si/so - Memory swapped in/out
CPU Columns:
us - Time spent running user code
sy - Time spent running kernel code
id - Time spent idle
wa - Time spent waiting for I/O
st - Time stolen from virtual machine
Why Other Options Are Incorrect:
A . watch -t 5 vmstat - Incorrect syntax; -t removes headers, not set intervals; interval flag is -n, not -t
C . vmstat -t 5 - The -t option adds a timestamp to output, but doesn't set the interval; the 5 would be
ignored
D . watch uptime - The uptime command displays system uptime and load average but not detailed
memory/CPU stats; watch requires -n flag for interval specification
E . watch -n 10 vmstat - While syntactically valid, this uses a 10-second interval, not 5 seconds; also
unnecessary since vmstat already supports delay parameter directly
Additional vmstat Examples:
According to documentation:
bash
vmstat 5 5
# Display 5 updates at 5-second intervals
vmstat 1 10 # Display 10 updates at 1-second intervals
vmstat -t 5 5 # Display 5 updates every 5 seconds WITH timestamps
First Report Note:
According to the documentation:
"When you run vmstat without any parameters, it shows system values based on the averages for
each element since the server was last rebooted. These results are not a snapshot of current values."
The first report with vmstat 5 shows averages since last reboot; subsequent reports show statistics
for each 5-second interval.
Referenced Documentation:
Linux vmstat Command Documentation
RedHat vmstat Command Guide
Oracle Solaris vmstat Manual
Microsoft Azure Linux Troubleshooting Guide
IBM AIX vmstat Documentation