For log correlation to be effective, events from different devices must be placed in the correct chronological order. This requires all logging devices and the FortiAnalyzer to have synchronized system clocks. Using a Network Time Protocol (NTP) server ensures that all devices share a common, accurate time source. This synchronization is fundamental for FortiAnalyzer to accurately correlate log entries from various sources and reconstruct the precise sequence of events for analysis, reporting, and incident response.

A. Use DNS: DNS resolves hostnames to IP addresses, which is necessary for communication but does not ensure the time synchronization required for log correlation.

B. Use host name resolution: This is a general term for name-to-IP mapping (like DNS). It is unrelated to the time-stamping accuracy needed for correlating log data.

C. Use real-time forwarding: While real-time forwarding ensures logs are sent promptly, it does not correct inaccurate timestamps on the logs themselves, which would still prevent proper correlation.

1. FortiAnalyzer 7.4.0 Administration Guide

Page 101

"System Information widget": This section details the importance of system time and configuring NTP. It states

"The System Time widget displays the FortiAnalyzer system time and allows you to configure the system time and an NTP server." This highlights NTP as the mechanism for time management.

2. FortiOS 7.4.0 Administration Guide

Page 103

"Settings": This guide for the logging device (FortiGate) emphasizes the importance of time synchronization for logging. It states

"It is important to have the correct time on your FortiGate

especially for logging... You can manually set the FortiGate's system time or configure the FortiGate to automatically synchronize its clock with a Network Time Protocol (NTP) server." This directly links correct time via NTP to the quality of logs sent to FortiAnalyzer.

3. FortiAnalyzer 7.4.0 Administration Guide

Page 138

"Adding devices": The guide implicitly requires correct time settings for proper device management and logging. While not using the word "correlation" in this specific sentence

the entire function of analyzing logs from multiple devices depends on it. The prerequisite is that devices are "configured to send logs to FortiAnalyzer

" and as per the FortiOS guide

proper configuration for logging includes time synchronization.

On a FortiAnalyzer, analytics logs are logs that have been received from a device, processed, and then indexed into the SQL database. This indexing process is crucial for enabling the fast data retrieval required for analytical functions, such as generating reports, charts, and datasets in Log View and FortiView. These indexed logs are optimized for analysis and are distinct from raw, active log files or compressed archives. The system uses this structured data to provide insights and detailed reporting on network activity.

A: This describes active logs. These are the raw log files currently being written to by connected devices before they are indexed for analytics.

B: This describes archived logs. When an active log file is rolled over, it is compressed into a .gz file for long-term storage, not for immediate analytics.

C: This describes the process of log rolling, which is a mechanism to manage log file size and is not a type or state of a log file itself.

1. FortiAnalyzer Administration Guide 7.4.2

Page 161

Section: "Log files".

The guide states: "Logs are indexed to the SQL database for analytic support. Analytics logs are also referred to as indexed logs." This directly supports option D.

It also defines other log states: "The active log file is the log file that is currently receiving logs from the connected devices." (Refuting A) and "When a log file is rolled over

it is compressed to the .gz format and archived." (Refuting B).

2. FortiAnalyzer Administration Guide 7.4.2

Page 162

Section: "Log rolling".

This section describes log rolling as a process: "Log rolling saves the active log file and starts a new active log file when the active log file reaches a specific size or at a scheduled time." This confirms that option C is a process

not a log type.

When upgrading a FortiAnalyzer High Availability (HA) cluster, the process is managed from the primary unit. The primary unit orchestrates a sequential upgrade to maintain service availability. It first sends the firmware image to all secondary (or slave) units and initiates their upgrade. Once the secondary units have successfully upgraded and rebooted, the primary unit proceeds to upgrade its own firmware. This rolling upgrade methodology ensures that the cluster's logging and reporting services remain operational on the primary unit while the secondary units are offline, minimizing overall downtime for the HA cluster.

A. You can perform the firmware upgrade using only a console connection.

This is incorrect. The firmware upgrade can be initiated from the primary unit's GUI or CLI (via SSH or console), not exclusively through a console connection.

B. All FortiAnalyzer devices will be upgraded at the same time.

This is false. A simultaneous upgrade would cause a complete service outage. The upgrade is performed sequentially—secondaries first, then the primary—to ensure high availability.

C. Enabling uninterruptible-upgrade prevents normal operations from being interrupted during the upgrade.

This is incorrect. The uninterruptible-upgrade setting is a feature for FortiGate HA clusters to maintain traffic flow, not for FortiAnalyzer HA clusters.

1. FortiAnalyzer Administration Guide 7.4.1

Chapter: "High Availability"

Section: "Upgrading the FortiAnalyzer HA cluster"

Page 101.

Quote: "You can upgrade the firmware of a FortiAnalyzer HA cluster from the primary unit GUI. When you upgrade

the primary unit upgrades the firmware of the secondary units first

and then its own firmware." This directly supports the correct answer (D) and refutes option (B).

The guide also details the GUI-based upgrade process

refuting the "console only" claim in option (A).

2. FortiAnalyzer CLI Reference 7.4.1

config system ha section.

This reference confirms the absence of an uninterruptible-upgrade option within the FortiAnalyzer HA configuration commands

demonstrating that option (C) refers to a non-existent feature for this product.

When Administrative Domains (ADOMs) are enabled on a FortiAnalyzer, the default operational mode is Normal mode. In this mode, all VDOMs from a single FortiGate device must be assigned to the same ADOM.

Advanced mode provides greater flexibility. A key feature of Advanced mode is the ability to assign different Virtual Domains (VDOMs) from a single physical FortiGate device to multiple, separate ADOMs on the FortiAnalyzer. This allows for more granular administrative separation and reporting for different VDOMs residing on the same hardware.

A: The disk quota for an ADOM is configurable when the ADOM is created or edited, regardless of whether FortiAnalyzer is in Normal or Advanced mode.

B: The ADOM mode can be changed from both the GUI (under System Settings > All ADOMs) and the CLI, not just the CLI.

1. FortiAnalyzer Administration Guide 7.4.1

Chapter: "System Settings"

Section: "ADOMs"

Page 100.

"Normal mode is the default ADOM mode." (Supports answer D)

"In advanced mode

you can assign VDOMs from a single FortiGate device to different FortiAnalyzer ADOMs." (Supports answer C)

The guide shows a screenshot of the GUI for changing the ADOM mode

which invalidates option B.

2. FortiAnalyzer Administration Guide 7.4.1

Chapter: "System Settings"

Section: "Creating ADOMs"

Page 102.

This section shows the "Device Quota (MB)" field as a standard part of ADOM creation

which can be edited later. This functionality is not tied to the ADOM mode

invalidating option A.

The set log-checksum md5-auth command configures the FortiAnalyzer to secure log files by generating a checksum. This specific option uses the MD5 algorithm combined with a pre-shared authentication code (key). The purpose is to ensure log file integrity and authenticity. When logs are rolled, FortiAnalyzer calculates a hash value using both the log data and the secret authentication code. This makes it computationally infeasible for an unauthorized party to alter the log file and forge a new, valid checksum without knowing the code, thus providing stronger integrity verification than a simple MD5 hash.

A: This option is incomplete. While an MD5 hash is used, the md5-auth setting specifically adds an authentication code to the process, which this answer omits.

B: This command relates to log file integrity, not the encryption of passwords that might be contained within the log messages themselves.

C: This command ensures the integrity of the stored log file after it has been received and archived. It does not encrypt the real-time log transport channel.

1. FortiAnalyzer 7.4.1 CLI Reference

Page 111

config system global.

log-checksum {none | md5 | md5-auth}: The entry explicitly defines the md5-auth option as: "Use MD5 with an authentication code to create a checksum." This directly supports the correct answer.

2. FortiAnalyzer 7.4 Administration Guide

Page 160

"System Settings > Advanced > Log File Settings".

The guide explains the purpose of the log checksum feature is to "verify that the log files have not been altered." It details that selecting MD5-Auth requires an Authentication Code

confirming that both elements are part of the configuration.

FortiAnalyzer treats a FortiGate High Availability (HA) cluster as a single logical device. If the individual FortiGate units were added to FortiAnalyzer before being configured into an HA cluster, they will appear as separate devices. To correctly represent the cluster, an administrator must manually group these existing device entries on FortiAnalyzer. This is accomplished by selecting the relevant devices in the device list and using the "Group HA" function. This action consolidates their management and logging under a single cluster entity, ensuring proper reporting and analysis.

B: FortiAnalyzer primarily identifies individual cluster members by their unique serial number (devid) contained within the logs, not by the source IP address in the log message headers.

C: FortiAnalyzer handles HA failover automatically. When a new primary takes over, it begins sending logs, and FortiAnalyzer recognizes it as part of the cluster without requiring manual intervention.

D: FortiAnalyzer supports logging from FortiGate HA clusters in both active-passive and active-active modes. There is no requirement to limit the configuration to active-passive mode.

1. Fortinet FortiAnalyzer Administration Guide 7.4.1

"Adding a FortiGate HA cluster"

Page 51.

"If you have already added the FortiGate devices to the device list

you can group them together into an HA cluster. ... In the content pane

select the devices that you want to group into an HA cluster

then click Group HA in the toolbar." This directly supports option A.

"When a FortiGate HA cluster is added to FortiAnalyzer

FortiAnalyzer sees the HA cluster as a single device. ... If a failover occurs

the new primary FortiGate sends logs to FortiAnalyzer." This refutes option C.

2. Fortinet FortiOS Administration Guide 7.4.1

"Logging"

Page 671.

"FortiAnalyzer uses the device ID to identify the FortiGate." This supports the reasoning for why option B is incorrect

as the serial number (device ID) is the primary identifier.

3. Fortinet FortiOS Handbook - High Availability 7.4.0

"Active-active HA"

Page 31.

This section details the operation of active-active HA

including how traffic and logging are handled

with no mention of incompatibility with FortiAnalyzer

thus refuting the limitation suggested in option D.

When creating a remote administrator account on FortiAnalyzer that authenticates against an external server like LDAP or RADIUS, you have the option to set a local password. This local password serves as a fallback authentication mechanism. If the external authentication server becomes unavailable or unreachable for any reason, the administrator can still log in to the FortiAnalyzer using the username and this locally configured password, ensuring continued administrative access to the device.

B. This password authenticates FortiAnalyzer against the LDAP server. Incorrect. The credentials for FortiAnalyzer to bind to the LDAP server for queries are configured within the LDAP server profile settings, not in individual administrator accounts.

C. This password is set to comply with FortiAnalyzer password policy. Incorrect. While the password must adhere to the policy if set, the reason for its existence is for fallback access, not merely to satisfy a policy requirement.

D. This password is required because this is a restricted user. Incorrect. The fallback password option is available for all remote administrator accounts, regardless of their assigned access profile (restricted or superadmin).

1. FortiAnalyzer Administration Guide 7.4

Page 113

Section: "Creating administrators".

The guide states: "For remote users

you can optionally set a password. The password provides backup authentication in case the remote authentication server is unavailable. If you do not set a password

and the remote authentication server is unavailable

the user cannot log in." This directly supports the correct answer (A).

2. FortiAnalyzer Administration Guide 7.4

Page 120

Section: "LDAP".

This section details the configuration of the LDAP server connection itself

including the Username and Password for the bind type

which authenticates FortiAnalyzer to the LDAP server. This shows that option B is incorrect as those credentials are set elsewhere.

The best approach for a hard disk failure on a FortiAnalyzer with hardware RAID is to perform a hot swap. FortiAnalyzer models that support hardware RAID are designed for high availability, which includes the ability to replace a failed component, such as a hard disk, without powering down the unit. This process is known as hot-swapping. Once the failed disk is replaced with a new one, the RAID controller automatically initiates the rebuild process to restore the array's redundancy and health, minimizing system downtime and data unavailability.

A: A physically failed hard disk cannot self-recover. The purpose of RAID is to provide redundancy so the system can continue operating until the failed disk is replaced.

B: The execute format disk command is a destructive operation that erases all data on the disks. It is not used for recovering from a single disk failure in a RAID array.

D: Shutting down the FortiAnalyzer to replace the disk (a cold swap) is less efficient than a hot swap. It introduces unnecessary downtime, which hot-swapping is specifically designed to avoid.

1. FortiAnalyzer 7.4.1 Administration Guide

Page 231

Section: "RAID Management".

The guide states

"If a disk fails

the RAID becomes degraded. You must replace the failed disk to return the RAID to a healthy state. On devices that support hot swapping

you can replace the disk without shutting down the device." This directly supports the hot-swap procedure (Option C) as a standard and supported method.

2. FortiAnalyzer 7.4.1 Administration Guide

Page 231

Section: "RAID Management".

The document further explains

"After replacing the disk

the system automatically rebuilds the RAID." This confirms that manual formatting (Option B) is not required and contradicts the idea of self-recovery (Option A).

3. FortiAnalyzer 3700F QuickStart Guide

Page 6

Section: "Hot-Swappable Components".

This hardware-specific guide lists "Hard Drives" as hot-swappable components

explicitly confirming that the hardware is designed for replacement while the system is operational

making hot-swapping (Option C) the intended and best procedure over a shutdown (Option D).

A FortiAnalyzer system backup is designed to save the device's configuration and reporting structure, not the voluminous log data it collects. The backup file, typically a .conf file, contains the complete system configuration, which includes settings for administrators, registered devices, and system-level options. It also includes all report-related information, such as custom report layouts, report schedules, and output profiles. This allows an administrator to restore the operational state and reporting capabilities of the FortiAnalyzer unit without needing to back up the potentially massive log database.

A. Logs from registered devices: This is incorrect. The official documentation explicitly states that the system configuration backup does not include log files. Log backup is a separate, distinct process.

B. Database snapshot: This is incorrect. The system backup does not include a snapshot of the log database. It only backs up configuration data, not the analytical or log data itself.

1. FortiAnalyzer 7.4 Administration Guide

Page 61

"Backing up and restoring the configuration":

"You can back up the full configuration of your FortiAnalyzer system... The backup file includes the FortiAnalyzer system configuration and reports." This statement directly supports options C and D.

"The backup file does not include logs." This statement directly refutes option A.

2. FortiAnalyzer 7.4 Administration Guide

Page 31

"System Information widget > Backup":

"You can perform a system backup of the FortiAnalyzer configuration from the System Information widget. The backup file is a .conf file that contains the system configuration." This supports option D. The guide consistently refers to the backup as containing "system configuration".

According to the FortiAnalyzer Administration Guide, there are specific prerequisites for deleting an Administrative Domain (ADOM). Firstly, an ADOM cannot be deleted if it has any devices assigned to it. The devices must first be moved to a different ADOM. Secondly, the default root ADOM is a fundamental part of the FortiAnalyzer system and is protected from deletion to ensure the system remains operational. These two conditions are primary restrictions that must be met before an ADOM can be successfully removed from the system.

A. Logs must be purged or migrated before you can delete an ADOM.

This is incorrect. When an ADOM is deleted, the associated logs for that ADOM are automatically deleted along with it.

D. The status of the ADOMs must be unlocked.

While you cannot delete a locked ADOM, this is a temporary administrative state, not a fundamental prerequisite like the others. The primary rules concern device assignment and the ADOM's system role.

1. FortiAnalyzer Administration Guide 7.4

Page 101

"Deleting ADOMs".

"You cannot delete an ADOM that has devices assigned to it. You must move the devices to another ADOM before you can delete the ADOM." (Supports answer B).

"You cannot delete the root ADOM." (Supports answer C).

"When you delete an ADOM

the logs for the ADOM are also deleted." (Refutes option A).

2. FortiAnalyzer Administration Guide 7.4

Page 100

"Locking and unlocking an ADOM".

This section explains that locking an ADOM prevents configuration changes. Deleting an ADOM is a configuration change

so it would be blocked

but the explicit prerequisites for deletion are listed separately. (Context for refuting option D as a primary rule).