Free FCP_FAZ_AD-7.4 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

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).

The set log-checksum sha256 command configures the FortiAnalyzer to generate a hash value using the SHA-256 algorithm for each log file upon rolling (archiving). This hash value is then stored alongside the log file. The direct function enabled by this command is the creation and recording of this hash. While the ultimate purpose is to allow for integrity verification, the command itself only facilitates the recording step. The term "authentication code" is used loosely here; the primary function is recording the hash for integrity purposes.

B: The command configures a hashing algorithm (SHA-256) for integrity, not an encryption algorithm for confidentiality. Log transfer encryption is a separate feature.

C: The secure channel for the OFTP (OveR-the-wire FortiTelemetry Protocol) process is established using SSL/TLS encryption, which is unrelated to the checksum configuration for archived log files.

D: This describes the ultimate goal, but not the direct action of the command shown. The command enables the recording of the hash; the verification is a separate, subsequent step performed using a different diagnose command.

1. FortiAnalyzer Administration Guide 7.4.1

Log Security

p. 110.

"FortiAnalyzer can checksum log files to ensure that they have not been tampered with. When a log file is rolled

FortiAnalyzer calculates a checksum and stores it. You can later verify the log file against the checksum to confirm that the log file has not been changed." This quote shows that the process involves calculating and storing (recording) the checksum.

2. FortiAnalyzer CLI Reference 7.4.1

config system global

p. 113.

The description for set log-checksum is "Set the checksum algorithm for rolled logs." This confirms the command's role is to configure the algorithm for the checksumming process.

3. FortiAnalyzer CLI Reference 7.4.1

diagnose log checksum

p. 45.

The existence of the diagnose log checksum command demonstrates that verification is a distinct action from the configuration command shown in the question.

According to the official FortiAnalyzer documentation, for models that utilize software RAID, the recommended and required procedure for replacing a failed hard disk is to first power off the unit. This ensures the system's integrity and allows the software RAID controller to properly recognize the new disk upon reboot and initiate the rebuild process safely. Attempting to replace a disk while the system is running (hot-swapping) is not supported for software RAID configurations and is reserved for specific models equipped with hardware RAID controllers.

B: Downgrading and then upgrading the RAID level is not a standard or documented procedure for disk replacement. This action is unnecessarily complex and carries a high risk of data loss.

C: Clearing alarms before resolving the underlying physical fault is incorrect practice. Furthermore, replacing the disk while the FortiAnalyzer is running is not supported for software RAID.

D: A hot swap is the process of replacing a component while the system is operational. This capability is explicitly supported on FortiAnalyzer models with hardware RAID, not software RAID.

1. FortiAnalyzer Administration Guide 7.4.1

"System Settings" > "RAID Management" > "Replacing a failed disk".

The documentation states: "If a hard disk in the RAID array fails

you must replace it. For FortiAnalyzer models that support software RAID

you must power off the device before replacing the failed disk. For FortiAnalyzer models that support hardware RAID

you can hot-swap the failed disk without powering off the device." This directly confirms that shutting down is the correct procedure for software RAID.

To resolve IP addresses without impacting FortiAnalyzer's performance, the resolution task must be offloaded to the source FortiGate devices. By enabling IP resolution on each FortiGate, the device performs the DNS lookups and embeds the resulting hostnames directly into the log data before sending it to FortiAnalyzer. FortiAnalyzer then simply ingests and displays the already-resolved names, avoiding the resource-intensive process of performing thousands of DNS queries itself. This method directly satisfies the critical requirement of preventing any additional performance load on the FortiAnalyzer.

A: Resolving on a per-ADOM basis still consumes FortiAnalyzer CPU and memory for DNS lookups, thereby impacting its performance, which the question explicitly forbids.

B: This command enables IP resolution on the FortiAnalyzer for FortiView, which is the direct cause of the performance impact that needs to be avoided.

C: Configuring local DNS servers is a prerequisite for resolution by FortiAnalyzer, but the resolution process itself still consumes FortiAnalyzer resources and causes a performance hit.

1. FortiAnalyzer Administration Guide 7.4.1

Page 211

Section: "System Settings > Advanced > Display Options". The guide notes for the "Resolve unknown IPs using DNS lookup" setting: "Enabling this option may impact system performance." This confirms that resolution on FortiAnalyzer has a performance cost.

2. FortiAnalyzer Administration Guide 7.4.1

Page 101

Section: "Device Manager > Performance > Log Insert Lag Time". The guide states: "To improve FortiAnalyzer performance

you can configure FortiGate to resolve IP addresses in logs. This can reduce the load on FortiAnalyzer." This directly supports offloading the task to FortiGate.

3. FortiOS CLI Reference 7.4.1

Page 1381

Command: config log fortianalyzer setting. The set resolve-ip {enable | disable} option is described as enabling/disabling resolving IP addresses to hostnames in logs sent to FortiAnalyzer

confirming this capability exists on the FortiGate.

The accuracy of a FortiAnalyzer report depends entirely on the availability of the underlying log data in its database. Two primary system-level reasons can cause expected information to be missing.

First, the logfiled service must process and index incoming raw logs before they can be queried by the reporting engine. If this indexing process is delayed or has not completed for the relevant time period, the data will not be present in the database and, consequently, will be absent from the report.

Second, FortiAnalyzer's data retention policy dictates how long logs are stored. If the logs for the report's time frame have been purged due to exceeding the configured age limit or because the disk space threshold was reached, the data is permanently gone and cannot be included.

A. You enabled auto-cache with extended log filtering.

This is a standard feature for performance optimization. It does not inherently cause data loss unless the filter itself is misconfigured to exclude the expected data.

D. The time frame selected in the report is wrong.

While a common user error, this option points to a configuration mistake. Options B and C describe fundamental system states where the log data itself is unavailable for reporting.

1. FortiAnalyzer Administration Guide 7.4.1

Page 250

"Troubleshooting reports": This section explicitly lists potential causes for empty or incomplete reports

including "The logs were deleted from FortiAnalyzer" (supporting option C) and "The log database is not rebuilt completely" (supporting the concept of option B

where indexing is incomplete).

2. FortiAnalyzer Administration Guide 7.4.1

Page 11

"FortiAnalyzer workflow": This section describes the fundamental process: "Logs are collected from the network devices and indexed in the SQL database." This highlights that if indexing (Option B) has not occurred

the data is not available for reporting.

3. FortiAnalyzer Administration Guide 7.4.1

Page 208

"Configuring log storage policy": This section details the data retention mechanisms

explaining that logs are deleted when the allocated disk space is nearly full or when they are older than the specified time. This directly supports option C as a reason for missing data.

The Initializing status on the RAID management page indicates that the FortiAnalyzer is performing the initial setup of a newly created RAID array. For redundant RAID levels (such as RAID 5, 6, 50, or 60), this process involves writing parity data across all the member disks. This initial write operation is essential to establish the array's fault tolerance, allowing it to withstand a drive failure without data loss. This is a one-time process for a new array and can be time-consuming depending on the disk size.

A: This describes a RAID consistency check or "scrubbing," which verifies existing parity data, rather than creating it for the first time. The status for this is typically Verifying.

B: This describes a RAID rebuild process, which occurs after a failed drive is replaced. The status for this is Rebuilding or Degraded during the process.

D: Initializing is a transitional state during which the array is being prepared. The normal, fully functional state is Optimal or Good.

1. FortiAnalyzer 7.4.0 Administration Guide

Page 310

Section: "RAID Management"

The guide states

"After you create a RAID array

the system needs to initialize the array. This process can take a long time

depending on the size of the hard disks." It further explains that for RAID 5

this involves creating parity blocks

which is the mechanism for fault tolerance.

2. FortiAnalyzer 7.4.0 CLI Reference

Page 671

Command: diagnose system raid status

The output of this command shows various states of the RAID array. While it doesn't explicitly define "Initializing" in a glossary

the context of RAID creation commands (execute raid ...) implies that initialization is the step following creation to bring the array to an Optimal state. The process described in the Administration Guide aligns with option C.

The most direct and common reason for receiving only a subset of expected logs from a FortiGate is an incomplete logging configuration on the FortiGate itself. FortiOS provides granular control over logging. An administrator must explicitly enable logging for individual firewall policies, security profiles (such as Antivirus, Web Filter, and IPS), and various system events. If logging is enabled for some policies or events but not others, FortiAnalyzer will only receive the logs that were configured to be sent, resulting in a partial log set.

A. FortiGate was added to the wrong ADOM type. An incorrect ADOM type primarily affects management capabilities and the availability of specific features in the FortiAnalyzer GUI, not the fundamental transport of logs from the FortiGate.

B. This FortiGate model is not fully supported. If a model were unsupported, it would likely fail to register correctly or send any logs at all, rather than sending only some logs.

D. This FortiGate is part of an HA cluster but it is the secondary device. While a secondary HA unit only sends its own system logs and not traffic logs, the question implies an expectation of logs from traffic flow. The root cause for missing expected traffic logs from the cluster as a whole would still be a configuration issue on the primary unit (Option C).

1. FortiOS 7.4 Administration Guide: In the "Firewall policies" section

it is detailed that for each policy

an administrator must enable the "Log Violation Traffic" option to record logs for traffic handled by that policy. This demonstrates the need for explicit configuration. (Reference: FortiOS Administration Guide 7.4

Chapter: "Firewall"

Section: "Firewall policies").

2. FortiAnalyzer 7.4.2 Administration Guide: The troubleshooting section lists "The logging device is not configured to send logs to the FortiAnalyzer unit" as a primary reason for not receiving logs. This directly supports the idea that the source device's configuration is a critical factor. (Reference: FortiAnalyzer Administration Guide 7.4.2

Chapter: "Troubleshooting"

Section: "Logs are not being received from a registered device").

3. FortiOS 7.4 High Availability Guide: The "HA logging" section explains that in an active-passive cluster

the primary unit is responsible for sending traffic logs. The secondary unit only sends logs about its own operation. This confirms that a configuration issue on the primary unit (Option C) would be the reason for missing traffic logs from the cluster. (Reference: FortiOS High Availability Guide 7.4

Chapter: "Introduction to HA"

Section: "HA logging").

The provided log exhibit explicitly states that an "Insecure SSL Connection blocked from 10.0.3.20". Furthermore, the Event Status is listed as "Mitigated". In the context of security event management, "mitigated" signifies that a corrective action has been successfully applied to neutralize a detected threat. In this case, the action was to block the connection, thus preventing the potential risk. The combination of these two details confirms that the security risk was handled and is no longer active.

B: The "Mitigated" status directly contradicts the idea that the risk is "open". An open risk would still require attention and would not be considered mitigated.

C: The log shows a single, low-severity, automatically handled event. There is no information to suggest it was escalated to a formal incident, which is a more significant occurrence.

D: The log indicates a specific connection was blocked. It does not provide evidence that the source host (10.0.3.20) itself was quarantined or isolated from the network.

NIST Special Publication 800-61 Rev. 2, Computer Security Incident Handling Guide: This guide distinguishes between events, adverse events, and incidents. The log shows a mitigated adverse event. Section 3.4, "Incident Response Life Cycle," discusses containment, eradication, and recovery, where mitigation actions like blocking traffic are primary steps. The "Mitigated" status indicates this process was successful for this specific event.

Cisco, Firepower Management Center Configuration Guide: In the context of intrusion and security events, Cisco documentation describes event statuses. An action such as "block" results in the threat being stopped. When a system successfully blocks a threat as per its policy, the event can be considered mitigated, as the immediate danger has been averted.

Palo Alto Networks, PAN-OS® Administrator’s Guide: Threat logs in PAN-OS detail the action taken against a threat (e.g., 'alert', 'drop', 'reset-both'). The "blocked" description in the exhibit is analogous to a 'drop' action, confirming the firewall actively prevented the connection. This preventative action is a form of risk mitigation.

The Security Operations “Threat Hunting” workspace in FortiAnalyzer 7.4 is explicitly described by Fortinet as “a proactive approach to detecting threats that have evaded existing security controls.” It lets analysts create hypotheses, pivot through log data, and uncover dormant or lateral-movement attacks before they cause harm—thereby enabling proactive network-security management.

A. Incidents dashboards – Summarizes already-detected incidents; reactive after detection, not a proactive search capability.

C. FortiView Monitor – Provides real-time traffic/log visibility but waits for events to occur; chiefly reactive monitoring.

D. Outbreak alert services – Supplies external threat notifications and IOC packages, but analysts must still correlate; not the built-in proactive hunting workflow emphasized by Fortinet documentation.

1. Fortinet. “FortiAnalyzer 7.4.0 Administration Guide

” Section ‘Threat Hunting’

pp. 369-372: “Threat hunting is a proactive

analyst-driven process for identifying hidden threats in your environment.”

2. Fortinet. NSE 5 FortiAnalyzer 7.4 Courseware

Module 4 ‘Security Operations’

slide 28: “Threat Hunting: Provides a proactive methodology… enables analysts to search for threats before alerts are raised.”

3. Fortinet. “FortiAnalyzer 7.4 New Features Guide

” PDF ID FAZ-7.4-NF-2023

p. 11: “The new Threat Hunting workspace empowers security teams with a proactive approach.”

In FortiAnalyzer's playbook execution model, the overall status of a playbook is contingent on the successful completion of all its constituent tasks. If any single task within the workflow fails, the entire playbook execution is considered to have failed. This is because the automated process did not complete its intended sequence of actions successfully. Therefore, even with four out of five tasks succeeding, the single failure causes the final playbook status to be marked as "Failed".

A. Success: This status is incorrect because a playbook is only marked as "Success" if all of its tasks complete without any failures.

C. Running: This is an intermediate status indicating that the playbook is still in the process of executing. The scenario describes a completed execution, not an ongoing one.

D. Upstreamfailed: This is a status for an individual task, not the entire playbook. It signifies that a task was skipped because a preceding task it depended on had failed.

1. FortiSOAR Documentation (Playbook Engine): The logic for playbook execution status is inherited from FortiSOAR. The documentation clarifies playbook states. The "Failed" status is explicitly defined: "A playbook is marked as Failed if any of its steps fail to execute."

Source: FortiSOAR > Playbooks > The Playbook Engine > Playbook Execution. (This principle is fundamental to the FortiSOAR engine integrated into FortiAnalyzer).

2. FortiAnalyzer 7.4.0 Administration Guide: The guide describes monitoring playbook execution and shows the possible statuses. A playbook run that contains a failed task will show a "Failed" status in the execution log.

Source: FortiAnalyzer 7.4.0 Administration Guide

Page 519

"Monitoring playbook execution". The section illustrates that a non-successful completion results in a "Failed" status for the playbook run.

A dataset in FortiAnalyzer is fundamentally a structured SQL query that retrieves specific information from the FortiAnalyzer database. Its primary purpose is to define what data is fetched for use in reports. When creating custom reports, administrators build or use pre-defined datasets to query for the exact log data needed, such as top applications by bandwidth or failed authentication attempts. This retrieved data is then used by charts and macros to generate the visual and tabular elements of a report.

B: The visual presentation, structure, and branding of a report, such as the cover page, headers, and footers, are controlled by report layouts, not datasets.

C: This is an indirect and less precise description. While datasets provide the data for charts within templates, their core function is the retrieval of data (the query), not the setting of data in a template.

D: Chart definitions determine the visualization type (e.g., pie, bar, table) and which dataset to use for data, but the dataset itself does not define the chart's appearance.

1. FortiAnalyzer Administration Guide 7.4

Page 278

Section: "Reports > Charts

datasets

and macros > Datasets".

The guide states: "Datasets are SQL queries that retrieve specific information from the FortiAnalyzer database. You can create custom datasets to query the database for specific information that you want to include in a report." This directly supports that datasets determine what data is retrieved.

2. FortiAnalyzer Administration Guide 7.4

Page 278

Section: "Reports > Report templates

layouts

and settings > Layouts".

The guide explains: "Layouts are used to customize the look of your reports

including the report cover page

header

and footer." This differentiates layouts (Option B) from datasets.

3. FortiAnalyzer Administration Guide 7.4

Page 278

Section: "Reports > Charts

datasets

and macros > Charts".

The guide notes: "Charts are used to graphically represent the data that is collected by FortiAnalyzer... When you create a chart

you can specify the chart title

the dataset

the type of chart..." This confirms that charts define the visualization type (Option D) and use datasets for their data.