FCP_FMG_AD-7.6 Fortinet NSE 5 - FortiManager 7.6 Administrator Questions and Answers

Activating workspace mode in the ADOM settings allows multiple administrators to work concurrently in the same ADOM by isolating their configuration changes in separate workspaces, preventing conflicts and enabling effective collaboration.

ADOM revisions save the current state of all policy packages and objects within an ADOM, allowing administrators to track changes over time and revert to previous configurations if needed.

The correct answer is D . In FortiManager HA manual mode, the study guide explains what happens when members change: if the primary fails, you must manually promote a secondary and repoint the others, but that is not this scenario. For a failed secondary , the relevant exact extract is: “if you remove a secondary member from the HA configuration, the primary FortiManager removes the secondary serial number from the central management configuration of FortiGate, and updates the managed FortiGate devices immediately.”

Operationally, in the HA configuration, removing that failed secondary means deleting its HA peer entry from the primary, which corresponds to removing the failed device’s peer IP . A is false because manual HA is not transparent in this case. B is only a diagnostic detail. C applies when the primary fails, not a secondary.

=========

The correct answer is D . The exact extract from the study guide says a revert operation “Reverts only the device database to the previous revision” and “Does not revert policies and objects—you must import them.” It further states: “Performing a revert operation followed by an installation only reverts device-level changes and does not revert policy packages.”

That exactly matches the CLI output. The device shows the device manager portion as installed and synchronized, while the policy package appears as unknown, which indicates the revert and installation affected the device-level configuration only . It did not reinstall or synchronize the policy package. Therefore B is incorrect. A is unsupported by the source, and C is unrelated because the firmware version is already shown in the device list output. The study guide also states that after revert you must use Import Configuration to synchronize policy information.

The FortiManager 7.6 Administrator Study Guide is explicit for the scenario where both FortiManager and FortiGate are behind NAT . It states that FortiManager can discover FortiGate through the FortiGate NATed IP address , which makes A correct. It also explains that in this scenario, the FortiManager NATed IP address is not configured on FortiGate by default under central management , which makes B correct.

C is incorrect because FortiGate must use the FortiManager NATed IP address , not the non-NATed IP, if it needs to announce itself or reestablish the FGFM tunnel. D is also incorrect because in this NAT scenario, if the tunnel is torn down, only FortiGate attempts to reestablish the connection ; FortiManager does not automatically do so.

=========

The command set workspace-mode normal enables Workspace (ALL ADOMs) . The study guide explicitly states that with this mode, “Workspace (ALL ADOMs): All ADOMs can be locked” and that enabling workspace mode “Disables concurrent read/write access to locked items” with “Read/write access for only one administrator—all others have read-only access.” That directly proves D .

A is also verified by the lab guide, which states: “If an administrator locked one or more ADOMs, and then logs out of FortiManager, all of those ADOMs are unlocked.” The phrase “one or more ADOMs” confirms that the same administrator can lock more than one ADOM at the same time.

C is incorrect because approval is required only in workflow mode , not in workspace normal.

=========

The correct answer is D . The lab guide explains that when an installation fails, the installation log shows the commands that the managed device received and accepted, as well as the commands that the managed device did not accept .

From the exhibit, FortiGate accepted the policy creation commands for policy ID 2 such as set srcintf port3, set dstintf port1, set srcaddr all, set dstaddr all, set action accept, and set schedule always. However, the line set users student failed with “entry not found in datasource” and “value parse error before ' student ' ” . That shows the user reference was not accepted, while the rest of the policy commands were processed. Therefore, policy ID 2 is still created, but without the remote user student . This rules out A , B , and C .

=========

Adding and managing FortiAnalyzer from FortiManager is recommended for handling a high volume of logs, as FortiAnalyzer is designed specifically for centralized log management, analysis, and reporting, which offloads this workload from FortiManager.

Using the Install Wizard is the recommended method to reinstall the central policy package on the BR1-FGT-1 firewall, ensuring all settings, installation targets, and dependencies are correctly processed during installation.

The correct answer is A . This conclusion comes from the HA settings shown in the exhibit plus Fortinet’s HA behavior. In the exhibit, HQ-NGFW-1 has memory-based-failover enabled , memory-failover-threshold 70 , memory-failover-monitor-period 50 , and its memory usage is about 90% , while HQ-NGFW-2 is about 48.7% . Fortinet’s official documentation states that memory-failover-threshold is the memory percentage that triggers failover, and memory-failover-monitor-period is the duration high memory must persist before failover occurs. It also states that if utilization stays above the threshold for the entire monitor period, a failover is triggered , and the peer becomes primary. ( Fortinet Document Library )

Because the condition was observed for 55 seconds , which is longer than the configured 50-second monitor period , the cluster would fail over from HQ-NGFW-1 to HQ-NGFW-2 due to the memory-failover-threshold condition. The priority setting does not explain this result here, because override is disabled , and flip-timeout governs subsequent memory-based failovers, not the initial trigger. ( Fortinet Document Library )

=========

When FortiManager is behind a NAT device, setting the NATed IP address (100.65.0.120) in the system admin settings causes FortiManager to use that NATed IP address for communication and configuration with FortiGate during discovery and management operations.

The correct answers are B and C . The FortiManager 7.6 Administrator Study Guide explicitly states: “Scripts that you run directly on remote devices also cause automatic updates and create a revision history.” This exact extract proves both results: FortiManager creates a new revision history and the device status becomes Auto-Updated , meaning the FortiGate change is automatically reflected in the FortiManager device-level database.

The lab guide also distinguishes this from database-targeted scripts by stating: “You must perform an installation if you run a script on a device database, policy package, or ADOM database.” That wording excludes Remote FortiGate Directly via CLI , so D is incorrect.

A is also incorrect because direct remote execution does not use the install preview workflow; preview and validation are tied to Install Wizard operations, not direct CLI execution.

=========

The most likely reason FortiGate HQ-NGFW-1 does not recognize the new IPS signature is that FortiManager and FortiGate have different IPS database versions. The FortiManager may have pushed a signature update that FortiGate has not yet synchronized or validated locally, causing the signature to be unrecognized.

The correct conclusion is D . The FortiManager 7.6 Administrator Study Guide defines Never Installed as a state where the policy package was never created and was never imported for a managed device . That means FortiManager may already know the device itself at the device layer, but the firewall policy layer has not yet been built for that device.

The lab guide confirms this behavior directly: when you choose Import Later in the Add Device wizard, the policy package status becomes Never Installed because there is still no policy package created for the added FortiGate devices.

So this is not a revision-history issue, and it does not mean ADOM policy changes are merely waiting for first install. It means the policies still exist only on the managed device side until they are imported into a FortiManager policy package.

=========

The correct answer is D . The FortiManager 7.6 Administrator Study Guide gives the exact extract under Web Filter and Email Filter : “fgdlinkd — Responsible for downloading web filter and email filter databases” . The same study guide section explains that the execute top command displays real-time CPU and RAM usage, and the %MEM column shows the memory percentage used by each process.

In the exhibit, the line for fgdlinkd shows %MEM 2.9 . Therefore, the process responsible for downloading the web and email filter databases is using 2.9% of RAM. That matches option D exactly. The other values belong to different processes, such as fgdsvr and other FortiGuard-related daemons, but not the downloader process identified in the study guide.

=========

The import report shows that a new policy package named Remote-FortiGate_root will be created in the FortiManager ADOM database, but some firewall addresses and policies failed to import due to interface binding conflicts.