How to Deploy a Security Policy to All Firewalls in a FortiManager ADOM
A FortiGate administrator needs to use FortiManager to deploy a new security policy to all firewalls in a specific ADOM. Which two steps are part of the installation process? (Choose two.)
Quick Answer
The correct answer involves selecting the target devices and clicking 'Install', along with using the install preview to review changes before deployment. The install preview is critical because it generates a detailed diff of the policy package against each firewall’s current configuration, showing every addition, deletion, or modification—this prevents unintended disruptions by allowing the administrator to verify exactly what will be pushed. On the Fortinet NSE 7 Advanced Security NSE7 exam, this question tests your understanding of FortiManager’s staged deployment workflow within an ADOM, where the common trap is assuming that simply saving the policy package pushes it automatically. Remember, the install preview is your safety net, and the manual 'Install' button is the final trigger—think "Preview then Push" to avoid policy chaos.
⚠ Common exam trap
Candidates often confuse the 'install preview' (a read-only verification step) with the actual 'install' action, or they mistakenly think that revision history or automation stitches are mandatory prerequisites for deploying a policy package.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Run the install preview to see the changes that will be applied
Option B is correct because running the install preview in FortiManager lets the administrator review exactly which policy package changes will be pushed to the managed FortiGates before committing, helping avoid unintended configuration changes. Option C is correct because the actual deployment step in FortiManager's Install Wizard requires selecting the target devices (or all devices in the ADOM) and clicking 'Install' to push the policy package to those firewalls. Option A is not part of the installation process itself; revision history is a logging/versioning feature that records changes, not a required install step. Option D is unnecessary because the scenario already specifies an existing ADOM containing the firewalls, so creating a new ADOM is not required. Option E is incorrect because automation stitches are used to trigger automated actions based on events, not to install a policy package to devices.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure revision history to track changes
Why it's wrong here
Revision history passively records configuration changes for audit and rollback; it performs no push to managed devices. Installation requires selecting the policy package and target devices, then invoking Install Wizard. Revision tracking is the right choice when you need to compare or revert prior FortiManager configuration states, not to deploy policy.
- ✓
Run the install preview to see the changes that will be applied
Why this is correct
The install preview queries FortiManager for the pending configuration differences and displays exactly what will be pushed to each managed firewall in the ADOM. Reviewing it before installation confirms the policy changes are correct, satisfying the deployment step.
- ✓
Select the target devices and click 'Install'
Why this is correct
Selecting target devices and clicking 'Install' initiates FortiManager's policy installation, pushing the ADOM's policy package to the chosen managed FortiGates. This directly satisfies the stem's requirement to deploy to all firewalls in the ADOM, since installation only occurs once devices are explicitly selected as targets.
- ✗
Create a new ADOM for the policy package
Why it's wrong here
The policy must reach firewalls in an existing ADOM, so creating another ADOM adds no deployment step and would orphan the package. New ADOMs are created when separating administrative domains or device groups with distinct policy scopes. Installation instead assigns the package to the target ADOM's managed FortiGates.
- ✗
Enable automation stitches to push the policy
Why it's wrong here
Automation stitches trigger actions on event logs, not policy installation; they cannot push a package to an ADOM. The Install Wizard performs that deployment directly. Stitches suit reactive workflows such as quarantining a compromised host after an IPS event, which is unrelated to distributing configuration.
Go deeper
Related to this question
About these practice questions
One of 718 original NSE7 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on NSE7
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A FortiManager administrator is planning to deploy a new policy package to a FortiGate that has multiple VDOMs. To ensure the policy package is applied correctly to the target VDOM, which THREE steps should the administrator take?
hard- ✓ A.Install the policy package to the FortiGate, selecting the correct VDOM
- ✓ B.Create a new policy package in the ADOM corresponding to the target VDOM
- C.Configure a revision history to track changes
- ✓ D.Assign the FortiGate to the policy package
- E.Enable central management on the FortiGate
Why A: When installing a policy package to a FortiGate with multiple VDOMs, the administrator must select the correct target VDOM in the installation wizard. This ensures the policy package is applied to the intended VDOM and not to the global or another VDOM, which could cause policy conflicts or security gaps.
Variation 2. An administrator uses FortiManager to deploy a new security policy to a remote FortiGate. The administrator selects 'Install Preview' and sees that the policy will be created. After confirming, the installation fails with 'Device not reachable'. What is the most likely reason?
medium- A.The FortiGate has insufficient memory
- B.The policy package is locked by another administrator
- C.The FortiGate's configuration revision has changed since the last sync
- ✓ D.The FortiGate is behind a NAT device that blocks FGFM traffic
Why D: The 'Device not reachable' error during an Install Preview operation indicates that FortiManager cannot establish or maintain the FGFM (FortiGate-to-FortiManager) tunnel with the remote FortiGate. When the FortiGate is behind a NAT device, the NAT may alter the source IP or port of FGFM traffic, causing the tunnel to break or preventing the FortiManager from reaching the FortiGate's management IP. This is the most common cause of such reachability failures in remote deployments.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE7 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE7 exam.