NSE6_FMG_AD-7.6 Practice Questions

Based on the provided "Managed FortiGate devices" exhibit, the device named Local-FortiGate* is a member of the Training Security Fabric group and has an asterisk (*) appended to its name. In FortiManager, this asterisk acts as a status indicator signifying that the device's configuration is out-of-sync with the FortiManager's device-level database. To resolve this discrepancy and ensure that the Security Fabric topology, settings, and group synchronizations are accurate, the administrator must retrieve the configuration from the Local-FortiGate device.

Option B: The Install On column for Policy sequence #1 explicitly lists ISFW (root) and ISFW (Student), completely omitting the Trainer VDOM.

Option C: Selecting Installation Targets in the Install On column is a valid, standard FortiManager configuration that dynamically applies policies to the package's targets without causing errors.

Option D: The exhibit strictly displays a local ADOM policy package named Shared_Package; it does not provide any evidence of a global policy package being merged or applied.

Fortinet, Inc. FortiManager 7.6 Administration Guide. "Device Manager: Device Status and Synchronization." (Details the use of the asterisk * for out-of-sync device databases).

Fortinet, Inc. FortiManager 7.6 Administration Guide. "Policy & Objects: Policy Packages and Installation Targets."

Fortinet NSE 6 - FortiManager 7.x Official Courseware. "Managing Device Configurations and Security Fabric."

Workspace mode in FortiManager provides concurrency control and administrative locking to prevent simultaneous configuration changes that could corrupt the database or create conflicts. When an administrator locks an ADOM, FortiManager grants exclusive write access to that administrator, putting all other administrators into a read-only state for that specific ADOM. This ensures database integrity and prevents race conditions during major configuration changes. Until the holding administrator saves, commits, or unlocks the ADOM session, other administrators cannot make modifications. This mechanism explicitly explains why Administrator B is blocked from making changes while Administrator A holds the exclusive ADOM lock.

B: ADOM locking restricts write access to a single administrator for the entire ADOM, rather than allowing simultaneous editing by multiple administrators.

C: ADOM locking applies at the entire ADOM level in this mode, not at a per-policy granular level.

D: ADOM locking must be explicitly performed by administrators when entering read/write mode, rather than being unmanageable and automatic.

- Fortinet

FortiManager 7.2.0 Administration Guide

Section: "Workspace mode and ADOM locking"

pp. 185–190.

- Fortinet

FortiManager 7.4.0 Administration Guide

Section: "Concurrent administration and session locks"

pp. 192–197.

Based on the provided exhibits, "image_f652d5.jpg" shows that the FortiGate is running an older IPS Definitions database (Version 6.00741). Conversely, "image_f652ba.jpg" indicates the FortiManager is utilizing significantly newer Signature Meta Data (Version 29.00906). When configuring policies, FortiManager uses its own signature metadata to populate the available IPS signatures in its GUI. If an administrator selects a newly released IPS signature from the FortiManager's updated database and pushes this policy, the FortiGate will fail to recognize the configuration because the specific signature ID does not exist in its older, mismatched local IPS database.

A: FortiGate uses the update server-type specifically for downloading IPS definitions, whereas rating is strictly reserved for real-time query services like Web Filtering and DNS Filtering.

C: There is no requirement to enable IPv6 connections to resolve a database mismatch; the current IPv4-mapped IPv6 address is completely valid for management and update traffic.

D: In a closed network using FortiManager as a local FDS, fortiguard-anycast must remain disabled to ensure the FortiGate queries the local server rather than external public servers.

Fortinet, Inc. FortiManager 7.6 Administration Guide. "FortiGuard Management" (Section: Signature and Database Updates).

Fortinet, Inc. FortiOS 7.6 Administration Guide. "System FortiGuard" (Section: Overriding default FortiGuard servers / Update vs. Rating).

When reverting a configuration from the Configuration Revision History window in the Device Manager, FortiManager restores and installs only the device-level configuration to the target FortiGate. It does not install the ADOM-level policy package. This behavior is verified by the CLI output in the exhibit, which shows the device database is synchronized (dev-db: not modified; conf: in sync), but the policy package status has changed to unknown (pkg:[unknown]BR1-FGT-1). Since the policy package was skipped during the device-level revert, FortiManager can no longer determine its exact synchronization status.

A: The flags:0 parameter represents an internal FortiManager system state, not a user-configurable value used to prevent configuration overrides. B: The output clearly displays pkg:[unknown]BR1-FGT-1, confirming the policy package was not reinstalled. If it were, the status would show as installed. C: The FortiGate's firmware version is successfully detected and displayed as 7.0 MR6 (3401) in the CLI output, making a device retrieval unnecessary for this purpose.

Fortinet, Inc. FortiManager 7.2 Administration Guide. Section: Device Manager -> Configuration Revision History (Details device-level restorations vs. policy package installs).

Fortinet, Inc. FortiManager 7.2 CLI Reference. Diagnostics and Troubleshooting -> diagnose dvm device list (Explains the output parameters including conf, dev-db, and pkg states).

HQ-NGFW-1 has memory-based-failover enabled with a memory-failover-threshold of 70 and a memory-failover-monitor-period of 50. The system performance output shows HQ-NGFW-1's memory utilization is currently at 90%. Because this 90% utilization exceeds the 70% threshold and the administrator has observed it for 55 seconds (which satisfies the 50-second monitor period requirement), a memory-based failover is triggered. This forces HQ-NGFW-1 to relinquish its primary role, resulting in HQ-NGFW-2 being elected as the new primary device.

B. The HA failover is strictly triggered by the memory threshold being exceeded on the original primary, which supersedes standard priority-based HA election rules.

C. The memory-failover-flip-timeout parameter dictates how long a device must wait before it can participate in an election again; it does not make it the primary.

D. The override parameter is explicitly set to disable in the configuration, so it does not factor into the primary election process in this scenario.

Fortinet, Inc. FortiOS Administration Guide: High Availability (HA) -> HA memory-based failover. This section explicitly details how a device will fail over to a subordinate role if its memory utilization exceeds the configured threshold for the duration of the monitor period.

When a managed FortiGate device is relocated from one ADOM to another within FortiManager, only its device-level management settings (Device Manager profile) are transferred to the target ADOM. FortiManager does not automatically copy or create policy packages or policy objects in the new ADOM database. To populate and view the policy and object configurations associated with the FortiGate in the new ADOM, the administrator must run the Import Configuration wizard. This wizard imports the policy package, firewall rules, and associated objects directly from the FortiGate into the new ADOM database.

A: Shared objects cannot dynamically construct or import a device's specific policy package structure.

B: Resetting and re-adding the FortiGate causes unnecessary disruption when the policy import wizard is standard.

D: ADOM sync is not an existing FortiManager function for migrating policy packages between ADOMs.

- Fortinet FortiManager 7.2.0 Administration Guide

Section: "Moving a device to a new ADOM"

pp. 132-134.

- Fortinet FortiManager 7.4.0 Study Guide

Chapter: "ADOM Management"

Section: "Moving Devices Between ADOMs"

pp. 68-71.

When a CLI script is configured to run on the Remote FortiGate Directly (via CLI), FortiManager bypasses the local device database and executes the commands directly on the live FortiGate unit. Because the configuration is modified directly on the hardware, the FortiGate immediately auto-updates the FortiManager's device-level database to ensure synchronization. Furthermore, FortiManager automatically captures this configuration change by generating a new revision history entry, ensuring an accurate audit trail and backup of the newly applied device state.

Option A is incorrect because previewing CLI commands is only possible when running the script against the Device Database and subsequently using the Install Wizard to review the pending changes.

Option D is incorrect because executing directly on the device applies the configuration in real-time, completely bypassing the staging process and eliminating the need for the Install Wizard.

Fortinet, Inc. FortiManager 7.4.0 Administration Guide. Document ID: 09-740-880000-20231102. Section: Device Manager > Scripts > Executing a script, pp. 312-314.

Fortinet, Inc. NSE 6 FortiManager 7.4 Study Guide. Fortinet Training Institute. Chapter 3: Device Manager, pp. 118-120.

Enabling normal workspace mode (set workspace-mode normal) introduces ADOM locking to prevent concurrent administrators from making conflicting changes. Under this configuration, an administrator must lock an ADOM to make modifications. If an administrator closes a session ungracefully—such as closing the web browser without logging out or releasing the lock—FortiManager retains the lock until the administrator's idle session timer expires or a super administrator clears the session. Additionally, FortiManager permits a single administrator with proper administrative permissions to concurrently lock and manage more than one ADOM at the same time.

B. Workspace locks are applied strictly at the ADOM container level; administrators cannot independently or granularly lock individual policy blocks.

D. Approval workflows exist only in workflow workspace mode; normal workspace mode permits direct saving and committing of configuration changes without an approval requirement.

Fortinet Inc., FortiManager 7.6.0 Administration Guide, Section: "System Settings > Workspace mode", Document Identifier: 04-760-1045233.

Fortinet Inc., FortiManager 7.6 Study Guide for Fortinet Certified Professional (FCP), Chapter: "System Settings and ADOMs", Subsection: "Workspace Modes: Normal vs. Workflow".

Fortinet Inc., FortiManager 7.6.0 CLI Reference, Section: "config system global > workspace-mode", Document Identifier: 04-760-1045238.

When both FortiManager and FortiGate reside behind Network Address Translation (NAT) devices, communication and discovery rely on translated IP addresses. During the discovery process initiated from FortiManager, FortiManager targets and discovers the FortiGate using the FortiGate's public NATed IP address. However, because FortiManager is also behind a NAT gateway, it is unaware of its own external public NATed address by default. Consequently, during discovery, FortiManager pushes its internal non-NATed IP address to the FortiGate's central management configuration instead of its NATed IP address. Administrators must manually update the central management IP address on the FortiGate to ensure proper long-term FGFM management connection re-establishment across NAT gateways.

Option C: FortiGate requires the external NATed IP address of FortiManager configured under central management to successfully initiate connections.

Option D: FortiManager cannot initiate FGFM connections to a FortiGate behind NAT; re-establishment must be initiated by the FortiGate.

- Fortinet FortiManager 7.0.0 Administration Guide

Section: "Device Manager"

Subsection: "Discovery and NAT configurations".

- Fortinet FortiManager 7.2 Study Guide

Chapter: "FGFM Protocol and Device Discovery"

Page 95–102.

FortiManager automatically tracks device-level configuration changes by creating new entries in the Revision History table under specific operational triggers. First, whenever FortiManager successfully performs an installation operation that pushes device-level configuration changes to a managed FortiGate, a new revision entry is logged to represent the installed baseline. Second, when configuration modifications are performed directly on the FortiGate CLI or GUI, FortiManager detects the out-of-sync status and automatically retrieves or auto-updates its configuration from the managed device, creating a corresponding revision history entry. Both of these actions ensure complete auditability of deployed device configurations across FortiManager and managed FortiGate units.

Option B: Modifying the device-level database in FortiManager only alters the staging database and does not generate a revision entry until an install or retrieve occurs.

Option D: Assigning a provisioning template modifies FortiManager's database settings, but a revision history entry is created only when those template settings are installed.

- Fortinet

FortiManager 7.4.0 Administration Guide

"Creating revision histories" section.

- Fortinet Training Institute

FortiManager 7.2 Study Guide

"Device Manager - Revision History Triggers" chapter

pp. 82-85.