Fortinet NSE6_FMG_AD-7.6 Fortinet NSE 6 - FortiManager 7.6 Administrator Exam Practice Test

Right after moving the ISFW device to a new ADOM, the status typically shows the policy package as never-installed, indicating that the device has been assigned to the new ADOM but no policy package has yet been installed in that ADOM.

The exhibit shows diagnose fmupdate view-serverlist fds with Server Override Mode: Strict and the active entry marked with *0 as 10.0.1.50 on port 8890, with source CLI. In FortiManager, Strict override mode means the system can communicate only with the configured override server list and cannot fall back to public FDS servers. Therefore, FortiManager gets antivirus and IPS updates from 10.0.1.50, making B correct.

The study guide also explains that antivirus and IPS override addresses are specifically used when a downstream FortiManager must download updates from an upstream FortiManager or another designated server.

So even though FDNI and DEFAULT entries are listed, Strict mode prevents fallback, and only the CLI-defined override server is actually used.

=========

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.

Enabling workflow mode along with the ADOM lock feature ensures that all configuration changes go through a centralized review and approval process before installation, allowing controlled and coordinated management of firewall policies by multiple administrators.

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)

=========

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 correct answers are A and C. The FortiManager 7.6 Administrator Study Guide states: “An ADOM revision creates a snapshot of all policy and object configurations for the ADOM”. The lab guide says the same thing in practical terms: “An ADOM revision creates a snapshot of the policy and object configuration for the ADOM” and that these revisions are useful for comparing differences and reverting to a previous revision.

Because the revision is a snapshot of the ADOM’s policy-and-object state, it saves the current ADOM policy/object state, which supports A and directly proves C. B is false because the study guide warns: “ADOM revisions can significantly increase the size of the configuration backup files.” D is not supported by the uploaded sources.

=========

The correct answers are A and C. The FortiManager 7.6 Administrator Study Guide gives the exact extract: “FortiManager creates a configuration revision when: FortiGate is added to FortiManager, Device changes are installed from FortiManager, FortiGate configuration is retrieved from FortiManager, A local change on FortiGate causes an automatic update”.

This exactly proves A, because device changes are installed from FortiManager, and C, because a local change on FortiGate causes an automatic update. The guide also states: “By default, all changes made on a managed FortiGate device are automatically updated on FortiManager and reflected in revision history”.

B and D only modify the FortiManager device-level database status to Modified. They do not, by themselves, create a new revision history until an install, retrieve, or auto-update occurs.

Meta fields in FortiManager can be added to objects as custom attributes, allowing administrators to categorize and add additional information to firewall objects for easier management and identification.

This point is not covered in the uploaded FortiManager 7.6 study guide, so the answer is based on Fortinet’s official FSSO documentation. Fortinet documents that in FSSO Collector Agent deployments, the FortiGate connects to the Collector Agent on TCP port 8000 by default, and if a different port is not configured, that is the port that must be reachable. Fortinet also explains that the DC agents monitor user logon events and pass the information to the Collector Agent, which stores the information and sends it to the FortiGate.

So, when login events are not reaching FortiGate, the most effective first troubleshooting step is to verify connectivity on TCP 8000 between the Collector Agent and FortiGate. Options A, B, and C are less direct and do not test the actual transport path used by the Collector Agent to send FSSO information to FortiGate.

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 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.

The most strongly supported answer is A. The study guide explicitly states: “In the case of having multiple FortiOS firmware versions on the same ADOM, it is recommended to use separate ADOMs instead.” It also says: “When you organize managed FortiGate devices, it is highly recommended that you group them based on their FortiOS firmware version. This is because valid command syntax varies by firmware version, which affects script compatibility.”

D is the other practical fix supported by FortiManager workflow. The study guide states that FortiManager can run scripts on multiple managed devices at once, and device groups let you run scripts on multiple devices instead of a single device. Combined with the firmware-version compatibility rule above, the correct operational approach is to keep version-specific scripts and apply them only to the matching device sets. B and C are not supported by the uploaded study guide as the recommended fix.

=========

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.

The correct answer is B. The FortiManager 7.6 Administrator Study Guide explicitly states: “CLI scripts use the FGFM tunnel and the FGFM tunnel is authenticated using the FortiManager and FortiGate serial numbers.” It also states: “Tcl scripts do not run through the FGFM tunnel like CLI scripts do. Tcl scripts use SSH to tunnel through FGFM and they require SSH authentication to do so.”

This is the exact reason CLI scripts can run without prompting for SSH authentication every time: they use the existing secure FGFM management tunnel, not a separate interactive SSH login. The FGFM section of the study guide also confirms that this is a secure communication tunnel established between FortiManager and managed FortiGate devices.

So the enabler is not legacy login, script location, or the “Remote FortiGate Directly” option by itself. It is the FGFM secure management tunnel.

The FortiManager 7.6 Administrator Study Guide states that global policies must be explicitly assigned: “You must explicitly assign global policy packages to specific ADOMs,” and FortiManager can also target specific policy packages in individual ADOMs. The lab guide confirms that assignment is performed from the Global Database ADOM: the administrator selects Global Database ADOM, clicks Assignment, adds the ADOM, chooses Specify Policy Packages To Assign, selects the target package, and then clicks Assign.

So creating a new policy package inside ADOM1 does not automatically inherit the existing global package assignment. It also does not automatically install policies. The administrator must go back to the global ADOM and assign the global policy package to that new local policy package.

In a FortiManager HA cluster configured with VRRP failover, the failover process is automatic and transparent to administrators. If the monitored interface on the primary device fails, the secondary device takes over without requiring manual intervention to maintain HA.

The exhibit shows the default value of the LAN address object as 172.16.5.0/255.255.255.0. It also shows Per-Device Mapping entries only for BR1-FGT-1 [root], HQ-NGFW-1 [root] , and Remote-Firewall [root]. There is no mapping shown for Remote-Firewall [VDOM1] .

The FortiManager 7.6 Administrator Study Guide gives the exact rule: “The devices in the ADOM that do not have a dynamic mapping for LAN have a default value.” It also states that dynamic mappings are configured per device in the Per-Device Mapping section.

Since Remote-Firewall [VDOM1] does not have its own mapping entry, it will use the object’s default value, which is 172.16.5.0/255.255.255.0.

The correct answer is D. The FortiManager 7.6 Administrator Study Guide states: “You can revert to a previous configuration revision” and “Reverts only the device database to the previous revision”. It also states “Does not revert policies and objects—you must import them” and “You must install reverted changes on FortiGate.”

This exactly means a revert operation changes the device-level database on FortiManager, not the policy layer database. The guide further clarifies: “Performing a revert operation followed by an installation only reverts device-level changes and does not revert policy packages.”

So C is incorrect because both layers are not reverted together. A and B are also incorrect because the documented and verified effect is specifically a modification of the device database, followed by install and, if needed, policy re-import for synchronization.

=========