FortiManager 7.6 should be studied in the order a centralized administrator actually works. Begin with platform setup and ADOMs, then device registration and FGFM, templates/scripts, policy packages and objects, import/install/revisions, advanced HA/FortiGuard/global policies, and finally mixed troubleshooting. The current exam’s heaviest areas are Policy and Objects plus Device Manager and Troubleshooting, so hands-on workflow matters more than memorizing isolated screens.
The master-plan code FCP_FMG_AD-7.6 refers to the same FortiManager 7.6 skill set that Fortinet now publishes as NSE 6 – FortiManager 7.6 Administrator. Build your notes around the current 7.6.1/7.6 product generation.
Phase one: establish FortiManager platform fundamentals
Review interfaces, administrator access, backups, system health, setup wizard, topology, FortiAnalyzer integration, and API concepts. Know what must be working before any FortiGate can be managed.
Create a baseline checklist for reachability, time/DNS, credentials, backup, and resource health so later onboarding failures can be compared with a known-good manager.
Phase two: master ADOM design and workspace behavior
Study ADOM operation/device modes, supported versions, administrator profiles, external authentication, workspace mode, locking, upgrades, device movement, and backup/restore.
Use a simple multi-team or MSSP scenario to understand why ADOM boundaries exist and what changes when administrators edit concurrently.
Phase three: learn device registration end to end
Practice discovery, add-device wizard, device-initiated requests, FGFM communication, groups, HA clusters, model devices/blueprints, import reports, and discovery troubleshooting.
Write the registration states in order. When a device is missing or unauthorized, the state sequence helps locate the fault before you touch policy.
Phase four: use templates and scripts for repeatable settings
Create or review system templates, copy templates between ADOMs, and run a small CLI script against a test target. Understand scheduling, errors, and where output appears.
Keep scripts narrow and predictable. Broad scripts should be tested on limited targets before they become organization-wide changes.
Phase five: spend serious time on policy and objects
Build policy packages, shared/dynamic objects, interface mappings, metadata, install targets, feature visibility, and object cleanup. Use policy checks and status to validate the package before installation.
This phase deserves the largest block because Policy and Objects can represent 25–35% of the exam.
Phase six: practice import and installation as separate workflows
Import a managed device’s configuration, inspect mapping and results, then make a controlled change and install it back. Compare the device database, ADOM database, and actual FortiGate state.
Learn the evidence for failed import, copy failure, validation failure, and failed installation. Similar symptoms can require different fixes.
Phase seven: learn revision history and rollback
Retrieve configuration, inspect automatic updates, compare revisions, revert safely, and understand ADOM revisions versus device revisions. Create one intentionally bad test change and recover it using the supported revision workflow.
Rollback practice makes version control operational rather than theoretical.
Phase eight: add HA, FortiGuard and global policy
Review FortiManager HA synchronization/failover, FortiGuard distribution/cache, packages and licensing, firmware cache, server override, global database ADOM, global policy packages, and Security Fabric views.
Keep these services tied to business reasons such as management availability, bandwidth efficiency, global policy consistency, or centralized update control.
Phase nine: troubleshoot using the management lifecycle
Create or study failures involving NAT, FGFM keepalives, registration, import, installation, database mismatch, replacement FortiGate, high CPU/memory/disk, filesystem/database integrity, and debug commands.
Always classify the layer first: transport, protocol, authorization, ADOM/database, policy validation, install, or system resource.
Finish with one complete managed-device change
Register a test FortiGate, place it correctly, apply template settings, import policy, edit a package, validate/install, compare revision state, and roll back. Then explain the same workflow from memory.
Keep one small FortiManager/FortiGate topology through the whole plan. Reusing the same devices makes it easier to see how ADOM membership, templates, policy packages, scripts, revisions, and FortiGuard settings interact. A new lab for every objective hides dependencies that become obvious when one environment evolves over time.
During platform study, include a backup-and-restore tabletop. Record what a FortiManager backup protects, where it is stored, how you would restore the manager, and what needs validation afterward. Centralized management becomes a business-critical service once many FortiGate devices depend on it.
During ADOM study, create two administrative scopes with different versions or business roles. Assign administrators with different profiles and observe which objects they can access. This makes ADOM, RBAC, workspace, and version concepts tangible in one exercise.
During registration study, deliberately break one prerequisite at a time: routing, NAT assumption, authorization, version compatibility, or management protocol state. Write the evidence that changes. The goal is to recognize registration failure patterns rather than memorizing a troubleshooting checklist mechanically.
During template study, compare a system template with a policy package. System templates standardize device/system settings; policy packages define firewall/security policies and objects. Mixing the two concepts leads to confusion about where a change should be made and how it reaches the device.
During scripting study, start with read-only or harmless commands. Capture output, target scope, and execution status. Then examine a failed script caused by syntax or unsupported target state. Script troubleshooting is safest when the task is narrow enough that failure has limited impact.
During policy study, create one reusable object and one target-specific dynamic or mapped value. Follow both into the install preview. This demonstrates why interface mapping and metadata variables matter in multi-device deployments.
During import practice, compare what FortiManager already knows with what exists on the FortiGate. Identify conflicts before accepting changes. Import should be treated as a reconciliation event with consequences for the management database.
During installation practice, inspect preview and validation rather than clicking through. Note which devices and policies are targeted and whether FortiManager proposes unexpected changes. A safe administrator understands the diff before applying it.
During revision practice, compare two configurations and describe the business change that caused the difference. Then revert a safe test change and confirm both manager and device state. This trains the habit of evidence-based rollback.
During advanced study, include one FortiManager HA or FortiGuard distribution design on paper if a multi-node lab is unavailable. Explain the failover or content-delivery path and which dependencies still remain external.
In the final week, troubleshoot from symptoms rather than objectives. “Device not registering,” “policy install fails,” “ADOM locked,” “FortiGuard package unavailable,” and “CPU high” should each lead to a different starting point. Symptom-first practice is closer to real FortiManager work.
Before scheduling, review Fortinet’s current branding and product versions. The live exam is NSE 6 – FortiManager 7.6 Administrator, based on FortiManager 7.6.1 and FortiOS 7.6. Old NSE 5 notes can still explain concepts but should not define final scope.
Add one API study session after platform fundamentals. Perform or inspect a harmless GET request and understand authentication, method, path, response code and returned object. This is enough to make API objectives concrete without turning preparation into a programming course.
Add one multi-administrator exercise during ADOM/workspace study. Let two test administrators attempt overlapping changes and observe locking or workflow behavior. Collaboration concepts are easier to remember after seeing why concurrent edits need control.
Add one FortiGate HA registration scenario. Compare managing one standalone firewall with an HA cluster and document which identity FortiManager manages, what state is synchronized and how a member replacement would be approached.
Add one object-hygiene session during policy study. Find duplicate or unused objects in a test database, review dependencies and clean them safely. This improves policy clarity and reinforces the exam’s object-management objectives.
Add one global database scenario if a full lab is unavailable. Define a corporate-wide policy/object and one ADOM-specific requirement, then decide which belongs in the global package and which remains local. This makes inheritance and scope explicit.
For final readiness, explain a failed policy install without using the GUI: transport/FGFM healthy, target correct, package valid, interface mappings present, object dependencies resolved, database consistent and device revision verified. That verbal checklist demonstrates end-to-end understanding.
Add one database-integrity review before final troubleshooting. Understand the difference between the device database, ADOM database and actual FortiGate configuration, then practice comparing them after an import or install. Many difficult FortiManager issues are really state-consistency problems.
Add one NAT deployment scenario: FortiManager behind NAT, FortiGate behind NAT, or both. Trace what connectivity and registration assumptions change and which troubleshooting evidence still proves the FGFM path.
Keep one final page of evidence sources: registration status, FGFM/keepalive state, revision history, install logs, script results, policy-package status, database comparison, resource utilization and debug output. Final-week review should connect symptoms to evidence rather than to menu locations.
Use Fortinet’s current sample questions only after your workflow model is stable. They can confirm question style and scope, but Fortinet explicitly notes that sample questions do not represent all exam content and are not a readiness guarantee.
Add one change-review exercise before the final week. Propose a policy update that affects several FortiGate devices, then list ADOM scope, locks, object dependencies, install targets, validation, revision checkpoint, rollback, and post-install verification. This forces the whole FortiManager workflow into one operational sequence.
Use your last practice session to explain which evidence belongs to FortiManager and which belongs to the managed FortiGate. Centralized management is strongest when the administrator can distinguish manager database state from actual forwarding-device state.
Finish by comparing one known-good revision with the active device state.
Keep revision evidence handy.
Within the current Fortinet certification program, that end-to-end fluency is more valuable than memorizing hundreds of menu locations because it mirrors centralized administration work.