Fortinet FortiManager 7.6 Administrator - FCP_FMG_AD-7.6 Practice Questions

Explanation:

An ADOM revision is a snapshot of the entire ADOM's configuration database, including both the policy/object database and the device-level database. A new revision is automatically created when there is a change to this centralized database.

✅Option B is correct
because any manual edit to the device-level configuration (e.g., interfaces, routing settings) within FortiManager's Device Manager constitutes a change to the ADOM database, triggering a revision.

✅Option C is correct
because when FortiManager performs a retrieve operation (pulling configuration changes made directly on a managed FortiGate), it updates its own device-level database. This database change also triggers the creation of a new ADOM revision.

❌ Why the other options are wrong

Option A is incorrect.
Installing configuration to a device does not change the ADOM database itself; it pushes the existing database configuration to the device. Therefore, it does not trigger a revision. Installation history is tracked separately.

Option D is incorrect.
Assigning a provisioning template to a device is a metadata operation that links the template. It does not, by itself, alter the configuration entries in the device-level database. A revision would be created later when that template is installed and its configuration is written to the database.

Reference:
FortiManager Administration Guide - Managing ADOMs - Revision History. Revisions are created when the ADOM database is modified, either manually within FMG or via a retrieve from a device.

Explanation:

Workflow mode in FortiManager enforces a centralized approval process for all policy package installations. When enabled, administrators must submit their changes for review, and a designated approver must authorize them before they are pushed to managed FortiGate devices. This ensures that mistakes are caught during the approval stage, preventing repeated errors and maintaining strict change control. Fortinet documentation confirms: “Workflow mode allows administrators to submit changes for approval before installation, ensuring controlled and verified deployments.” (FortiManager 7.6 Administration Guide).

❌ Why the other options are wrong

A. Configure a TCL script to run locally
TCL scripts can automate tasks but do not prevent administrators from repeating mistakes. They are not a governance mechanism.

B. Restrict administrators from viewing revision history
Revision history is for auditing and rollback. Restricting access does not prevent mistakes; it only limits visibility.

C. Enable the change note requirement
Change notes improve documentation and accountability but do not enforce approval or prevent incorrect configurations from being installed.

📖 References
FortiManager 7.6 Administration Guide
– section on Workflow Mode: “Workflow mode enforces a structured approval process for policy changes before installation.”
Fortinet KB Article:
“Use workflow mode to prevent unauthorized or incorrect policy package installations by requiring approval.”

Explanation:

FortiManager is designed for centralized management and mass provisioning of FortiGate devices. The key feature is the use of templates (system templates, interface templates, provisioning templates, etc.) that allow administrators to apply consistent configurations across multiple devices at once. This eliminates repetitive manual configuration, ensures uniformity, and speeds up deployment in large environments. Fortinet documentation confirms: “FortiManager supports mass provisioning by using templates to configure common settings across multiple devices simultaneously.” (FortiManager 7.6 Administration Guide).

❌ Why the other options are wrong

A. It upgrades the OS of each FortiGate device
FortiManager can manage firmware upgrades, but this is not the primary mechanism for mass provisioning. Provisioning refers to configuration, not OS upgrades.

B. It provides local FortiGuard Distribution Server (FDS) services
FDS services are handled by FortiGuard or FortiAnalyzer, not FortiManager. This is unrelated to provisioning.

D. It sends email alerts when new devices connect
FortiManager can generate alerts, but sending emails is not a provisioning function. Alerts do not configure or deploy settings.

📖 References
FortiManager 7.6 Administration Guide – section on Provisioning Templates: “Templates allow administrators to configure the same settings on multiple devices simultaneously, supporting mass provisioning.”

Explanation:

When an ADOM is in backup mode, it is read-only for policy and object management. You cannot create or install policy packages in the normal way.
The only way to push configuration changes (such as policies) to a FortiGate device in backup mode is by using FortiManager scripts.

Scripts bypass the ADOM policy package workflow and apply changes directly to the device or its database. Fortinet documentation confirms: “In backup mode, ADOMs are read-only. Configuration changes must be applied using scripts.” (FortiManager 7.6 Admin Guide).

❌ Why the other options are wrong

A. Use the Install Wizard located on the device manager
The Install Wizard cannot be used in backup mode because policy packages are locked.

B. Enable workflow mode to allow policy creation and approval
Workflow mode enforces approval processes, but it does not override the read-only nature of backup mode.

C. Make sure the ADOM and FortiGate firmware versions match and use the ADOM policy package
Version matching is important, but in backup mode, policy packages cannot be installed regardless of version alignment.

📖 References
FortiManager 7.6 Administration Guide – section on ADOM backup mode: “ADOMs in backup mode are read-only. Scripts must be used to apply configuration changes.”

Explanation:

ADOM revisions are snapshots of the ADOM database, including all policy packages and objects.
If every change creates a revision and those revisions are retained for 90 days, the ADOM accumulates a large number of revisions.
During an ADOM upgrade (e.g., from 7.4 to 7.6), FortiManager must process and convert all revisions, which significantly slows down the upgrade.
Limiting the number of revisions before upgrading reduces the amount of data FortiManager must process, resulting in faster and smoother upgrades.
Fortinet documentation confirms: “Large numbers of revisions can slow down ADOM upgrades. Limiting revisions before upgrading improves performance.” (FortiManager 7.6 Administration Guide).

❌ Why the other options are wrong

A. Check and repair the global configuration database
Useful for corruption issues, but not related to ADOM upgrade speed.

B. Export firewall policies to Excel, delete, and reimport
This is unnecessary and risky. Policy packages are already handled by FortiManager during upgrades.

C. Find unused firmware templates and delete them
Firmware templates do not impact ADOM upgrade performance. The issue is revision history size, not templates.

📖 References
FortiManager 7.6 Administration Guide –
section on ADOM Revisions and Upgrade: “Excessive revisions can slow down ADOM upgrades. Limit revisions before upgrading.”

Fortinet KB Article:
“To improve ADOM upgrade performance, reduce or purge old revisions before upgrading.”

Explanation:

When configuring IPsec VPNs through FortiManager scripts, the phase2-interface must reference a valid phase1-interface. If the administrator forgets to close the phase1 block with the end command, the phase1 object is not created on the FortiGate. As a result, when the script attempts to configure phase2, FortiGate reports “object mismatch” because the required phase1 object does not exist. Adding the end command ensures the phase1-interface is properly defined and available before phase2 is configured. This is the most direct and correct fix for the error. Fortinet documentation confirms: “Phase2 configuration requires a valid phase1-interface. Ensure phase1 is completed and closed with ‘end’ before configuring phase2.” (FortiGate CLI Reference, FortiManager 7.6 Admin Guide).

Why other options are not correct:

B. Use IPsec templates to deploy provisioning templates:
Templates can simplify VPN deployment but do not resolve CLI syntax errors. The issue here is missing end, not template usage.

C. Add a second config vpn ipsec phase2-interface block without linking it to phase1:
Phase2 must always be linked to a valid phase1. Adding another block without linkage will still fail.

D. Run the script using the policy package or ADOM database method:
The execution method does not fix the object mismatch. The problem is within the script syntax itself, not how it is delivered.

References:
FortiGate CLI Reference Guide – IPsec VPN section:
“Phase2 must reference a valid phase1-interface. Ensure phase1 is properly defined and closed.”

Explanation:

The scenario describes a managed FortiGate that receives its FortiGuard updates (including IPS signatures) from FortiManager acting as a local FortiGuard Distribution Server (FDS). The FortiGate's configuration shows its update server is 192.168.1.120 (the FortiManager), not the public FortiGuard servers. For the FortiGate to recognize a new IPS signature pushed via policy, the IPS signature database on the FortiGate must be the same version (or newer) than the one referenced when the policy was configured on FortiManager. If FortiManager has a newer IPS database version than what is currently installed on the FortiGate, the FortiGate will not recognize signatures that were added in that newer database version, causing the policy to fail or be ineffective.

Option A is incorrect.
The rating option is for the Security Rating service, not for IPS signature validation. The server list is correctly configured for updates.

Option C is incorrect.
IPv6 is not required; the communication is using IPv4 (shown as ::ffff:10.0.13.120 which is an IPv4-mapped IPv6 address, and server 192.168.1.120).

Option D is incorrect.
The fortiguard-anycast option is used on a FortiGate to use Fortinet's anycast servers for updates. Here, the FortiGate is explicitly configured to use the local FortiManager (192.168.1.120), so anycast is not relevant.

Reference:
FortiManager Administration Guide - FortiGuard - Configuring Local FortiGuard Distribution. When FortiManager acts as an FDS, managed devices must have their FortiGuard update source pointed to it. Synchronization of signature database versions between FortiManager and the managed devices is critical for policy consistency.