Fortinet FortiManager 7.6 Administrator - FCP_FMG_AD-7.6 Practice Questions

Explanatin:

In FortiManager, an ADOM revision is essentially a snapshot of the configuration state at a given point in time.
When you create a revision, FortiManager saves the entire ADOM’s policy packages, objects, and settings.
This allows administrators to roll back, audit, or compare configurations later.
Official Fortinet documentation confirms: “ADOM revisions are snapshots of the ADOM database, including all policy packages and objects.” (FortiManager 7.6 Admin Guide).

❌ Why the other options are wrong

A. Find unused, duplicate, and unnecessary firewall policies and objects
That’s the role of Policy Consistency Check and Object Usage tools, not ADOM revisions.

B. Show specific changes in a policy package when it is installed
That’s handled by the Install Preview / Install Wizard, which shows diffs before pushing to devices.

C. Compare previous snapshots of the Policy Package and ADOM-level objects with the device-level database
That’s the function of Policy Package Diff / Device Database comparison, not ADOM revisions.

📖 Reference
Fortinet FortiManager 7.6 Administration Guide – “ADOM revisions are snapshots of the ADOM database, including all policy packages and objects. They can be used to restore or compare configurations.”

Explanation:

The exhibit clearly shows two meta fields—ExternalSubnet and InternalSubnet—created under the “Firewall Address” category in an ADOM’s Meta Fields configuration. Meta fields are custom tags or attributes that administrators can define and then assign to specific objects or policies to enhance organization, filtering, and reporting. In this case, these fields can be attached to address objects (like IPv4 addresses, ranges, or subnets) to classify them by their network role, making policy management more intuitive and searchable.

Option B is incorrect
because meta fields are scoped to the ADOM in which they are created. They are not global objects and cannot be exported or shared directly between ADOMs. Each ADOM maintains its own independent set of meta fields.

Option C is incorrect
because meta fields are descriptive labels, not script variables. Variables used in FortiManager CLI scripts are defined separately as “Script Variables” or “Custom Attributes” within the Device Manager or policy package, not in the Meta Fields section.

Option D is incorrect
as it refers to the syntax used for referencing Custom Attributes (${attribute_name}) or CLI script variables in device configuration templates. Meta fields are not invoked using the $ character; they are used within the GUI for metadata tagging and filtering.

Reference:
FortiManager 7.6 Administration Guide > Policy & Objects > Meta Fields. The guide states, “Meta fields are custom fields that you can add to policy objects and policies. You can use meta fields to sort, group, and filter policies and objects in the policy list.” This aligns with the function shown in the exhibit: creating custom fields to annotate firewall address objects.

Explanation:

The import process shown is a Policy & Object import, which creates a new policy package in the specified ADOM (root) using the device’s configuration. The header explicitly states the target package as Remote-FortiGate_root, confirming a new package will be created. The subsequent SKIP and FAIL entries detail object-level import results within that package.

Option A is incorrect
because per-device mapping is fully supported and is precisely what caused the REMOTE_SUBNET failure; the system attempted to map the device’s interface (port6) but encountered a binding conflict.

Option C is incorrect
as the REMOTE_SUBNET object import FAILED; FortiManager does not force a change when interface mapping fails. The conflict must be resolved manually.

Option D is incorrect
because the report clearly states the firewall address REMOTE_SUBNET failed to import due to an interface binding error, so it will not be created in the ADOM database.

Reference:
FortiManager 7.6 Administration Guide > Device & Console > Installing Policies and Objects > Importing Policies and Objects from Devices. The import function creates a new policy package, and the import report indicates success or failure for each configuration object, with interface mapping being a common point of failure.

Explanation:

Workspace mode is the native FortiManager feature specifically designed to allow multiple administrators to work concurrently in the same ADOM without overwriting each other's changes. When enabled, each admin works in an isolated, private workspace where they can make and validate configuration changes. Changes are only committed to the public ADOM database when the admin explicitly submits their workspace for approval, preventing direct configuration conflicts.

Option A is incorrect.
While RADIUS authentication and role-based access control are important for defining permissions, they do not inherently prevent two authorized admins from editing the same policy or object at the same time, which can lead to conflicts and overwrites.

Option B is incorrect.
Workflow mode is used for change approval processes (requiring a second admin to review and install changes), not for preventing concurrent editing conflicts. Workspace mode is the primary mechanism for conflict prevention during the configuration phase.

Option C is incorrect.
The JSON API is an automation interface; providing API access does nothing to prevent manual configuration conflicts and could even increase the risk if not managed properly.

Reference:
FortiManager Administration Guide — Workspace Mode. The guide states workspace mode allows administrators to "make changes to the ADOM database without interfering with other administrators' work" and that changes are "isolated until they are submitted," making it the best solution for concurrent work.

Explanation:

Global policy packages are created and managed in the Global ADOM.
The header and footer policies in a global policy package are enforced across all assigned ADOMs.
These policies are read-only from the perspective of the customer ADOM. The customer administrator can see them but cannot modify them.
Only the service provider administrator (who has access to the Global ADOM) can edit or update the global header/footer policies.
Fortinet documentation states: “Global policy packages are managed in the Global ADOM. Administrators of assigned ADOMs cannot modify global header or footer policies.” (FortiManager 7.6 Admin Guide).

❌ Why the other options are wrong

A. Workspace mode on the global ADOM
Workspace mode allows collaborative editing and commit control, but the customer administrator does not have access to the Global ADOM.

B. Workflow mode on the global ADOM and My_ADOM
Workflow mode is for approval processes, but again, the customer administrator cannot access the Global ADOM.

C. Service provider administrator can unlock the global policy
There is no “unlock” mechanism to delegate editing of global header policies to customer administrators. Control remains strictly with the service provider.

📖 Reference
FortiManager 7.6 Administration Guide – “Global policy packages are defined in the Global ADOM. Only administrators with access to the Global ADOM can edit global header and footer policies. ADOM-level administrators cannot modify them.”

Explanation:

FortiManager supports per-VDOM management, but only if the FortiGate device itself is registered under the root ADOM.
When a FortiGate with multiple VDOMs is added to a non-root ADOM (like Site1 in this case), all of its VDOMs are bound to that ADOM. You cannot split them across multiple ADOMs.
To manage VDOMs separately across different ADOMs, the FortiGate must be added under the root ADOM, then each VDOM can be assigned to different ADOMs.
Fortinet documentation states: “To manage VDOMs in separate ADOMs, the FortiGate must be added to the root ADOM. If added to another ADOM, all VDOMs remain bound to that ADOM.” (FortiManager 7.6 Admin Guide).

❌ Why the other options are wrong

B. Full access in device layer of VDOM-root
Access rights have no bearing on ADOM assignment. The limitation is architectural, not permissions-based.

C. FortiManager must be in ADOM normal mode
Normal mode does allow per-VDOM management, but only if the device is added under root ADOM. The issue is not the mode but the ADOM assignment.

D. Delete and re-add using Add Device wizard
Re-adding the device alone won’t solve the problem unless it’s added under the root ADOM. The wizard doesn’t bypass the ADOM binding rule.

📖 Reference
FortiManager 7.6 Administration Guide – “When a FortiGate is added to a non-root ADOM, all VDOMs are bound to that ADOM. To manage VDOMs in separate ADOMs, the FortiGate must be added to the root ADOM.”

Explanation:

✅Why A is correct
When a script is executed on the Device Database, it modifies the configuration stored locally on FortiManager, not on the actual FortiGate.
This causes FortiManager to flag the device’s Config Status as “Modified”, indicating that the local config differs from the device’s actual running config.
This is a key operational signal that an install action is pending.

✅ Why D is correct
Since the script only updates the Device Database, the changes are not yet pushed to the FortiGate.
To apply the changes, the administrator must use the Install Wizard to deploy the updated config to the managed device.
This is standard FortiManager workflow: Device Database → Install Wizard → FortiGate.

❌ Why B is wrong
The script history only logs executions on the actual device, not on the Device Database. Running the script on the Device Database does not trigger remote execution, so no history entry is created for the FortiGate.

❌ Why C is wrong
ADOM revision history is only updated when you manually create a revision or install a policy package.
Running a script on the Device Database does not automatically create a revision.

📖 Reference
FortiManager 7.6 Admin Guide – “Scripts run on the Device Database modify the local configuration. These changes must be installed to the device using the Install Wizard.”