FortiManager 7.6 is easier to understand when the exam domains are drawn as one centralized change pipeline. Administrators configure the FortiManager platform, divide responsibility with ADOMs, register FortiGate devices, standardize settings with templates, manage policy and objects, install changes, preserve revisions, extend services such as FortiGuard, and troubleshoot mismatches between manager intent and device reality.
The current live exam is branded NSE 6 – FortiManager 7.6 Administrator, even though the master-plan target uses FCP_FMG_AD-7.6. The weighted areas are Administration 15–25%, Device Manager 20–30%, Policy and Objects 25–35%, Advanced Configuration 10–20%, and Troubleshooting 20–30%.
FortiManager itself is the control plane
Management interfaces, administrators, backups, API access, FortiAnalyzer integration, and platform health sit beneath every managed-device workflow. If FortiManager is unhealthy or unreachable, centralized policy lifecycle stops even when individual FortiGate devices continue forwarding traffic.
This distinction is important during incidents: data-plane service may remain available while the management plane requires recovery.
ADOMs map organizational boundaries into the platform
ADOMs determine how devices, policies, versions, and administrators are grouped. Workspace and locking behavior then control how several administrators make changes within the same scope.
A good objective map shows ADOM version compatibility, device movement, upgrades, and administrator profiles as governance around the device and policy layers.
Device registration establishes management authority
FortiManager must discover or receive a device request, establish FGFM communication, authorize the device, place it in the correct ADOM, and import or associate relevant configuration before centralized changes are meaningful.
Device groups and HA clusters then add organizational and resiliency context above the individual FortiGate.
System templates standardize non-policy configuration
Templates can define repeatable system settings across devices or ADOMs. They should be drawn between device inventory and configuration deployment because they reduce per-device drift.
Copying templates between ADOMs can improve consistency, but version compatibility, variables, and target differences still need review.
Policy packages and objects define security intent
Policy packages, shared objects, dynamic objects, interface mappings, metadata, and feature visibility express the centralized firewall policy model. The package itself does not protect traffic until it is validated and installed to the correct target.
This is why policy workflow, installation targets, object hygiene, and policy status belong together on the map.
Import brings device reality into FortiManager
When a device is onboarded or has diverged, import workflows reconcile FortiGate configuration with FortiManager databases. Interface mapping and policy/object interpretation matter because the manager must represent the device accurately before it can control future change.
A failed import is therefore a database/reconciliation problem, not just an onboarding inconvenience.
Install pushes centralized intent back to devices
The install wizard validates the target and transmits the change to managed FortiGate devices. Reinstallation, per-policy targets, locks, and workflow permissions influence what can be deployed and when.
The map should keep install separate from editing: a policy can be valid in FortiManager’s database but not yet present on the device.
Revision history creates recoverability and auditability
Device configuration revisions, ADOM revisions, retrieval, automatic updates, and revert operations provide the evidence needed to compare state and recover from bad changes.
Revision control also improves troubleshooting because the administrator can ask what changed between the last known-good and current state rather than relying on memory.
Advanced services extend centralized operations
FortiManager HA protects the management plane; FortiGuard distribution/cache centralizes update delivery; the global database ADOM can share policies and objects; Security Fabric views add topology and security context.
These features belong above the basic device/policy path because they extend scale, resilience, and consistency rather than replacing the core workflow.
Troubleshooting walks the map from transport to database
Start with network/NAT reachability and FGFM, then registration, ADOM/device assignment, import state, policy validation, installation, revision mismatch, FortiManager resources, and database/filesystem health. The first broken layer should determine the next action.
The map should also include the API as an alternate administrative interface. API calls can retrieve or change the same management objects that GUI or CLI workflows expose. Authentication, method, path, permissions, response code, and target all matter. Automation therefore sits beside ordinary administration rather than outside the product’s control model.
Backups belong at both platform and configuration levels. A FortiManager system backup protects the manager configuration, while device and ADOM revisions preserve managed-state history. These recovery mechanisms solve different problems and should not be treated as interchangeable.
FortiAnalyzer integration should be drawn adjacent to the management plane because FortiManager can manage or integrate with analysis capabilities. The key conceptual boundary is that configuration management and log analytics have different primary purposes even when they are connected through the Fortinet ecosystem.
Version compatibility should be shown across ADOMs, devices, and policy databases. FortiManager needs to understand the FortiOS version of managed devices so policy/object behavior maps correctly. An ADOM upgrade is therefore not merely cosmetic; it changes the management schema and compatibility assumptions for that administrative scope.
Device replacement should sit on the recovery path. When a managed FortiGate is replaced, FortiManager can help re-establish the centralized configuration and policy state, but the administrator must still verify identity, connectivity, registration, target mapping, and actual device behavior after replacement.
Install failures should be split into validation and transport categories. A package may fail before transmission because objects or interfaces cannot be resolved, or it may fail during communication with the target. This distinction determines whether the next evidence belongs in the policy database or FGFM/network path.
High CPU, memory, or disk usage belongs beneath every centralized workflow because platform resource pressure can create symptoms far above the system layer. Slow GUI operations, delayed jobs, failed imports, or database problems may have a common resource cause. The map should therefore keep FortiManager health visible.
Workspace sessions should be connected to policy locking and administrator accountability. The manager needs to know who changed which object, who holds a lock, and whether a session ended cleanly. Collaboration features are part of operational correctness, not just convenience.
Metadata variables belong between reusable policy and target-specific deployment. They let one policy model adapt to different sites or devices without hardcoding every value. This improves scale, but a missing or incorrect variable can create a valid-looking policy package that fails or behaves incorrectly on install.
Security Fabric views should be placed on the visibility side of advanced configuration. They provide topology and rating context that can help administrators understand the environment around managed FortiGate devices. They supplement policy and device state rather than replacing direct configuration validation.
A strong FortiManager map also includes direction of truth. Device state can be imported into FortiManager, while centralized packages and templates are installed outward. Confusion about direction is a common source of unintended overwrite or drift during onboarding and troubleshooting.
For practice, use the map on one failure: a policy appears correct in FortiManager but traffic still follows the old rule. Ask whether the package was installed, target was correct, install succeeded, device database matches, and the FortiGate is actually using that policy. Each question corresponds to a map layer.
Device groups should be drawn as an organizational convenience above individual devices. They can help target scripts or administration, but they do not replace ADOM boundaries or policy-package target logic. Grouping and administrative isolation solve different problems.
HA cluster management belongs on the Device Manager path because FortiManager must understand cluster identity and member state when registering and managing FortiGate HA pairs. The centralized view should represent the service correctly even though multiple physical members exist.
Global policy should be shown flowing downward into ADOM-level packages. Shared corporate requirements can be applied broadly while local packages preserve site-specific rules. The map should make this inheritance visible so administrators know where to edit a rule and where a conflicting requirement originates.
FortiGuard package management should be connected to license and contract state. A device can be reachable yet unable to receive expected content because entitlement or server-override configuration is wrong. That is different from a transport failure.
Keep a revision checkpoint after every major branch in the map. Registration/import creates a baseline, policy installation changes target state, and rollback should return to a known revision. Version evidence makes complex centralized management safer.
The complete objective map should support one question: where is the source of truth for this setting right now? FortiGate local state, FortiManager device database, ADOM database, global database, template, script or policy package can each own part of the final device configuration.
The map should also show backup and restore at the FortiManager platform layer. A healthy policy database is not enough if the manager itself cannot be recovered after system failure. Platform backups protect administrative continuity, while device/ADOM revisions protect configuration history. These controls solve different recovery problems.
Administrator session monitoring belongs beside workspace and locking because abandoned or conflicting sessions can interfere with collaborative change. Knowing who holds a lock and which session created a pending workflow helps administrators resolve process problems without forcing unnecessary database changes.
One useful review exercise is to label every objective as platform, ADOM/governance, device, policy, deployment, advanced service or troubleshooting. If a feature seems to belong nowhere, revisit its purpose. The classification reduces cognitive load on a broad FortiManager blueprint.
Keep the source-of-truth path explicit during every change.
For final review, draw one policy change from administrator → ADOM/workspace → package/object → target → install → FortiGate → revision verification. That single path connects nearly every FortiManager domain in the current Fortinet certification role.