FCP_FMG_AD-7-6 Practice Questions

The exhibit displays a firewall address object named LAN configured in FortiManager with "Per-Device Mapping" enabled. This feature allows a single object to have different values on different managed devices. The default value is 10.10.10.5/32, but the mapping table specifies unique values for individual devices. For the device Remote-Firewall [VDOM1], the IP/netmask is explicitly mapped to 21.21.2.5/255.255.255.255. When FortiManager installs the policy package to Remote-Firewall [VDOM1], it will substitute the default object value with this specific mapped value.

B. 172.16.5.20/255.255.255.255 is the mapped value for the Local-FortiGate [root] device, not the Remote-Firewall [VDOM1].

C. 172.16.5.0/255.255.255.0 is an incorrect value that does not appear in the object's configuration or its per-device mappings.

D. 10.10.10.5/255.255.255.255 is the default value for the object, which is overridden by the specific mapping for Remote-Firewall [VDOM1].

1. FortiManager Administration Guide 7.2.3

Chapter: "Policy and Objects"

Section: "Dynamic objects". The guide states

"You can map a dynamic object to a different value for each device... When you install the policy package to a device

the per-device mapping is used for the device." This confirms that the specific mapping for Remote-Firewall will be used.

2. Fortinet Certified Professional - Network Security 7.2 Study Guide - FortiManager

Chapter: "Policy and Objects"

Section: "Dynamic Objects". This section explains that per-device mapping allows an administrator to define a single object that resolves to a unique value on each managed device

which is the exact functionality shown in the exhibit.

In FortiManager, templates are used to enforce standardized configurations across multiple devices. When a template, such as a BGP template, is assigned to a FortiGate, the settings defined within that template take precedence over any manual, device-level configurations for the same feature. In this scenario, even though the administrator configured the BGP peer in the device-level database, the assigned BGP template's configuration was pushed during the installation. Since the new peer was not in the template, it was not applied to the FortiGate, resulting in the observed behavior.

A. A sanity check is used to verify database integrity. A corrupted database would likely cause installation failures or other widespread errors, not the silent omission of a specific setting.

C. The Install Wizard is the tool used for installation, but the choice of "Install device settings only" would not resolve the issue. The template's settings are considered part of the device settings and would still override the manual change.

D. A mismatch between the FortiGate firmware and the ADOM version typically generates warnings or causes the installation to fail. The question explicitly states the installation completed without any errors.

1. Fortinet FortiManager Administration Guide 7.2.3

Page 418

"Templates":

"Templates are used to provision and manage common device settings on managed devices... When you assign a template to a device

the settings in the template are applied to the device. If there is a conflict between the settings in the template and the settings on the device

the settings in the template take precedence." This directly supports the explanation that template settings override device-level settings.

2. Fortinet FortiManager Administration Guide 7.2.3

Page 420

"Creating a new template":

The guide details the creation of various templates

including CLI and BGP templates. It notes

"You can create templates to define specific configurations

such as BGP settings... and apply them to multiple devices." This confirms the existence and purpose of BGP templates.

In a FortiManager High Availability (HA) cluster, specific interfaces can be monitored for connectivity. If a monitored interface on the primary unit fails, the unit is considered to have failed. The secondary units, which constantly monitor the primary via heartbeat signals over these interfaces, will detect the failure. Upon detection, the cluster automatically initiates a failover process. A secondary unit is elected to become the new primary based on priority and uptime, and it takes over all management tasks. This entire process is designed to be automatic and transparent to administrators to ensure service continuity without requiring manual intervention.

B. Manual promotion is not required. The failover process is automatic when a monitored interface fails, which is a primary feature of the HA design.

C. Reconfiguring the primary device is incorrect. The primary unit is in a failed state, and the failover is initiated by the secondary units detecting the failure.

D. A database integrity check is not the trigger for a failover in this scenario. The failover is triggered by the loss of heartbeat signals due to the interface failure.

1. Fortinet FortiManager Administration Guide 7.0

Chapter: "High Availability"

Section: "HA failover"

Page 131.

The document states

"You can configure the cluster to monitor one or more FortiManager interfaces. If any of the monitored interfaces fail on the primary unit

the primary unit is considered to have failed and a failover occurs." This confirms that the failover is a direct and automatic consequence of the monitored interface failure.

2. Fortinet FortiManager Administration Guide 7.2

Chapter: "High Availability"

Section: "HA failover"

Page 141.

This guide reiterates the same principle: "A failover occurs when the primary unit is no longer detected by the other cluster units... You can configure the cluster to monitor one or more FortiManager interfaces. If any of the monitored interfaces fail on the primary unit

the primary unit is considered to have failed and a failover occurs." The automatic nature of this process makes it transparent to administrators.

When a FortiManager is deployed behind a Network Address Translation (NAT) device, managed devices on the other side of the NAT boundary must use FortiManager's public IP address to establish a connection. The NATed IP setting, configured under System Settings > Admin > Admin Settings, is specifically designed for this purpose. During the device discovery and authorization process, FortiManager provides this configured NATed IP address (100.65.0.120 in this case) to the FortiGate. The FortiGate then updates its central management settings (config system central-management) to use this public IP for all subsequent management traffic, ensuring successful communication.

A. The FortiGate is configured with only one management IP address. Pushing the private, non-routable IP (10.0.13.120) would cause a connection failure.

B. The IP address 100.65.0.101 is not relevant to the configuration shown in the exhibit or the described scenario.

C. The IP address 100.65.0.101 is not configured on the FortiManager and has no role in this management process.

1. FortiManager Administration Guide 7.2.0

Page 100

"Admin settings".

The guide states for the NATed IP field: "If FortiManager is behind a NAT device

enter the NATed IP address that FortiGate devices will use to connect to FortiManager." This confirms that the NATed IP is the address provided to the managed devices.

2. Fortinet Cookbook

"Adding a FortiGate to FortiManager (NAT mode)"

Document ID: FD40540.

This official guide details the exact scenario: "When adding the FortiGate

FortiManager will use the NATed IP to configure the central-management settings on the FortiGate. The FortiGate will then use this IP address to connect to the FortiManager." This explicitly confirms that the NATed IP is set on the FortiGate.

The exhibit displays a "Modified" status for "Config Status," "Policy Package Status," and "Provisioning Template Status."

The "Config Status: Modified" indicates that the running configuration on the managed FortiGate has changed and is no longer synchronized with the device-level database stored on FortiManager. This directly supports statement A.

The "Provisioning Template Status: Modified" indicates that the assigned system template has been altered within FortiManager. By design, when changes from a provisioning template are installed, they are pushed to the managed device, overwriting the corresponding device-level settings to enforce a standard configuration. This functional behavior supports statement D.

B. The "Modified" status across all categories explicitly indicates that changes are pending and have not been installed. An installation is required to synchronize the device.

C. The "Policy Package Status: Modified" clearly shows that the policy package on FortiManager is different from what is currently implemented on the FortiGate, indicating a mismatch.

1. Fortinet FortiManager Administration Guide 7.2.3

Page 123

"Device Manager pane".

Config Status: "A red M indicates that the device configuration has been modified." This confirms that the device configuration is out of sync with the FortiManager database

validating answer A.

Policy Package Status: "A red M indicates that the policy package has been modified." This confirms a mismatch

invalidating answer C.

2. Fortinet Certified Professional - Network Security Study Guide for FortiManager 7.2

Page 100

"Provisioning Templates".

The guide states

"When you install device settings to a managed device

the settings in the template are installed on the device... This allows you to enforce a standard configuration across multiple devices." This principle confirms that templates are designed to override device-level settings upon installation

validating answer D.

3. Fortinet FortiManager Administration Guide 7.0.1

Page 100

"Device & Groups > Managed Devices > Device Dashboard".

This guide corroborates the meaning of the "Modified" status: "A red M indicates that the device configuration has been modified." This directly contradicts the claim in option B that changes have been installed.

When a device is moved from one Administrative Domain (ADOM) to another within FortiManager, its existing configuration must be reconciled with the database of the new ADOM. The immediate action FortiManager takes is to launch the "Import Configuration" wizard. This wizard prompts the administrator to decide how to handle the device's current policies and objects. The administrator can choose to import them into the new ADOM's database, which is necessary to manage the device's existing configuration, or to discard them, which would typically require a new configuration to be pushed from the new ADOM.

A: The "Re-install Policy" dialog appears after configuration changes are made and ready to be pushed to the device, not immediately upon moving it to a new ADOM.

B: This image displays the "Move to ADOM" option within the device settings, which is the action taken to initiate the move, not the output after the move.

D: A "Synchronized" configuration status is the end-state, indicating that the device's running configuration matches the FortiManager database, which occurs after the import and any necessary installations are completed.

1. Fortinet. (2023). FortiManager Administration Guide 7.4.0. Fortinet Document Library. Retrieved from https://docs.fortinet.com/document/fortimanager/7.4.0/administration-guide/239981/moving-a-device-to-another-adom.

Reference Details: In the section "Device Manager > Moving a device to another ADOM" (page 241)

the guide states

"When you move a device to another ADOM

the Import Configuration wizard is displayed. You can select to import the device configuration

policies

and objects to the new ADOM

or not." The accompanying screenshot is identical to the image in option C.

2. Fortinet. (2022). FortiManager Administration Guide 7.2.0. Fortinet Document Library. Retrieved from https://docs.fortinet.com/document/fortimanager/7.2.0/administration-guide/239981/moving-a-device-to-another-adom.

Reference Details: In the section "Device Manager > Moving a device to another ADOM" (page 231)

the procedure and resulting dialog box are described and shown

confirming that the "Import Configuration" wizard is the immediate output.

The standard and required procedure to deploy a central policy package from FortiManager to a managed FortiGate is to use the Install Wizard. As shown in the second exhibit, the wizard guides the administrator through the installation process. It allows for reviewing, validating, and then pushing the configuration changes to the target device, BR1-FGT-1. The "Unknown" status in the first exhibit indicates that FortiManager has not yet compared the policy package with the device's current configuration, and initiating an installation via the wizard is the correct next step to synchronize them.

A: This is incorrect. A single FortiGate device can be assigned multiple policy packages, especially in a multi-VDOM environment where each VDOM has its own distinct policy package.

B: Importing a policy package is the action of pulling the configuration from the FortiGate to FortiManager. The administrator's task is to install (push) the configuration to the FortiGate.

D: The exhibit shows the policy package status as "Unknown," not "modified." While resolving modified templates is necessary before installation, it is not the issue presented in this specific scenario.

1. FortiManager Administration Guide 7.0

Chapter: "Policy & Objects"

Section: "Installing a policy package".

This section explicitly states: "You can use the Install Wizard to install a policy package to a device." It then details the step-by-step process

which matches the interface shown in the second exhibit. This directly validates that the Install Wizard is the correct tool for the task.

2. FortiManager Administration Guide 7.0

Chapter: "Policy & Objects"

Section: "Policy package statuses".

The guide defines the "Unknown" status: "The policy package has never been imported or installed to the device." This confirms that installation is a valid next step to resolve this status

refuting the need to address a non-existent "modified" status as suggested in option D.

3. FortiManager Administration Guide 7.0

Chapter: "Device Manager"

Section: "VDOMs".

The documentation explains: "When you create a VDOM on a device

a policy package for that VDOM is automatically created in FortiManager." This demonstrates that a single device with multiple VDOMs will have multiple associated policy packages

proving option A is factually incorrect.

Workspace mode is a feature specifically designed to prevent configuration conflicts when multiple administrators are working within the same Administrative Domain (ADOM). When an administrator starts making changes in an ADOM with workspace mode enabled, the ADOM is locked. This locking mechanism prevents other administrators from making concurrent changes, thus avoiding overwrites and conflicts. Administrators can see who has locked the ADOM and must wait until it is unlocked before they can make their own modifications. This provides a clear and effective method for managing simultaneous administrative access.

A. Configure RADIUS authentication to assign ADOM roles to each user.

RADIUS is an authentication protocol; while it can assign roles and permissions, it does not inherently manage or prevent concurrent configuration conflicts between authorized users.

B. Enable workflow mode, which is the only way to prevent concurrent configuration conflicts.

Workflow mode enforces a change management process (submit, approve, deploy) but does not prevent concurrent editing. Workspace mode is the primary feature for this, making the claim "only way" incorrect.

C. Assign administrators with JSON API access to the FortiManager.

Using the API is a method of interaction, not a conflict resolution mechanism. Multiple API users could still attempt to modify the same object simultaneously, leading to conflicts.

1. Fortinet FortiManager Administration Guide 7.4.1

Page 218

Section: "Workspace mode".

The guide states

"Workspace mode prevents administrators from simultaneously making configuration changes to the same ADOM

device

or policy package. When an administrator is working in an ADOM

the ADOM is locked

and other administrators cannot make changes to the ADOM." This directly supports the function of workspace mode for conflict prevention.

2. Fortinet FortiManager Administration Guide 7.2.1

Page 211

Section: "Workspace mode".

This version of the guide provides the same explanation: "Workspace mode prevents administrators from simultaneously making configuration changes to the same ADOM

device

or policy package."

3. Fortinet FortiManager Administration Guide 7.0.1

Page 208

Section: "Workspace mode".

The documentation for this version also confirms

"In workspace mode

you can prevent two or more administrators from simultaneously editing the same ADOM

device

or policy package." It also contrasts this with Workflow mode

which is described on page 210 as a process for "approving and deploying configuration changes."

For environments with a high volume of logs, the recommended Fortinet architecture is to use a dedicated FortiAnalyzer appliance. FortiAnalyzer is specifically designed for high-speed log collection, storage, analysis, and reporting, making it the optimal solution for scalability. By adding the FortiAnalyzer to FortiManager, you can centralize both device management (FortiManager) and log analysis (FortiAnalyzer) under a single pane of glass. This integration allows administrators to manage the FortiAnalyzer and access its reporting capabilities directly from the FortiManager GUI, creating a powerful and efficient security management and analytics platform.

A. FortiManager has limited built-in logging and reporting capabilities suitable for smaller deployments, but it is not designed to handle a high volume of logs.

C. Enabling ADOMs (Administrative Domains) is a feature for segmenting and delegating the administration of managed devices; it does not address log storage or processing capacity.

D. The correct and efficient log flow is from managed devices (like FortiGate) to FortiAnalyzer. Forwarding logs from FortiAnalyzer back to FortiManager is illogical and inefficient.

1. FortiManager Administration Guide (7.4.1)

Chapter: "Log View and FortiView"

Section: "Log View".

Page 431 states

"FortiManager can be configured to be the central logging and reporting device for a small number of devices and a low volume of logs. For more extensive logging

a FortiAnalyzer unit is required." This directly supports the need for FortiAnalyzer in high-volume scenarios and refutes option A.

2. FortiManager Administration Guide (7.4.1)

Chapter: "FortiAnalyzer"

Section: "Adding FortiAnalyzer to FortiManager".

Page 451 details the procedure for integrating a FortiAnalyzer. It states

"FortiManager can be used to manage a FortiAnalyzer unit. When FortiManager is managing a FortiAnalyzer unit

you can view FortiAnalyzer device information from the FortiManager GUI." This confirms that adding and managing FortiAnalyzer from FortiManager (Option B) is the intended operational model.

3. Fortinet Certified Professional - Security Operations Study Guide for FortiOS 7.2

Chapter 1: "Introduction to FortiSOAR"

Section: "Fortinet Security Fabric".

This guide consistently depicts the architectural relationship where FortiGate devices send logs to FortiAnalyzer for analysis and reporting

while FortiManager provides centralized management. This reinforces the distinct roles of each product and the correct log flow

invalidating option D.

When a script is executed against the Device Database on FortiManager, the changes are applied only to the configuration data stored within FortiManager for that specific device. This action does not directly alter the configuration on the managed FortiGate. Consequently, FortiManager detects a difference between its stored configuration and the last known configuration of the device, changing the device's Config Status to Modified. To apply these database changes to the actual FortiGate, the administrator must explicitly initiate an installation process, which is typically done using the Install Wizard.

B. The script history shows the successful installation of the script on the remote FortiGate.

This is incorrect because running a script on the Device Database only modifies the database. The installation of the resulting configuration onto the FortiGate is a separate, subsequent step.

C. The successful execution of a script on the Device Database creates a new revision history.

This statement is imprecisely worded. A new revision entry is created in the existing revision history, not an entirely "new revision history". Options A and D describe the primary operational outcomes more accurately.

1. FortiManager Administration Guide 7.4.0

Page 258

"Running scripts":

"You can run scripts on the device database... The changes are not pushed to the managed device. You must install the device settings to a device to push the changes to the device."

This directly supports option D

stating that an installation is a required subsequent step.

2. FortiManager Administration Guide 7.4.0

Page 22

"Device Manager" pane:

"When the device configuration on the FortiManager is different from the configuration on the managed device

the Config Status column shows Modified."

This supports option A

as running the script on the database creates this difference

triggering the "Modified" status.

3. FortiManager Administration Guide 7.4.0

Page 258

"Running scripts":

"When you run a script on the device database

a new revision is created in the revision history."

This shows that a revision is created

but the wording in option C ("creates a new revision history") is ambiguous compared to the more direct and certain outcomes described in A and D. The operational status change (A) and the required action (D) are the most significant results for an administrator.