Fortinet FortiManager 7.6 Administrator - FCP_FMG_AD-7.6 Practice Questions

Explanation:

FortiManager's VPN Manager is designed to simplify the deployment and management of complex IPsec VPN topologies, particularly hub-and-spoke networks.

Automation: When you define the hub and add the spoke devices, the VPN Manager automatically handles the creation and maintenance of the necessary Phase 1 (IKE) and Phase 2 (IPsec) settings on all participating devices. This includes:
- Creating the required IPsec tunnels.
- Generating the necessary crypto settings and pre-shared keys (if used).
- Creating the firewall addresses for tunnel subnets.

This significantly reduces the administrative effort and the chance of human error (e.g., mismatched keys, phase 2 selectors) that are common in manual configuration or scripting.

Incorrect Answers Details

A. VPN Manager supports only route-based VPNs, making configuration more secure:
This is incorrect. VPN Manager supports both route-based and policy-based VPNs. While route-based VPNs are generally preferred for modern, scalable networks, the management system's support for both is not a key advantage over manual configuration, and security is determined by the crypto settings, not the management tool.

C. VPN Manager does not require any IP addressing on tunnel interfaces:
This is incorrect. Route-based VPNs, which are the standard for hub-and-spoke in FortiManager, require IP addressing on the virtual tunnel interfaces (e.g., ipsec_tun_X). This is necessary for routing protocols or static routes to function correctly.

D. VPN Manager allows central SSL-VPN configuration only:
This is incorrect. VPN Manager is primarily designed for IPsec VPN topologies (Hub-and-Spoke, Full Mesh). Central SSL-VPN configuration is managed through a different part of the FortiManager policy interface.

References
Fortinet Document Library - FortiManager Administration Guide (v7.6):
Refer to the chapter on "VPN Manager" and the section detailing "Hub-and-Spoke VPN Topology." The documentation highlights the automated creation of tunnel interfaces, Phase 1, and Phase 2 settings as a core feature and benefit of the tool.

FCP - FortiManager 7.6 Administrator Course Materials:
The module on Central VPN Management contrasts the VPN Manager workflow with the traditional method, emphasizing that automation for the IPsec tunnel parameters is the primary reason to use the feature.

Explanation:
When a Security Fabric root FortiGate is added to a FortiManager ADOM, downstream devices (leaf nodes) are discovered but remain unauthorized. They appear in the root ADOM’s device list with an unauthorized status until explicitly authorized by the administrator.

Correct Option:

C. The downstream devices show as unauthorized in the root ADOM.
Correct. After adding only the root FortiGate to the Training ADOM, FortiManager discovers downstream devices through the Security Fabric connection. However, those devices are not automatically authorized and appear as Unauthorized in Device Manager.

Incorrect Option:

A. The downstream devices are automatically authorized.
Incorrect. FortiManager does not auto-authorize downstream Security Fabric devices. Each device must be manually authorized for management.

B. The downstream devices will appear in the Managed FortiGate section of the root ADOM.
Incorrect. The root ADOM (typically ADOM 0) is separate from the newly created Training ADOM. Downstream devices appear within the Training ADOM, not the root ADOM.

D. The downstream devices must be added using the Add Device wizard.
Incorrect. They are discovered automatically via the Security Fabric and do not need to be added manually with the wizard. However, they still require authorization.

Reference:
FortiManager 7.6 Administration Guide → Device Manager → Security Fabric Integration → Adding Security Fabric Root FortiGate and Downstream Device Authorization

Explanation:
When both FortiManager and FortiGate are behind NAT devices, discovery and communication require proper NAT address configuration. The FortiGate is discovered using its NATed IP address, and the FortiManager's NATed IP must be manually configured on the FortiGate because it is not set automatically during discovery.

Correct Option:

A. FortiGate is discovered by FortiManager through the FortiGate NATed IP address.
Correct. When a FortiGate is behind NAT, FortiManager discovers it using the public (NATed) IP address that the FortiGate uses to reach the internet. The FortiManager sees the connection coming from this translated address.

B. During discovery, the FortiManager NATed IP address is not set by default on FortiGate.
Correct. FortiManager does not automatically send its NATed IP address to the FortiGate during discovery. The administrator must manually configure the FortiManager's NATed IP address on the FortiGate under config system central-management to ensure proper return communication.

Incorrect Option:

C. FortiGate can announce itself to FortiManager only if the FortiManager non-NATed IP address is configured on FortiGate under central management.
Incorrect. The FortiGate needs the FortiManager's NATed (public) IP address, not its non-NATed (private) IP address. The private IP is unreachable across NAT.

D. If the FortiGate–FortiManager communication protocol FGFM tunnel is torn down, FortiManager will try to reestablish the FGFM tunnel.
Incorrect. While FortiManager does attempt to reconnect, this behavior is not specific to NAT scenarios. It occurs regardless of whether NAT is present and is not a unique expected result of both devices being behind NAT.

Reference:
FortiManager 7.6 Administration Guide → Central Management → NAT Scenarios → Discovering FortiGates Behind NAT and Configuring FortiManager NATed IP

Explanation:

A global policy package contains reusable policies and objects that can be inherited by local policy packages within any ADOM. When creating a new policy package in an ADOM that already has a global policy package assigned, FortiManager provides the administrator with an explicit option during creation to inherit from or assign that existing global package. This is a manual selection, not automatic. The inherited global policies appear read-only in the local package and provide a common baseline.

Option B is incorrect.
Assignment is not automatic. The administrator must choose to use the global package during the creation wizard or later in the package settings.

Option C is incorrect.
Policy packages are configuration containers; creating one does not trigger an automatic installation. Installation is a separate, manual or scheduled administrative action.

Option D is incorrect.
The global policy package is already assigned to ADOM1 (as stated in the question). The administrator does not need to reassign it from the global ADOM; they simply select it as a source when creating the new local package within ADOM1.

Reference:
FortiManager Administration Guide — Policy & Objects — Working with Global Policy Packages. The guide explains that a global policy package can be assigned to an ADOM, and then local packages within that ADOM can be configured to inherit from it, maintaining centralized control over common rules.

Explanation:

In FortiManager, device-level configurations like BGP routing are typically managed through Device Templates, not through the standard Policy Package. If a BGP template (or any device/feature template) is assigned to the FortiGate in the Device Manager, it controls that specific configuration section. When a policy package is installed, it does not overwrite template-managed settings. Therefore, if a BGP peer was configured directly in the device-level database but a BGP template is also assigned, the template's configuration takes precedence and the manually entered BGP settings in the device database are ignored during installation.

Option A is incorrect.
While a database issue is possible, it's not the most likely reason. The scenario specifically describes a configuration push that completed without errors, suggesting a structural conflict (like a template) rather than database corruption.

Option C is incorrect.
Selecting "Install device settings only" is for pushing device-level configuration (like interfaces, BGP) when you are not pushing policy packages. In this case, the admin reinstalled the policy package, which does not push template-controlled device settings. The correct action would be to install the assigned templates, not use the policy package install wizard.

Option D is incorrect.
A version mismatch between the FortiGate firmware and the ADOM's OS version would typically cause a pre-install validation error or failure, not a silent omission of specific configuration sections.

Reference:
FortiManager Administration Guide — Device & Console > Device Manager > Managing Device Configuration with Templates. The guide explains that when a feature template is assigned, it manages that specific configuration section, overriding any manual entries in the device-level database for that feature.

Explanation:

The command execute fmprofile export-profile is used to export system template profiles (such as interface templates, SNMP, or routing profiles) from a specific ADOM policy database.
The export process takes the profile data stored in the ADOM’s policy database and writes it to a file (in this case /tmp/Backup_File) on the FortiManager system.
This allows administrators to copy or migrate profiles between ADOMs or back them up for reuse.
Fortinet documentation confirms: “The export-profile command exports system template profiles from the ADOM policy database to a file.” (FortiManager 7.6 CLI Reference).

❌ Why the other options are wrong

A. FortiManager /tmp/Backup_File folder
/tmp/Backup_File is the destination file path, not the source. The source is the ADOM policy database.

C. ADOM device database
Device database stores per-device configs (interfaces, routing, etc.), not system template profiles. Profiles are ADOM-level objects.

D. FortiManager configuration backup file
A configuration backup file is created using execute backup, not export-profile. This command does not interact with full system backups.

📖 References
FortiManager 7.6 CLI Reference Guide – “execute fmprofile export-profile exports system template profiles from the ADOM policy database.”

Explanation:

✅ Why A is correct
When a FortiGate is behind a NAT device, FortiManager must know the public/NAT IP address and the correct management ports to reach it.
If FortiManager is still configured with the internal/private IP, push updates will fail.
Fortinet documentation confirms: “For devices behind NAT, configure the NATed IP and ports in FortiManager so it can reach the FortiGate.” (FortiManager 7.6 Admin Guide).

✅ Why C is correct
The NAT device itself must be configured with a virtual IP (VIP) mapping and the correct port forwarding rules to allow FortiManager traffic to reach the FortiGate.
Without proper VIP and port forwarding, FortiManager cannot establish communication with the FortiGate.
Fortinet KB states: “Ensure NAT device has VIP and port forwarding configured for FortiManager management traffic.”

❌ Why the other options are wrong

B. FortiGuard updates and web service enabled
This relates to FortiGate’s ability to reach FortiGuard servers, not FortiManager push updates. Irrelevant to NAT communication.

D. Bind to IP address option on FortiGuard service interface
This setting is for FortiGuard service binding, not for FortiManager management connectivity. It does not solve NAT push update issues.

📖 References
FortiManager 7.6 Administration Guide – section on Managing devices behind NAT.
Fortinet KB Article: “When managing FortiGate behind NAT, configure NAT IP/ports in FortiManager and ensure VIP/port forwarding on the NAT device.”