View Full Fortinet FCP_FCT_AD-7.4 Exam Dumps and Practice Test Dumps.

Question 101. In FortiClient EMS, an endpoint has not communicated with EMS for more than eight hours. Which endpoint status should EMS normally display?

1. Never Seen
2. Online
3. Offline
4. Quarantined

Correct Answer: 3. Offline

Explanation:

FortiClient EMS uses endpoint communication history to show endpoint connectivity status. An endpoint is considered Online when it has been seen within fewer than three keep-alive timeouts. It becomes Away when it has been offline but for less than eight hours. Once the endpoint has been offline for more than eight hours, EMS displays the Offline status. Never Seen is reserved for an endpoint that has never registered with EMS. These status distinctions help administrators determine whether a device is temporarily disconnected, has been unavailable for an extended period, or has never successfully completed EMS registration.

Question 102. What does the “Away” status indicate for a managed FortiClient endpoint in EMS?

1. The endpoint is offline but has been unavailable for less than eight hours
2. The endpoint has never registered to EMS
3. The endpoint is quarantined from all network access
4. The endpoint has been offline for more than eight hours

Correct Answer: 1. The endpoint is offline but has been unavailable for less than eight hours

Explanation:

EMS uses Away to identify a managed endpoint that is currently disconnected but has not yet been offline long enough to be classified as fully Offline. Fortinet documents that an endpoint is Away when it has been offline for less than eight hours. After more than eight hours without communication, the status changes to Offline. This distinction is useful when investigating transient connectivity issues, such as laptops that have recently left the corporate network or mobile endpoints that are temporarily unavailable. It helps administrators distinguish a short-term loss of connectivity from a longer-lasting endpoint-management problem.

Question 103. An endpoint appears in EMS with a “Never Seen” status. What does this mean?

1. The endpoint has been offline for over eight hours
2. The endpoint has been quarantined
3. The endpoint failed a vulnerability scan
4. The endpoint has never successfully registered with EMS

Correct Answer: 4. The endpoint has never successfully registered with EMS

Explanation:

The Never Seen endpoint status indicates that EMS knows about the endpoint—for example, through imported directory information or discovery—but FortiClient on that endpoint has never successfully registered to EMS. This differs from Online, Away, and Offline states, all of which imply that EMS has previously communicated with the managed endpoint. When troubleshooting a Never Seen endpoint, administrators should investigate whether FortiClient is installed, whether the endpoint can reach EMS, whether required Telemetry settings and ports are correct, and whether the deployment or invitation workflow successfully directed FortiClient to the intended EMS server.

Question 104. FortiClient Telemetry is configured without an explicit port number. Which behavior should the administrator expect?

1. FortiClient selects a random available TCP port
2. FortiClient attempts to connect using the default Telemetry port, TCP 8013
3. FortiClient uses TCP 443 automatically
4. FortiClient waits for FortiGate to assign a port

Correct Answer: 2. FortiClient attempts to connect using the default Telemetry port, TCP 8013

Explanation:

Fortinet documents TCP 8013 as the default port for FortiClient Telemetry communication with EMS. If no alternative port is supplied, FortiClient attempts to connect on TCP 8013. The Telemetry connection is used for endpoint management, including receiving profiles and policies and exchanging endpoint status information. Administrators can change the port, but both EMS and FortiClient configurations must remain consistent. Because Telemetry is fundamental to centralized management, firewall policies, NAT, DNS, and server configuration must permit the required communication between remote endpoints and EMS.

Question 105. What is a potential consequence of changing the EMS FortiClient Telemetry port while some endpoints are still configured to use the default port?

1. Those endpoints can be locked out of EMS connectivity
2. EMS automatically reconfigures every disconnected endpoint through DNS
3. FortiAnalyzer takes over endpoint management
4. FortiClient automatically switches to UDP

Correct Answer: 1. Those endpoints can be locked out of EMS connectivity

Explanation:

Changing the FortiClient Telemetry port requires coordination because endpoints must know which port EMS is listening on. Fortinet specifically warns that changing the Telemetry port in EMS can lock out endpoints that are still attempting to connect on the default TCP 8013 port. If those endpoints lose communication before receiving the new configuration, EMS cannot simply push the corrected value through the broken connection. Administrators should therefore plan Telemetry-port changes carefully, verify endpoint configuration and firewall rules, and consider how remote or temporarily disconnected endpoints will learn the new connection settings before changing production connectivity.

Question 106. Which statement BEST describes the security of FortiClient Telemetry communication with EMS?

1. Telemetry exchanges are sent in clear text for performance
2. Telemetry uses only ICMP
3. FortiClient communicates with EMS through an SSL connection that requires a valid certificate
4. Telemetry requires FortiAnalyzer to encrypt traffic

Correct Answer: 3. FortiClient communicates with EMS through an SSL connection that requires a valid certificate

Explanation:

FortiClient Telemetry communication is protected using SSL. Fortinet documents that protocol exchanges between FortiClient and EMS or FortiGate flow through the secure SSL connection and require a valid certificate. The connection closes after the required protocol exchanges are completed. This protects endpoint-management traffic from being transmitted as unprotected clear text. Administrators can strengthen Telemetry registration further by configuring a preshared password or connection key where appropriate. Certificate problems, trust-chain issues, or mismatched connection settings can therefore cause Telemetry registration or management communication failures even when basic TCP reachability exists.

Question 107. Which additional control can be configured for FortiClient Telemetry connections to EMS?

1. A DHCP reservation
2. A preshared password or connection key
3. A FortiAnalyzer report template
4. An OSPF authentication key

Correct Answer: 2. A preshared password or connection key

Explanation:

FortiClient EMS can require a preshared password or connection key for Telemetry connections. This adds another control to the SSL-protected endpoint-management channel and can help ensure that only endpoints with the expected connection information establish a valid EMS relationship. It does not replace the requirement for proper certificates or network connectivity. Administrators designing secure onboarding should consider Telemetry credentials together with deployment packages, invitations, EMS certificates, endpoint policies, and firewall rules. If an endpoint repeatedly fails to register despite reaching the EMS server, checking the configured connection key or password can be an important troubleshooting step.

Question 108. An administrator enables “Start at a Scheduled Time” in an EMS deployment configuration. What can the FortiClient user normally do?

1. The user receives no notification and cannot influence installation
2. The user must uninstall FortiClient first
3. The user can only postpone installation for seven days
4. The user can accept the default scheduled time, choose a custom install time, or install immediately**

Correct Answer: 4. The user can accept the default scheduled time, choose a custom install time, or install immediately

Explanation:

When Start at a Scheduled Time is enabled, FortiClient notifies the endpoint user that a newer FortiClient version is expected to be installed. The EMS administrator’s configured time appears as the default scheduled time, but the notification also allows the user to configure a custom installation time or choose to install immediately. This provides controlled flexibility in normal interactive deployment scenarios. If administrators require a deployment that users cannot reschedule, they should also consider Unattended Installation, which changes how much control the user has over installation timing and reboot behavior.

Question 109. What happens when “Start at a Scheduled Time” is disabled in an EMS deployment configuration?

1. The FortiClient installation starts immediately without user interaction
2. EMS waits until midnight automatically
3. The deployment remains permanently pending
4. The user must manually download FortiClient from Fortinet

Correct Answer: 3. The FortiClient installation starts immediately without user interaction

Explanation:

Fortinet documents that when Start at a Scheduled Time is disabled, the deployment begins immediately rather than presenting the normal scheduling interaction to the endpoint user. This is useful when the administrator wants installation to begin as soon as the deployment configuration applies. By contrast, enabling scheduled installation displays a notification and gives the user scheduling choices unless unattended behavior changes those options. Deployment timing should be selected according to operational requirements, because immediate software installation or upgrades can affect users if a reboot or driver update becomes necessary during active working hours.

Question 110. What is the effect of enabling “Unattended Installation” in an EMS deployment configuration?

1. FortiClient installs only when the user manually launches the installer
2. The endpoint user cannot modify the installation schedule, and a required reboot can occur without warning logged-in users
3. EMS deploys FortiClient only to servers
4. The installation is sent to FortiAnalyzer instead of the endpoint

Correct Answer: 1. The endpoint user cannot modify the installation schedule, and a required reboot can occur without warning logged-in users

Explanation:

Unattended Installation is intended for administrator-controlled deployment where end users should not be able to reschedule the installation. When enabled, users cannot modify the deployment schedule. Fortinet also warns that if the installation requires a reboot, the device can reboot without warning logged-in users. This makes the option powerful but potentially disruptive. Administrators should therefore use unattended installation carefully, considering maintenance windows, business-critical workloads, and whether unexpected reboots could interrupt user activity. In less restrictive deployments, scheduled installation and user-controlled reboot options may provide a better balance between administration and usability.

Question 111. What priority does a newly created EMS deployment configuration receive by default?

1. Highest priority
2. Random priority
3. The same priority as every existing deployment
4. Lowest priority

Correct Answer: 4. Lowest priority

Explanation:

A newly created deployment configuration receives the lowest priority by default. Fortinet notes that administrators cannot change its priority while initially creating the configuration; priority can be modified after the deployment configuration has been saved. Deployment priorities matter when an endpoint could qualify for multiple deployment configurations because EMS needs a deterministic way to determine which applicable configuration should take precedence. Administrators should therefore review deployment priority after creating new configurations, particularly in environments with separate packages for departments, operating systems, testing groups, or staged FortiClient upgrades.

Question 112. An administrator selects an Active Directory security group as the target of an EMS deployment configuration. What must that security group contain?

1. Only user objects
2. At least one computer object
3. Only administrator accounts
4. A FortiGate object

Correct Answer: 2. At least one computer object

Explanation:

When an Active Directory security group is selected for an EMS deployment configuration, Fortinet requires the group to contain a computer object. If the group contains only user objects, EMS does not assign the FortiClient installer to those users. Similarly, a Microsoft Entra ID security group used for deployment must include a device object. Deployment is endpoint oriented, so device or computer membership is needed rather than simply a collection of user identities. Administrators should verify directory-group object types when an apparently valid deployment group receives no FortiClient installation assignment.

Question 113. EMS pushes an uninstall to a managed FortiClient macOS endpoint. What limitation should the administrator know?

1. The remote uninstall does not remove FortiClient system extensions from macOS
2. macOS endpoints cannot be uninstalled through EMS at all
3. The uninstall automatically deletes the user’s home folder
4. EMS must first remove the endpoint from Active Directory

Correct Answer: 1. The remote uninstall does not remove FortiClient system extensions from macOS

Explanation:

Fortinet documents an important macOS limitation for EMS-pushed FortiClient uninstall operations: the remote uninstall does not remove FortiClient system extensions from the device. To remove those extensions as part of the uninstall process, a user can run the FortiClient uninstaller manually on the macOS endpoint. This difference matters when administrators expect a remotely initiated uninstall to leave no FortiClient system components behind. Windows and macOS endpoint-management behaviors are not always identical, so platform-specific deployment and removal requirements should be considered when planning lifecycle operations.

Question 114. During initial FortiClient deployment, which protocol can EMS use to probe endpoints?

1. SMTP
2. BGP
3. ICMP
4. SNMP exclusively

Correct Answer: 3. ICMP

Explanation:

FortiClient EMS can use ICMP for endpoint probing during initial FortiClient deployment. Fortinet lists ICMP as an outgoing requirement for this specific initial-deployment function. If endpoint probing does not work as expected, administrators should verify whether ICMP is allowed between EMS and the destination systems rather than focusing only on TCP Telemetry ports. Endpoint deployment involves multiple stages and protocols: probing helps identify or reach endpoints, installer download uses its own service, and post-installation endpoint management relies on FortiClient Telemetry. Understanding which protocol belongs to each stage simplifies deployment troubleshooting.

Question 115. Which default TCP port is used when endpoints download FortiClient deployment packages created by EMS?

1. TCP 22
2. TCP 10443
3. TCP 8015
4. TCP 25

Correct Answer: 2. TCP 10443

Explanation:

Fortinet lists TCP 10443 as the default incoming port used for FortiClient deployment-package downloads from EMS. This is separate from TCP 8013, which is used for FortiClient Telemetry endpoint management, and TCP 8015, which is associated with FortiOS-to-EMS communication. When an endpoint can register or communicate but cannot retrieve the required FortiClient installer, administrators should verify that the deployment download service and TCP 10443 path are accessible. Firewalls, NAT, reverse proxies, or security devices between remote endpoints and EMS must permit whichever ports the deployment architecture requires.

Question 116. Which TCP port does FortiClient EMS 7.4 documentation associate with FortiOS communication to EMS?

1. TCP 21
2. TCP 8013
3. TCP 8015
4. TCP 3389

Correct Answer: 3. TCP 8015

Explanation:

Fortinet documents TCP 8015 for communication between FortiOS and EMS. In relevant 7.4 deployments, EMS opens the port and FortiOS connects to EMS as a client for Security Fabric and ZTNA-related communication. Newer 7.4 documentation also describes the connection as supporting WebSocket-based notifications, while REST queries may use HTTPS separately. Administrators troubleshooting missing posture tags, ZTNA integration, or FortiGate/EMS synchronization should therefore verify that the required FortiOS-to-EMS communication paths are allowed in addition to endpoint Telemetry on TCP 8013.

Question 117. An endpoint policy contains three separate on-fabric detection rules. The endpoint satisfies only one of them. How does EMS classify the endpoint?

1. Off-fabric because all three rules must match
2. Quarantined
3. Unmanaged
4. On-fabric because satisfying any one of the selected detection rules is sufficient**

Correct Answer: 4. On-fabric because satisfying any one of the selected detection rules is sufficient

Explanation:

When multiple previously created on-fabric detection rules are selected in an endpoint policy, EMS treats them using OR behavior: an endpoint is considered on-fabric when it satisfies any one of the selected rules. This differs from the rule logic inside one individual rule set containing several detection types, where all configured conditions in that set may need to match. The distinction is important for exam and troubleshooting scenarios. Administrators should identify whether they are discussing multiple detection rules attached to a policy or multiple conditions nested inside one detection rule configuration.

Question 118. When does EMS normally push newly saved endpoint-policy settings to a managed FortiClient endpoint?

1. With the endpoint’s next Telemetry communication
2. Only when EMS restarts
3. Only after FortiAnalyzer generates a report
4. Once per month during license synchronization

Correct Answer: 2. With the endpoint’s next Telemetry communication

Explanation:

After an endpoint policy is saved, EMS pushes the relevant configuration to the endpoint during the next FortiClient Telemetry communication. This means changes are not necessarily visible immediately on an endpoint that is offline or unable to communicate with EMS. The behavior also explains why policy troubleshooting must include connectivity and endpoint status. If the correct policy exists and has the expected priority but the endpoint still shows old settings, administrators should verify that FortiClient has communicated with EMS since the policy was modified and that Telemetry connectivity is functioning correctly.

Question 119. In EMS 7.4.5, which feature helps administrators investigate why a security posture tag was added to or removed from an endpoint?

1. The EMS license synchronization page
2. The FortiClient installer wizard
3. Tag Evaluation events and rule-evaluation details in the Endpoints events view
4. The Web Filter category page only

Correct Answer: 3. Tag Evaluation events and rule-evaluation details in the Endpoints events view

Explanation:

EMS 7.4.5 added improved visibility into security posture tag evaluation. Administrators can use the Tag Evaluation filter in the endpoint events view to find events showing when tags were added or removed. They can then open evaluation details, review the status of relevant tags, and inspect individual rule logic, values, and final evaluation results. Nested rules can also be examined. This greatly improves troubleshooting when an endpoint receives an unexpected ZTNA posture result because the administrator can see exactly which rule evaluated true or false instead of inferring the reason from the final tag alone.

Question 120. A managed endpoint has the correct profile assigned in EMS but still shows old settings and cannot download a newly scheduled FortiClient upgrade. What should an administrator check FIRST?

1. Replace FortiAnalyzer
2. Delete every EMS policy
3. Reinstall the EMS operating system
4. Verify endpoint Telemetry connectivity and the required EMS communication/download ports before changing policy configuration**

Correct Answer: 1. Verify endpoint Telemetry connectivity and the required EMS communication/download ports before changing policy configuration

Explanation:

Both profile updates and deployment actions depend on communication between the endpoint and EMS. Endpoint-policy changes are pushed during Telemetry communication, while deployment-package download uses the relevant EMS download service. If an endpoint still has old policy settings and also cannot retrieve a scheduled upgrade, a shared connectivity issue is more likely than two unrelated configuration failures. Administrators should verify endpoint status, TCP 8013 Telemetry connectivity, deployment download reachability such as TCP 10443, DNS/FQDN resolution, certificates, NAT, and firewalls. Only after confirming connectivity should they begin rebuilding otherwise correct profiles or deployment configurations.