FCP-FMG-AD-7-6 Fortinet FCP - FortiManager 7.6 Administrator Practice Questions

To be merged, policies must control traffic flowing through the same network path, which means their source and destination interfaces must match.

The security inspection applied to the traffic must be identical. If one policy has AV and the other has AV and IPS, they cannot be merged.

The command execute ha failover is the standard procedure to gracefully force a failover in a FortiManager HA cluster. When run on the primary unit, it signals the secondary unit to take over the primary role, ensuring a smooth transition of services for planned maintenance.

The "Unknown" status specifically indicates that FortiManager cannot determine the synchronization state. FortiManager relies on retrieving a checksum of the FortiGate's configuration to compare it with its own database. If it cannot get this checksum—due to an incompatible firmware version, a problem with the FGFM management tunnel, or a device-side issue—it will report the status as "Unknown". An out-of-band change would typically result in a "Modified" status.

The "Read-Only" permission level is designed for this exact purpose. It grants the administrator the ability to view configurations, such as policy packages and object databases, but prevents them from creating, editing, or deleting any items. "None" would hide the module entirely, and "Read-Write" would grant full modification permissions.

When using dynamic objects (like those populated from a connector, SDN, or threat feed), FortiManager does not resolve the IP addresses at the time of installation. Instead, it pushes the policy to the FortiGate with a reference to the dynamic object name. The FortiGate itself is then responsible for locally resolving and updating the list of addresses associated with that dynamic object, ensuring the policy is always enforced against the most current data.

The Global ADOM is specifically designed for this purpose. Header and footer policies are enforced globally and cannot be modified within individual ADOMs, ensuring compliance. Local ADOM administrators can then add their own policies between the header and footer policies, fulfilling all requirements efficiently.

TCL scripts rely on correct syntax to reference variables like meta fields (e.g., using $(meta_field_name)). The script's failure on only some devices strongly suggests that either the script logic for handling the variable is flawed, or the 'VLAN_IP' meta field has not been assigned a value for those specific devices, causing the script to fail when it tries to reference a null or empty value.

Creating a separate ADOM for each business unit is the standard and most effective way to achieve management isolation for devices, policies, and objects.

The Global ADOM is specifically designed to create and manage objects and policies that can be shared and enforced across multiple regular ADOMs, which perfectly fits the requirement for a central security team to manage common security profiles.

This statement is True. In a standard active-passive FortiManager HA cluster, the primary unit handles all management tasks, including communication with FortiGate devices. The secondary (passive) unit maintains a synchronized copy of the configuration and database but remains idle with respect to device management until it is promoted to the primary role during a failover event.

The core issue is that the devices are out-of-sync with an incorrect local configuration. The most direct and scalable way to fix this is to force FortiManager's version of the configuration onto the devices. Using the "Install Wizard" for "Device Settings" does exactly this. It overwrites the unintended local changes made by the faulty script with the configuration stored in the FortiManager database, restoring service and bringing the devices back into a "synchronized" state.