Nse5 Fortimanager Operations practice questions

The device must be running the latest firmware.

Why it fails: Firmware version does not prevent config push.

All policies must be deleted.

Why it fails: Policies remain during config installs.

The device must be in 'backup' mode.

Why it fails: FMG works in 'normal' managed mode.

Auto-Link

Why it fails: Auto-Link is used for interface mapping, not script execution.

ADOM Policies

Why it fails: ADOM Policies are for central policy management, not provisioning.

Install On Install

Why it fails: This is not a standard feature name.

Manually re-import the config

Why it fails: Manual imports cause configuration drift.

Disable policy management

Why it fails: Disabling management breaks synchronization.

Delete local policy and recreate

Why it fails: This is inefficient and loses data.

Delete the original policy.

Why it fails: Workflow mode installs a new policy alongside the existing one, then requires approval and installation; deleting the original policy is not a required step. It is tempting because replacing a policy implies removing the old one, but workflow mode preserves the original until the new policy is approved and installed.

Reboot the FortiGate.

Why it fails: Rebooting the FortiGate is never part of the workflow-mode policy installation process; the steps are creating the policy, requesting approval, then installing it. It is tempting because some configuration changes need a restart, but policy installation pushes configuration without rebooting the managed device.

set fortimanager-ip

Why it fails: This is not the correct syntax.

set remote-log-server

Why it fails: This is for logging, not management.

set manager-address

Why it fails: This is not the correct command.

SSH.

Why it fails: SSH carries CLI sessions and FortiManager can open an SSH console, but device management traffic uses FortiGate-FortiManager (FGFM) over TCP 541, which handles provisioning and central management. SSH is tempting because it is the standard protocol for manual CLI administration of a FortiGate.

SNMP.

Why it fails: SNMP only carries monitoring and trap data such as interface statistics and alerts; it cannot push configuration or manage a FortiGate. FortiManager instead uses FGFM over TCP 541. SNMP is tempting because FortiManager can poll managed devices for performance monitoring, but that is not device management.

HTTP.

Why it fails: HTTP serves the administrative GUI and web portals, not the management tunnel FortiManager builds to FortiGates, which uses FGFM over TCP 541. HTTP is tempting because administrators reach FortiManager's interface through a browser, but that is GUI access, not device communication.

Hardware interface settings.

Why it fails: Hardware interface settings belong to the device's system configuration, not to a policy package, which contains firewall policies, objects and security profiles. Interface settings are configured per-device and would be the right answer if the question asked about device-level configuration.

Firmware images.

Why it fails: Firmware images are managed under system settings and image management, not within a policy package, which holds firewall policies, address objects and security profiles. Firmware handling would be the correct answer only if the question concerned system maintenance or upgrade management.

Delete old policies manually.

Why it fails: Policy installation pushes the package to managed FortiGates; FortiManager reconciles and overwrites policy differences automatically, so manual deletion of old policies is not a workflow step. It is tempting because removing obsolete rules is good hygiene, but that is administrative housekeeping, not part of the install process.

Factory reset the device.

Why it fails: The install workflow validates, pushes and verifies the policy package; a factory reset erases the device configuration and is unrelated. It is tempting because resets are used when provisioning a replacement FortiGate, but during policy installation the existing configuration is preserved and updated, not wiped.

Per-device policy package management.

Why it fails: This is done in the ADOM.

Automated firmware deployment.

Why it fails: This is in the firmware manager.

Device Objects

Why it fails: Device objects represent the hardware, not the configuration settings.

CLI Templates

Why it fails: CLI templates are static scripts, not dynamic object types.

Policy Objects

Why it fails: Policy objects are for firewall rules, not device-wide provisioning.

Firmware Template

Why it fails: Firmware templates manage software versions.

ADOM

Why it fails: An ADOM groups devices, policy packages and objects for administrative partitioning, but devices sharing one policy package are grouped by a device group inside that ADOM. ADOM is tempting because it is the top-level container, yet it does not itself bind devices to a shared package.

Device Group

Why it fails: A device group is a provisioning construct for installing settings and scripts to many FortiGates at once, not the object that binds devices to a shared policy package. It is tempting because grouping devices sounds equivalent, but policy-package assignment happens per device within an ADOM.

Policy & Objects > Import Policy

Why it fails: Import Policy pulls policy objects from a device into FortiManager's database; it does not retrieve the device's full configuration file. It is tempting because both operations involve device-to-manager data transfer, but backup specifically requires the Revisions or right-click Backup workflow.

Scripts > Create > Run on Device

Why it fails: Running a script on a device executes CLI commands; it does not capture the configuration file as a retrievable backup revision. Scripts are the right tool for pushing bulk configuration changes, which is why the menu path looks plausible for backup tasks.

System Settings > Network > Backup

Why it fails: System Settings > Network configures FortiManager's own interfaces and routing, not managed device backups. It is tempting because 'Backup' appears in system menus, but device configuration backups live under Device Manager, where revisions and the Backup action are exposed.

The Revision History view in the Device Manager pane for each FortiGate.

Why it fails: Revision History records and lets you compare policy package revisions that FortiManager itself generated. It does not reveal out-of-band changes made directly on the FortiGate CLI or GUI after the install, so it cannot explain why the live device configuration diverged from the FortiManager database.

The Install Preview option in the Install Wizard for the affected policy package.

Why it fails: Install Preview shows what FortiManager intends to push during an upcoming install, not what already exists on the FortiGate. It is a pre-install planning tool and provides no visibility into configuration drift that occurred after a previous successful installation, so it cannot identify the changes described.

The FortiManager event log filtered by the Configuration Changed event type.

Why it fails: FortiManager event logs record administrative actions and system events on FortiManager itself, such as logins and install operations. They do not capture configuration edits performed locally on a managed FortiGate, so filtering for Configuration Changed will not reveal the device-side drift the administrator is investigating.

Retrieve the FortiGate configuration to synchronize the object database.

Why it fails: Retrieving the FortiGate configuration will update FortiManager's database with the device's current objects, but it will not automatically create missing objects required by the policy package. If the policy package references an object that does not exist on the device, retrieval alone will not resolve the installation failure. The administrator must ensure that the required objects are either created on the device or installed from FortiManager. Retrieval is a step, but not the solution.

Manually create the missing object on the FortiGate via CLI or GUI.

Why it fails: Manually creating the missing object on the FortiGate might allow the installation to proceed, but it is not the recommended approach in a centrally managed environment. It introduces configuration drift and bypasses FortiManager's object management. The correct method is to ensure the object exists in FortiManager and is included in the installation. Manual creation on the device is a workaround but not a best practice, and it may lead to inconsistencies.

Remove the missing object from the policy package and reinstall.

Why it fails: Removing the missing object from the policy package would alter the intended security policy and is not a valid solution. The object is likely required for the policy to function correctly. Instead, the administrator should ensure the object is installed. Removing it could create security gaps or break connectivity. The proper resolution is to install the missing object, not to delete it from the policy.

Provisioning templates.

Why it fails: Provisioning templates push configuration to managed devices, not normalised address objects across ADOMs; global objects provide that shared naming. It is tempting because templates enforce consistency, but they target device settings rather than cross-ADOM object definitions.

Local ADOM objects.

Why it fails: Local ADOM objects exist only within one ADOM, so they cannot enforce naming across multiple ADOMs; global objects are visible to all. It is tempting because local objects are simple to create, but their scope prevents the cross-ADOM consistency required.

CLI templates.

Why it fails: CLI templates deliver device-level command snippets, not shared address object definitions; global objects supply cross-ADOM naming consistency. It is tempting because templates standardise configuration, but they operate on managed firewalls rather than FortiManager's object database.

Upgrade the firmware.

Why it fails: Firmware version does not govern policy-package association; the package must be assigned to the device or its ADOM, then installed. It is tempting because firmware mismatches do block policy installation, so upgrading would be correct when the imported FortiGate runs a version unsupported by FortiManager.

Re-install the device settings.

Why it fails: Re-installing device settings pushes configuration to a managed FortiGate; it does not associate an imported device with an existing policy package. The required step is assigning the device to the policy package, which triggers installation. Re-install suits refreshing settings on a device already bound to a package.

Run a script to update the policy database.

Why it fails: Scripts execute CLI or Tcl commands on managed devices; they cannot bind an imported FortiGate to an existing policy package. Synchronisation happens when the device is assigned to the package and installed. Scripting suits bulk configuration changes across many devices, not package association.

Install Wizard

Why it fails: The Install Wizard pushes policy packages to managed devices and reports installation results; it does not perform a syntax or validation check beforehand. It is the correct tool when you already trust the package and simply need to deploy it to selected FortiGates.

Revision History

Why it fails: Revision History records and compares past configuration versions, letting you roll back or diff changes; it does not parse policies for syntax errors before installation. It is the right feature when auditing what changed or reverting a bad deployment.

Device Manager

Why it fails: Device Manager inventories and configures individual managed FortiGates; it does not validate a policy package's syntax. Policy Check, within Policy & Objects, performs that pre-install validation. Device Manager is tempting because it is where devices and their objects are administered, but installation errors surface only at push time there.

Object Usage.

Why it fails: Object Usage lists where objects are referenced across policies and ADOMs; it never compares FortiManager's database against a FortiGate's running configuration. It tempts for impact analysis before deleting objects, but the installation diff appears in the Install Wizard's preview pane instead.

FortiView.

Why it fails: FortiView presents traffic, threat and session analytics from logs; it holds no configuration comparison data. It tempts because it is a go-to troubleshooting console, but the policy-installation diff is shown in the Install Wizard preview, not in log-driven dashboards.

Device Manager > Revision History.

Why it fails: Revision History stores FortiManager database revisions for rollback and comparison between saved versions, not against a FortiGate's live running configuration. It tempts because it does show configuration diffs, but those are historical FortiManager snapshots, not the device-versus-manager installation diff.

System Settings > Task Monitor.

Why it fails: Task Monitor shows installation task status, progress and any error messages, but not a line-by-line configuration diff. It tempts because failed installs surface there, yet the detailed comparison between FortiManager's policy database and the FortiGate's running configuration is displayed in the Install Wizard preview.

Configure global policies

Why it fails: Global policies are defined at the global ADOM level and assigned to ADOMs afterwards; creating an ADOM does not require them. It is tempting because global policies are central to multi-ADOM governance, and would be correct when standardising security profiles across several ADOMs rather than configuring a single one.

Schedule backups

Why it fails: Scheduling backups is an operational housekeeping task performed after an ADOM exists, not a step required to create one. It is tempting because backups are universally recommended for FortiManager administration, and would be correct when maintaining disaster recovery of ADOM configuration data rather than provisioning a new ADOM.

Assign a firewall to the ADOM

Why it fails: Assigning a firewall is a later management task, not part of ADOM creation; a firewall can be added to an ADOM only after that ADOM exists. It is tempting because ADOMs ultimately contain managed devices, but the mandatory creation steps are naming the ADOM and selecting its firmware version.

Global Policy Packages

Why it fails: Global policies are applied across all ADOMs and cannot be selectively pushed to only one device in a standard package.

Provisioning Templates

Why it fails: Provisioning Templates configure device settings such as interface and system parameters, not policy package assignment. They cannot restrict which firewalls receive an ADOM policy change. They would be correct when rolling out consistent configuration to newly added FortiGate devices, but granular policy deployment requires per-device policy package assignment instead.

Device Groups

Why it fails: Device Groups bundle devices for firmware and configuration tasks, but policy package installation targets are set per device or via the Install Wizard, not by group membership. Groups are tempting because they organise firewalls logically, yet they grant no granular control over which policies reach which firewall.