FCP_FMG_AD-7-4 Practice Questions

After a successful authentication request to the FortiManager JSON API, the system returns a unique session ID. This session ID acts as a temporary authentication token. For all subsequent API calls within the same session, this ID must be included in the JSON RPC request payload. This allows FortiManager to verify that the request is coming from an authenticated and authorized user, eliminating the need to send login credentials with every single request. The session remains valid until it is explicitly terminated or times out.

A. The session ID is an authentication credential, not a mechanism for identifying or managing client-side metadata related to the FortiManager.

B. The session ID is a token for session management and authentication; it is not a cryptographic hash used for verifying the integrity of JSON responses.

C. The HTTP request method (e.g., POST) is part of the HTTP protocol itself and is independent of the session ID, which is part of the JSON payload for authentication.

1. Fortinet FortiManager Administration Guide 7.4.0

Page 598

Section: "JSON API". The guide states

"After you log in

you receive a session ID that you must use for all subsequent requests." This confirms its role as a token for subsequent requests.

2. Fortinet FortiManager API Reference 7.4.0

Page 10

Section: "Authentication". The documentation details the login process and shows that the response contains a "session" key. It further explains

"The session key is required for all subsequent requests to the FortiManager unit." An example request on page 11 demonstrates including the "session": "..." key-value pair in a subsequent API call.

When a script is executed against the "Device Database" on FortiManager, the changes are applied only to the configuration stored locally on the FortiManager, not directly to the managed FortiGate. This action creates a discrepancy between the configuration on FortiManager and the running configuration on the device. Consequently, the system flags the device's Config Status as Modified. To apply these database changes to the actual device, the administrator must initiate an installation process, which is done using the Install Wizard.

B. While running a script on the device database does create a new configuration revision, options A and D describe the more direct, user-facing results and the necessary subsequent action.

C. The script history shows successful execution on the FortiManager's local database, not a successful installation on the remote FortiGate, which is a separate and subsequent manual step.

1. Fortinet FortiManager Administration Guide 7.4.1

Page 301

Section "Scripts > Running a script".

The guide states: "When you run a script on the Device Database

the script is run against the device-level database on FortiManager. The device configuration is not pushed to the managed device. The device's configuration status changes to Modified. You must install the device settings to the managed device." This passage directly validates answers A and D.

2. Fortinet FortiManager Administration Guide 7.4.1

Page 238

Section "Device Manager > Viewing device status".

This section defines the "Modified" status: "The device configuration has been changed on the FortiManager

but these changes have not been installed to the device." This confirms the outcome described in option D.

3. Fortinet FortiManager Administration Guide 7.4.1

Page 251

Section "Configuration and installation management > Installing device and policy package settings".

This section details the installation process: "After making configuration changes to a device or a policy package

you must install the changes to the managed devices." This supports the necessity of the action described in option A.

The exhibit displays several key indicators that point to a recent FortiManager configuration restore. The "Config Status" and "Policy Package Status" are both "Unknown," and the "Last Backup" is "Never." This specific combination occurs when a FortiManager configuration is restored from a backup. The restore process re-populates the list of managed devices but does not restore their configuration history or the secure FGFM management tunnel state. As a result, FortiManager knows the device exists but has lost all historical data and the active connection, leading to the "Unknown" statuses and the "FGFM tunnel is down" message.

A. Refreshing the device is a valid action to retrieve the configuration, but it can only be performed after the FGFM tunnel connectivity is re-established.

B. While a loss of internet connectivity could cause the FGFM tunnel to go down, it would not change the configuration and policy statuses to "Unknown."

C. Reclaiming the FGFM tunnel is a corrective action to fix the connectivity, not a conclusion that can be drawn about the root cause of the issue.

1. FortiManager Administration Guide 7.4.1

Page 101

"Restoring the FortiManager configuration": The official documentation states

"After restoring the FortiManager configuration

the connection to the FortiGate is lost. You must re-establish the connection." This directly explains why the FGFM tunnel is down.

2. FortiManager Administration Guide 7.4.1

Page 101

"Backing up and restoring the configuration": The guide also notes

"When you restore the FortiManager configuration

device-level settings are restored

but device configuration history is not restored." This detail explains why the "Config Status" is "Unknown" and "Last Backup" is "Never

" as the historical data required to determine these statuses is gone after a restore.

3. FortiManager Administration Guide 7.4.1

Page 201

"Device database": This section explains that the device database on FortiManager stores historical revisions. A configuration restore does not include this historical data

leading to the "Unknown" status until a configuration is retrieved from the device again.

In a FortiManager High Availability (HA) cluster, the primary unit's configuration defines the cluster membership. When a secondary (peer) device fails and cannot be recovered, the HA cluster is in a degraded state. To return the cluster to a stable, working condition with the remaining active members, an administrator must manually intervene. The correct procedure is to access the primary FortiManager's HA settings and remove the configuration entry, including the IP address, for the failed secondary device. This action updates the cluster's topology and resolves the inconsistency caused by the unreachable member.

A: This is incorrect. Manual mode HA requires administrator intervention to manage cluster membership, especially in a failure scenario. The process is not transparent.

B: Rebooting the failed device will not change the HA configuration on the primary unit. If the device is permanently offline, this action has no effect on the cluster's state.

C: Promoting a secondary device is the procedure for a primary device failure, not a secondary one. The primary unit is still operational in this scenario.

1. FortiManager Administration Guide 7.4.1

Chapter: "High Availability"

Section: "Managing the cluster"

Subsection: "Removing a failed cluster member"

Page 71.

The documentation explicitly states: "If a cluster member fails

you must remove it from the cluster. You must edit the HA configuration on the primary FortiManager to remove the failed device." It then provides the GUI steps: "Go to System Settings > HA... In the Peer Information table

select the failed device and click Delete." This directly supports the action of reconfiguring the primary device.

In FortiManager, when a global policy package is assigned to an Administrative Domain (ADOM), that assignment applies to the entire ADOM. Consequently, all existing policy packages within that ADOM, as well as any new policy packages created subsequently, will automatically have the global policy package assigned to them. This mechanism ensures that global security rules are consistently applied across all policy sets managed within that specific ADOM without requiring manual intervention for each new package.

A. You must assign the global policy package from the global ADOM.

This is incorrect. The assignment is made to the ADOM, and the new package inherits it automatically, eliminating the need for a separate manual assignment.

C. You must reapply the global policy package to ADOM1.

This is incorrect. Creating a new policy package within an ADOM does not affect the existing ADOM-level assignment of the global policy package.

D. You can select the option to assign the global policies.

This is incorrect. The assignment is automatic for any new policy package created in an ADOM that already has a global policy package assigned; it is not an optional step during package creation.

---

1. Fortinet FortiManager Administration Guide 7.4.1

Page 411

Section: "Global policy and objects > Assigning a global policy package to an ADOM".

The documentation states: "When you assign a global policy package to an ADOM

the global policy package is automatically assigned to all policy packages in the ADOM. When you create a new policy package in the ADOM

the global policy package is automatically assigned to the new policy package." This directly supports the correct answer.

The assignment of a global policy package is performed at the ADOM level. Once a global policy package is assigned to an ADOM, FortiManager automatically links that global package to any new policy package created within that specific ADOM. This is a fundamental behavior of the FortiManager ADOM architecture, designed to ensure that global security rules are consistently applied across all policy sets within the managed domain without requiring redundant manual configuration for each new package.

A. The assignment is automatic due to the ADOM-level setting; it is not a selectable option during the creation of a new policy package.

B. The assignment is made to the ADOM, not individually to each new package from the global ADOM. The action is not repeated.

C. The term "import" is incorrect. Global policies are "assigned" or "linked" to an ADOM, making them available to local packages, not imported into them.

1. Fortinet FortiManager Administration Guide 7.4.1

Page 429

Section: "Global policy packages > Assigning a global policy package to an ADOM".

The document states: "After a global policy package is assigned to an ADOM

you can create policy packages in the ADOM. When you create a policy package in the ADOM

the global policy package is automatically assigned to the new policy package." This directly confirms that the assignment is automatic for any new package created within the ADOM.

The exhibit displays the output of a system performance command, which lists running processes and their resource consumption. The process responsible for downloading security service databases, such as web and email filters, from the public FortiGuard servers is the FortiGuard update daemon, named fgdupdate. The last column in the provided output represents the percentage of memory (%MEM) being used by each process. By locating the fgdupdate process in the list, we can see that its corresponding memory usage is 2.9%.

B. 3.1: This value represents the memory usage for the sqlconn process, which manages SQL database connections, not FortiGuard updates.

C. 1.5: This value is the memory usage for the fmd (FortiManager Daemon) process, which is the main management daemon.

D. 4.1: This value corresponds to the memory usage of the sqlwriter process, which is responsible for writing data to the SQL database.

1. FortiManager Administration Guide 7.4.1

"FortiGuard" section

subsection "Settings". This section explains that FortiManager retrieves packages and updates from the public FortiGuard Distribution Network (FDN). The fgdupdate daemon is the underlying process that handles these update and package downloads.

2. FortiManager CLI Reference 7.4.1

page 1031

under the get system performance top command description. The official documentation confirms the output format of this command

specifying that the final column

%MEM

represents the "Percentage of real memory used" by the process. This validates that the value 2.9 for fgdupdate is the correct memory usage percentage.

Policy locking is a core component of the FortiManager workspace mode, which prevents administrators from overwriting each other's changes. Workspace mode can be configured in two ways: normal mode or workflow mode. In normal mode, an administrator must explicitly lock a policy package before they can make any changes. This lock grants them exclusive editing rights to that package. Once the changes are complete, they can unlock it, allowing other administrators to make modifications. This mechanism is fundamental to how workspace normal mode operates.

B. Locking a policy takes precedence over a locked ADOM.

An ADOM lock is a higher-level restriction. If an entire ADOM is locked, no administrator (other than the one who holds the lock) can edit any object within it, regardless of individual policy lock status.

C. When a policy is locked, the ADOM that contains it is also locked.

Locking a policy package is a granular action. It does not lock the entire ADOM, thus allowing other administrators to work concurrently on different policy packages or objects within the same ADOM.

D. Administrators in the approval group can work concurrently on a locked policy.

A lock provides exclusive editing rights to the administrator who holds it. No other user, including those in an approval group, can work on the policy concurrently until the lock is released.

1. FortiManager Administration Guide 7.4.1

Chapter: "FortiManager Key Concepts"

Section: "Administrative Domains (ADOMs)"

Subsection: "Workspace".

Reference for Correct Answer (A): The guide states

"Workspace mode can be enabled in one of two modes: Normal or Workflow... In normal mode

administrators can lock and unlock ADOMs as required." It further clarifies

"To make changes to policy packages and objects

administrators must lock the policy package." This confirms that locking policies is a standard procedure in workspace normal mode.

Reference for Incorrect Options (B

C

D): The same section explains the exclusivity and hierarchy of locks. It notes

"When an ADOM is locked

other administrators cannot make changes in the ADOM

" which refutes option B. The ability to lock individual policy packages without locking the entire ADOM is the basis of concurrent administration

refuting option C. The principle of a lock is to prevent concurrent changes

which refutes option D.

The FortiGate Management Protocol (FGFM) keepalive message is a periodic heartbeat sent from a managed FortiGate to the FortiManager. Its primary purpose is to communicate the device's operational status. This message critically includes a checksum of the FortiGate's running configuration, which allows FortiManager to track the device's configuration status (e.g., Synchronized, Modified). It also contains status information about security databases, including the installed IPS and Antivirus engine/definition versions. This enables FortiManager to monitor the security posture and report if the device's protections are up-to-date.

B. FortiGate license information is generally static and is communicated during initial registration or less frequent status updates, not within every high-frequency keepalive message.

D. While FortiManager monitors a device's online status via keepalives, the specific uptime value is a less critical management metric compared to configuration and security posture information.

1. FortiManager Administration Guide 7.4.0

Page 19

Section: "FortiManager protocol (FGFM)".

"The FortiGate unit periodically sends a heartbeat

or keepalive

message to the FortiManager system to indicate that it is online. The message includes the FortiGate unit’s serial number

checksum of the configuration

and other status information." (This directly supports option C).

2. FortiManager Administration Guide 7.4.0

Page 230

Section: "Device Manager > Monitors > FortiGate Status".

This section describes the information displayed in the FortiGate Status monitor

which is populated by data from the managed devices. The "AV/IPS DB" column shows the status of the Antivirus and IPS databases. This information is sent periodically from the FortiGate to the FortiManager via the FGFM protocol

specifically within the status updates of the keepalive message. (This supports option A).

The exhibit displays the FortiManager FortiGuard settings. The section for "Antivirus and IPS Updates" has the option "Use override server for updates" enabled. This configuration explicitly instructs FortiManager to bypass the public FortiGuard Distribution Network (FDN) and instead use the server specified in the "Server Override Address" field. In this case, the IP address is 10.0.1.50. Therefore, FortiManager will attempt to get antivirus and IPS updates exclusively from the configured override server at 10.0.1.50.

A. The override setting forces the use of the specified server only; it does not create a list or automatically fall back to public FDN servers.

C. The default public FDN servers are bypassed because the "Use override server for updates" option is explicitly enabled in the configuration.

D. This describes an arbitrary selection method for public servers, which is incorrect and irrelevant as the configuration uses a specific override server.

1. FortiManager Administration Guide 7.4.1

System Settings > FortiGuard

Page 318.

The guide describes the "Use override server for updates" setting under the "Antivirus and IPS Updates" section. It states: "When enabled

FortiManager uses the override server to get antivirus and IPS updates." This confirms that enabling this option directs update requests to the specified override server

not the public FDN.

2. FortiManager Administration Guide 7.4.0

System Settings > FortiGuard

Page 314.

Similar to the 7.4.1 guide

this document details the FortiGuard settings. The description for "Server Override Address" is "Enter the IP address or FQDN of the override server." This

combined with the enabled override option

confirms that 10.0.1.50 is the sole destination for these update requests.