FCP FortiManager 7.4 common mistakes
FCP FortiManager 7.4 · Understand the traps and how to avoid them.
Treating ADOM mode as a cosmetic setting and answering questions as if all ADOMs behave identically, instead of distinguishing normal ADOMs from backup-mode ADOMs when asked where policies can be edited or how configuration is pushed.
Candidates memorise the ADOM concept from the GUI tour but never internalise that backup-mode ADOMs are read-only containers for device configuration backup, while normal ADOMs hold policy packages and objects. Questions that hinge on 'which ADOM type' then get answered from intuition rather than from the operational model.
What to do instead
Build a two-column comparison for normal versus backup ADOMs covering policy editing, object creation, install capability, and typical use (managed devices versus configuration archival). Before answering any ADOM question, ask which ADOM type is implied, then apply the comparison.
Assuming an administrator account created in one ADOM automatically has visibility of devices and policies in another ADOM, and selecting 'all ADOMs' as the answer whenever cross-ADOM access is mentioned.
The default admin profile grants broad rights, so lab practice rarely exposes the restriction. In production, per-ADOM admin accounts and restricted profiles are common, and the exam tests whether the candidate knows that ADOM assignment on the admin account governs visibility independently of the profile's permission bits.
What to do instead
Study the interaction between admin profile permissions and ADOM assignment as two separate controls: the profile says what actions are allowed, the ADOM assignment says where. Practise creating an admin limited to one ADOM and confirm the device list and policy packages outside it are invisible.
Answering HA questions by describing FortiGate cluster behaviour instead of FortiManager HA behaviour, for example claiming the backup unit continuously syncs and can take over without any manual step.
Most candidates arrive with FortiGate HA habits and transfer terms like primary/secondary and session pickup to FortiManager, where the model is different: one primary, peers in a degraded or standby state, and configuration synchronisation that is not continuous in the same sense.
What to do instead
Write out the FortiManager HA roles, what each peer does while healthy, what happens to the GUI on non-primary units, and the conditions that trigger a failover. Explicitly list three FortiGate HA concepts that do not carry over, and review them before the exam.
Confusing the management of a device with the management of its configuration: answering that adding a device to FortiManager automatically imports and manages its policy, or that deleting the device object removes the configuration from the FortiGate.
The add-device workflow and the import-policy workflow are separate operations with separate consequences, and the GUI makes both look like a single onboarding step. Candidates who only ever onboarded devices with a wizard assume the wizard covers both.
What to do instead
Map the onboarding sequence explicitly: add device (reachability and credentials), then import policy or assign a policy package, then install. For each step note what changes on FortiManager and what changes on the FortiGate, including the effect of removing a device from the device manager.
Assuming a device shows as connected because credentials are correct, ignoring that the FortiManager needs the FortiGate to initiate the tunnel or that a changed administrative port, disabled fgfm, or a renamed admin account breaks the relationship.
Troubleshooting questions describe a device that is reachable by ping and HTTPS yet shows as disconnected. Candidates who equate reachability with management connectivity pick 'check the password' and miss the management-tunnel prerequisites.
What to do instead
Memorise the prerequisites for the FortiManager-FortiGate management tunnel: the FortiGate must be configured to point at FortiManager, the fgfm service must be enabled on the interface FortiManager reaches, and the administrative access settings must permit it. Build a checklist ordered from network reachability to tunnel state to authorisation.
Answering revision-history questions as if revisions are created on every install, or as if restoring a revision also pushes it to the managed devices.
Revisions are created when configuration changes are saved in the ADOM, and installing to a device is a separate action. Candidates conflate 'saved in FortiManager' with 'deployed to the FortiGate', which inverts the answer on questions about rollback and drift.
What to do instead
Separate the two timelines: ADOM revision history (FortiManager-side configuration snapshots) and device configuration state (what the FortiGate currently runs). Practise comparing a device's configuration status against the policy package, then restoring a revision and noting that an install is still required to deploy it.
Treating policy packages and installation targets as one-to-one, and answering that a package can only be installed to the single device it was created for.
Candidates who practised with one device never exercise the many-to-many relationship. In the exam, questions about installing one package to several devices, or several packages to one device, are answered from that single-device mental model.
What to do instead
Draw the relationship explicitly: a policy package can have multiple installation targets, and a device can appear in the target list of more than one package, with the last install winning. Note the implications for policy consistency and for which package a device's current configuration came from.
Deleting an object that is still referenced by a policy and expecting the policy to be silently updated, or expecting the delete to be blocked in every case.
Object dependency handling is nuanced: FortiManager tracks references and behaves differently depending on where the object is used and whether the change is made in the policy package or on a managed device. Candidates generalise from one experience and pick an absolute answer.
What to do instead
Study reference checking for address, service, and other objects separately from per-device object overrides. Learn what happens to a policy that references a deleted object, and how the GUI signals dependencies before deletion. Test the behaviour in a lab with a policy referencing one object, then delete it.
Confusing policy package scope with global scope: assuming a global object or global policy is automatically inherited by every ADOM and every policy package without an explicit assignment.
Global objects and global policy packages are a common source of exam questions because the inheritance is conditional. Candidates who only used per-ADOM objects assume global means 'everywhere by default' and miss the assignment step.
What to do instead
Document the global-to-ADOM flow: which object types can be global, how a global object is made available to an ADOM, and how global policy packages relate to per-ADOM policy packages. Note what happens when a global object is changed after it has been used in an ADOM.
Diagnosing provisioning or installation failures by reading only the FortiManager task list status, without knowing where the per-device install log, the install preview, and the FortiGate-side event log each fit.
The task monitor shows success or failure at a high level, while the reason usually lives in the install log or in the device's own logs. Candidates who stop at the task status choose 'reinstall the policy' as the fix instead of identifying the failing object or the connectivity problem.
What to do instead
Learn the diagnostic chain in order: install preview to see what would change, task monitor for the job outcome, the per-device install log for the specific error, then the FortiGate logs for the device-side view. Practise deliberately causing an install failure and following that chain to the root cause.