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

Question 81. Which file formats can an administrator upload for an EMS server certificate?

1. TXT, CSV, and XML only
2. PEM, DER, or PKCS12
3. ISO and IMG only
4. CAB and MSI only

Correct Answer: 2. PEM, DER, or PKCS12

Explanation:

FortiClient EMS supports administrator-uploaded server certificates in PEM, DER, and PKCS12 formats. Server certificates protect HTTPS communications and help administrators present a certificate that endpoints and browsers can trust instead of relying on the built-in default certificate. EMS also supports other certificate sources, including ACME-managed certificates and FortiCare-generated certificates in supported configurations. Selecting the appropriate certificate format and ensuring the complete certificate chain is trusted are important when troubleshooting browser warnings, remote administrator access, or endpoint communication issues involving certificate validation.

Question 82. Which statement about the default FortiClient EMS server certificate is correct?

1. It must be renewed through Active Directory every 30 days
2. It can be deleted after uploading another certificate
3. It can only be used for FortiAnalyzer connections
4. EMS uses it when no other certificate is available, and the administrator cannot delete it**

Correct Answer: 4. EMS uses it when no other certificate is available, and the administrator cannot delete it

Explanation:

FortiClient EMS includes a default server certificate that is available when another suitable certificate has not been configured. Fortinet documents that the default certificate cannot be deleted. Uploaded, ACME, or other supported certificates are generally preferable for production environments because they can provide a certificate chain that clients already trust. When another supported certificate is available, the default certificate is not intended to be selected in the same way as the preferred alternatives. Administrators troubleshooting HTTPS trust problems should review the active EMS server certificate and certificate chain rather than attempting to remove the built-in default certificate.

Question 83. What is the PRIMARY benefit of configuring an ACME certificate on FortiClient EMS?

1. It allows EMS to use certificates managed automatically through an ACME-compatible certificate authority such as Let’s Encrypt
2. It replaces EMS licensing
3. It converts endpoint certificates into VPN passwords
4. It eliminates the need for DNS resolution

Correct Answer: 1. It allows EMS to use certificates managed automatically through an ACME-compatible certificate authority such as Let’s Encrypt

Explanation:

EMS supports certificates obtained and managed through the Automated Certificate Management Environment, or ACME, protocol. Let’s Encrypt is a well-known public certificate authority using ACME, though other ACME-compatible services can also be used. ACME simplifies certificate lifecycle management by supporting automated issuance and renewal processes. This can reduce the administrative burden associated with manually uploading replacement server certificates when certificates approach expiration. ACME does not replace DNS, licensing, or endpoint authentication requirements; the EMS hostname still needs to resolve correctly and clients still need a valid trust path to the certificate being presented.

Question 84. What is the purpose of an admin role in FortiClient EMS?

1. To assign FortiClient licenses to individual endpoints
2. To determine the operating system installed on endpoints
3. To define which EMS administrative permissions an administrator account receives
4. To configure FortiGate routing policies

Correct Answer: 3. To define which EMS administrative permissions an administrator account receives

Explanation:

EMS admin roles implement role-based administrative access. A role contains permissions across categories such as endpoints, policies, and settings, and the role is then assigned to administrator accounts. EMS includes several built-in roles and also allows administrators with appropriate privileges to create custom roles. If a role does not permit a particular function, EMS hides or disables the relevant menu items or controls. This allows organizations to separate responsibilities—for example, giving a support technician endpoint-management permissions without granting full authority over server settings or administrator accounts.

Question 85. Which built-in EMS admin role is the only built-in role with access to the Administration section of the GUI?

1. Read-only administrator
2. Endpoint administrator
3. Standard administrator
4. Super administrator

Correct Answer: 4. Super administrator

Explanation:

The Super administrator is the most privileged built-in EMS role. Fortinet documents that it has complete access to EMS permissions and is the only built-in role with access to the Administration section of the GUI. It can work with configured Windows and LDAP users and manage user privileges and permissions. The default admin account is a Super administrator and cannot be assigned a different admin role. Because of the role’s broad authority, organizations should restrict Super administrator access to personnel who genuinely require full EMS administrative control.

Question 86. What permissions does the built-in Standard administrator role normally have?

1. All endpoint and policy permissions, with read-only access to settings permissions
2. No permissions unless individually enabled
3. Read-only endpoint permissions only
4. Full access to the Administration section and user-role configuration

Correct Answer: 1. All endpoint and policy permissions, with read-only access to settings permissions

Explanation:

The Standard administrator built-in role provides broad endpoint and policy administration capabilities but limits settings permissions to read-only access. This makes it suitable for administrators who need to manage FortiClient endpoints and policies without receiving the highest level of control over EMS system configuration and administrator management. The role differs from the Super administrator, which has complete permissions and Administration access, and from the Endpoint administrator, which has full endpoint permissions but more restricted policy and settings access. Understanding the default role differences is important when implementing least-privilege EMS administration.

Question 87. What permissions characterize the built-in Endpoint administrator role?

1. Full access to all EMS settings and admin accounts
2. All endpoint permissions, with read-only permissions for policy and settings areas
3. No endpoint permissions but full policy permissions
4. Only permission to view EMS licenses

Correct Answer: 2. All endpoint permissions, with read-only permissions for policy and settings areas

Explanation:

The Endpoint administrator role is intended for administrators whose responsibilities center on managed endpoints. It includes all endpoint permissions while providing read-only access to policy and settings permissions. This enables operational tasks on endpoints while limiting broader configuration changes. EMS’s permission reference further divides permissions into specific capabilities, such as running endpoint commands, managing groups, viewing or managing profiles, and quarantining endpoints. A custom admin role can provide even finer separation when the built-in role grants more capability than a particular support team should have.

Question 88. What is true of the built-in Restricted administrator role?

1. It has full endpoint permissions
2. It can edit profiles but not policies
3. It has no permissions enabled by default
4. It automatically becomes a Super administrator after login

Correct Answer: 3. It has no permissions enabled by default

Explanation:

The built-in Restricted administrator role has no permissions enabled. It can serve as a highly constrained starting point where the organization does not want an account to receive operational access through one of the broader predefined roles. EMS hides or disables functions that an administrator’s role does not permit. Organizations that require a very specific permission combination can also create custom roles rather than relying solely on the predefined ones. Role selection should follow the principle of least privilege so administrator accounts receive only the endpoint, policy, and settings capabilities needed for their assigned duties.

Question 89. An administrator wants to create an EMS admin account based on an existing Active Directory user. What must be true first?

1. The user must already exist in an AD domain configured in EMS as an LDAP authentication source
2. FortiAnalyzer must create the account first
3. The user must have a FortiGate local account
4. EMS must create the Active Directory account automatically

Correct Answer: 1. The user must already exist in an AD domain configured in EMS as an LDAP authentication source

Explanation:

EMS can create administrator access based on LDAP users, but those users must already exist in the Active Directory domain configured as an authentication server. EMS derives the available LDAP-user list from imported or configured directory information; it does not create new Active Directory accounts itself. Administrators go to Administration > Admin Users, choose LDAP as the user source, select the configured authentication server, and assign appropriate EMS permissions or roles. This allows organizations to integrate EMS administrative access with existing enterprise identity management while still controlling authorization through EMS roles.

Question 90. Why does Fortinet recommend using an FQDN rather than only an IP address for FortiClient-to-EMS connectivity?

1. An FQDN disables certificate validation
2. An FQDN makes EMS licensing unnecessary
3. An FQDN prevents endpoints from leaving the corporate network
4. It simplifies EMS IP changes, migration to another EMS instance, and internal/external DNS resolution**

Correct Answer: 4. It simplifies EMS IP changes, migration to another EMS instance, and internal/external DNS resolution

Explanation:

Fortinet recommends an EMS FQDN because it provides flexibility unavailable when endpoints are tied directly to a single IP address. DNS can resolve the same EMS hostname to an internal address for devices inside the corporate network and to an external address for remote endpoints. The FQDN also makes future EMS migration or IP-address changes easier because DNS can be updated without reconfiguring every endpoint. This is especially valuable for mobile users who move between internal and external networks while maintaining their FortiClient Telemetry connection to EMS.

Question 91. When external FortiClient endpoints use the EMS FQDN from outside the corporate network, what port does Fortinet documentation specifically describe forwarding to the internal EMS address?

1. TCP 22
2. TCP 443 only
3. TCP 8013
4. UDP 53

Correct Answer: 3. TCP 8013

Explanation:

Fortinet’s post-installation guidance describes an internal/external DNS design in which the same EMS FQDN can resolve differently depending on endpoint location. For external clients, the organization’s externally reachable address should forward traffic received on port 8013 to the internal EMS address so FortiClient can maintain the required management connection. The exact deployment should still follow the complete EMS ports and services documentation and organizational firewall design. For exam purposes, port 8013 is important because it is commonly associated with FortiClient Telemetry communication to EMS.

Question 92. Which EMS migration path is correct for moving directly to FortiClient EMS 7.4.0 from the earlier Windows-based EMS generation?

1. Any EMS 6.x version can migrate directly to 7.4.0
2. Migrate from EMS 7.2.4; earlier releases must first be upgraded to 7.2.4
3. Only EMS 7.2.5 can migrate to 7.4.0
4. No migration path from Windows EMS exists

Correct Answer: 2. Migrate from EMS 7.2.4; earlier releases must first be upgraded to 7.2.4

Explanation:

For the original EMS 7.4.0 migration, Fortinet specifies EMS 7.2.4 as the supported source release. Environments on an earlier EMS version must first follow the supported upgrade path to 7.2.4 and then migrate from the Windows Server architecture to the Linux-based EMS 7.4.0 architecture. This is not a conventional in-place upgrade from arbitrary older releases. The migration architecture changed significantly with EMS 7.4, making the supported source version and migration procedure important operational details. Administrators should always consult the FortiClient upgrade path before production migration.

Question 93. Why can EMS 7.2.5 not be migrated directly to EMS 7.4.0?

1. EMS 7.2.5 uses a MySQL database
2. EMS 7.2.5 supports only macOS endpoints
3. EMS 7.2.5 cannot store endpoint policies
4. EMS 7.2.5 was released after EMS 7.4.0 and is not a supported 7.4.0 migration source**

Correct Answer: 4. EMS 7.2.5 was released after EMS 7.4.0 and is not a supported 7.4.0 migration source

Explanation:

Fortinet explicitly notes that EMS 7.2.5 cannot migrate to EMS 7.4.0 because 7.2.5 was released after 7.4.0. For the EMS 7.4.0 migration workflow, 7.2.4 is the supported source release. This example illustrates why administrators should not assume that a numerically newer patch in an older branch is automatically a valid migration source for every newer major branch release. Supported upgrade and migration paths are release specific. Before maintenance, administrators should verify the Fortinet upgrade path and release-specific migration documentation rather than relying only on version-number comparisons.

Question 94. What should an administrator do before any EMS version upgrade or other major maintenance?

1. Disable all endpoint policies permanently
2. Back up the EMS database and consider a full server backup or VM snapshot
3. Delete old FortiClient installers
4. Revoke every server certificate

Correct Answer: 2. Back up the EMS database and consider a full server backup or VM snapshot

Explanation:

Fortinet strongly recommends backing up the EMS database before upgrades or other maintenance. The documentation also suggests considering a full server backup or VM snapshot where possible. This provides a recovery path if the maintenance operation fails or produces unexpected results. An EMS database contains critical management configuration and state, so performing disruptive maintenance without a backup creates avoidable operational risk. Backup planning should be part of the maintenance procedure itself rather than an afterthought triggered only after a failed upgrade. Administrators should also verify backup integrity and know the applicable restoration procedure.

Question 95. What HA operating mode does FortiClient EMS support for the EMS application nodes?

1. Active-passive
2. Active-active only
3. Round-robin active-active only
4. Anycast only

Correct Answer: 1. Active-passive

Explanation:

FortiClient EMS application high availability uses an active-passive architecture. Two or more EMS nodes connect to a common database or supported PostgreSQL database cluster. The first EMS node installed acts as the primary, while additional nodes join as secondary nodes ready to assume the active role during failover. This provides redundancy at the EMS application layer. Database HA can also be designed separately through a PostgreSQL cluster. Administrators should distinguish application-node redundancy from database redundancy because a highly available EMS design may need to address both layers to eliminate single points of failure.

Question 96. What database relationship is required among EMS application nodes in an HA cluster?

1. Every EMS node must use a completely separate unrelated database
2. Secondary nodes store configuration only in local files
3. Two or more EMS nodes connect to the same database or supported PostgreSQL database cluster
4. EMS HA requires Microsoft SQL Server

Correct Answer: 3. Two or more EMS nodes connect to the same database or supported PostgreSQL database cluster

Explanation:

In FortiClient EMS application HA, the EMS nodes share the database layer. Two or more EMS nodes connect to the same standalone PostgreSQL server or to a supported list of PostgreSQL nodes forming a database cluster. Each EMS node registers itself in the shared database and retrieves its configuration from that common data source. This shared configuration allows a secondary EMS node to take over the active application role during failover. For full resilience, organizations may also deploy PostgreSQL database HA rather than leaving one standalone database as a remaining point of failure.

Question 97. In a documented EMS HA georedundancy test, how can an administrator simulate failure of the primary EMS application node?

1. Delete the EMS database
2. Revoke the FortiClient license
3. Stop DNS service on every endpoint
4. Stop the FortiClient Endpoint Management Server Monitor Service on the primary node and verify secondary takeover**

Correct Answer: 4. Stop the FortiClient Endpoint Management Server Monitor Service on the primary node and verify secondary takeover

Explanation:

Fortinet’s HA georedundancy validation procedure recommends simulating application-node failure by stopping the FortiClient Endpoint Management Server Monitor Service on the primary node. Administrators should then verify that a secondary node becomes the EMS primary and confirm that FortiClient can still register successfully through the shared FQDN. This controlled failover test validates not only EMS node state but also DNS, network access, database availability, and endpoint connectivity. Fortinet recommends performing georedundancy and failover testing with a test endpoint before placing the design into full production service.

Question 98. What is the purpose of the EMS High Availability Keep Alive Interval setting?

1. It controls the interval used by the HA mechanism to monitor node availability
2. It controls FortiClient antivirus signature age
3. It defines the user’s EMS login timeout
4. It sets the Web Filter schedule

Correct Answer: 1. It controls the interval used by the HA mechanism to monitor node availability

Explanation:

The High Availability Keep Alive Interval is part of EMS HA configuration and controls timing associated with node-health monitoring in the HA environment. HA systems must detect when the active EMS node is no longer available so that a secondary can assume the primary role. Administrators can configure the interval from the EMS settings in supported HA deployments. The parameter is unrelated to endpoint antivirus signatures, user login sessions, or Web Filter schedules. HA timing should be selected with care because failover responsiveness and infrastructure stability both depend on appropriate health-monitoring behavior.

Question 99. Which certificate can EMS revoke and update when administrators suspect that the certificate used for ZTNA trust has been compromised?

1. Only the endpoint’s Windows logon certificate
2. Only an Active Directory domain-controller certificate
3. The EMS CA certificate used for ZTNA, which EMS can replace and propagate to FortiOS and FortiClient
4. Only the FortiAnalyzer server certificate

Correct Answer: 3. The EMS CA certificate used for ZTNA, which EMS can replace and propagate to FortiOS and FortiClient

Explanation:

EMS maintains a CA certificate used in supported ZTNA workflows. The EMS settings display its expiration information and provide a Revoke and Update action. Fortinet notes that administrators may use this option when the certificate is compromised and can no longer be trusted. EMS then works with FortiOS and FortiClient to establish updated certificate information. Replacing a trust certificate can affect existing connections, so administrators should treat revocation as a controlled security operation rather than routine maintenance. The feature requires the appropriate FortiClient ZTNA or EPP licensing.

Question 100. A company is moving from EMS 7.2.4 on Windows Server to EMS 7.4.0, wants resilient remote endpoint connectivity, and requires administrative separation of duties. Which approach BEST meets these requirements?

1. Perform an unsupported in-place Windows upgrade and give every administrator the default admin account
2. Keep endpoints permanently configured with the old EMS IP and use one shared Super administrator account
3. Migrate using the supported 7.2.4-to-7.4.0 Linux workflow, use an EMS FQDN for endpoint connectivity, back up before maintenance, and assign administrators least-privilege EMS roles
4. Disable certificates and HA so migration is simpler

Correct Answer: 3. Migrate using the supported 7.2.4-to-7.4.0 Linux workflow, use an EMS FQDN for endpoint connectivity, back up before maintenance, and assign administrators least-privilege EMS roles

Explanation:

A reliable EMS migration combines several Fortinet best practices. EMS 7.4.0 uses a Linux architecture and supports migration from EMS 7.2.4 through the documented workflow rather than an arbitrary in-place Windows upgrade. Fortinet recommends backing up before maintenance. Using an FQDN makes endpoint connectivity more resilient to IP changes and server migration, particularly for devices that move between internal and external networks. Finally, EMS role-based administration allows organizations to avoid sharing the highly privileged default administrator account and instead assign endpoint, policy, or settings permissions according to job responsibilities.