FCP_FAZ_AD-7-4 Practice Questions

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 FortiGuard Outbreak Detection Service is a subscription-based feature for FortiAnalyzer that enhances threat detection. It requires an additional license to operate. The service functions by automatically receiving threat intelligence packages from FortiGuard Labs when a new threat is discovered. These packages contain updated components, such as event handlers and reports, which FortiAnalyzer then uses to scan its logs for evidence of the newly identified threat. This mechanism allows for the retroactive discovery of threats that may have gone unnoticed before they were identified by FortiGuard.

A: Alerts are generated and displayed on the FortiAnalyzer dashboard and in FortiView. While email notifications can be configured for alerts, it is not the primary or guaranteed delivery method for the service itself.

B: The Outbreak Detection summary widget is available on the root ADOM's dashboard, but the specific threat alerts are visible in the FortiView of the ADOM where the threat was actually detected.

1. FortiAnalyzer 7.4.2 Administration Guide

Page 310

Section: "Outbreak Detection"

"The FortiGuard Outbreak Detection Service is a subscription-based service." (Supports Answer C)

"When a new threat is discovered

FortiGuard Labs creates a package that includes an updated event handler and report. The package is then pushed to FortiAnalyzer devices that have the Outbreak Detection Service enabled. The package is automatically downloaded and used to scan the logs for the new threat." (Supports Answer D)

2. FortiAnalyzer 7.4.2 Administration Guide

Page 311

Section: "Outbreak Alert"

"When a threat is detected

an alert is generated and displayed on the Dashboard and FortiView > Threats pages." (Contradicts A as the primary method)

"The Outbreak Detection summary widget is available on the dashboard for the root ADOM." (Contradicts B

as this refers to the summary widget

not all alerts

which appear in relevant ADOMs' FortiView).

The goal is to create a filter for FortiAnalyzer's own event logs that shows login attempts from a specific source IP (Laptop1: 10.1.1.100) for any user except 'admin'.

In FortiAnalyzer event logs, administrative access details are captured in specific fields. The performedon field is used to identify the management interface (GUI) and the source IP address of the connecting device. Therefore, performedon=="GUI(10.1.1.100)" correctly filters for web connections originating from Laptop1. The condition user!=admin correctly excludes the 'admin' user. The operation-login term filters for the login action. Option A correctly combines all these required elements.

B: This option is incorrect because it filters for the user 'admin' (user==admin) instead of excluding them. It also uses srcip and dstip, which are fields for traffic logs, not FortiAnalyzer's own event logs.

C: This option is incorrect because it lacks a filter for the source IP address of Laptop1 (10.1.1.100), so it would match logins from any source.

D: This option is incorrect because it uses the FortiAnalyzer's own IP address (10.1.1.210) as the source of the connection within the performedon field, which is factually wrong.

1. FortiAnalyzer 7.4.0 Log Message Reference

Page 21

logid="0100032002" (Admin login). This reference details the fields for an administrator login event.

ui field: "Name of the user interface

such as GUI(192.168.1.1)

ssh(192.168.1.1)

or console." This confirms that the source IP of the management station is included in this field

validating the format GUI() used in the question's filter.

user field: "Administrator name." This confirms user is the correct field for filtering by username.

action field: "Action performed by the administrator." This would include login

which corresponds to the operation-login filter term.

2. FortiAnalyzer 7.4.0 Administration Guide

Page 158

"Filtering logs". This section describes the use of the filter box in the Log View to create custom filters based on log field values

such as user

ui

and action. The logic field==value and field!=value is explained

supporting the syntax used in the question.

The set log checksum command enables a feature that calculates and records a checksum for each log file. The fundamental purpose of this is to ensure log integrity. This allows an administrator to verify that a log file has not been altered or tampered with after its creation, which is a critical security function (B).

This integrity verification mechanism also serves as a protective measure during log transfers. When logs are uploaded to a remote server, such as via SFTP, a man-in-the-middle attack could potentially modify the data in transit. By comparing the checksum of the received file against the original checksum logged by FortiAnalyzer, any unauthorized modification can be detected, thus helping to protect against such attacks (A).

C: Checksums provide data integrity, not confidentiality. Encryption is the technology used to make log communications unreadable.

D: Sending logs to a second logging server is a feature known as log forwarding, which is configured using separate commands and settings.

1. FortiAnalyzer Administration Guide 7.4.1

Page 110

"Log Security" section.

Quote: "FortiAnalyzer also supports log file checksums. When enabled

FortiAnalyzer calculates a checksum for each log file and logs the checksum value. You can use the checksum to verify log file integrity." This supports option B directly. The verification of integrity after a download or transfer implicitly protects against in-transit modification

supporting option A.

2. FortiAnalyzer CLI Reference 7.4.1

Page 261

config system log-setting.

Reference: The command set log-checksum {enable | disable} is documented here with the description "Enable/disable logging all log checksums." This confirms the command's existence and its role in enabling the checksum feature for logs.

3. FortiAnalyzer 7.4 Study Guide

Page 21

"Log Security".

Quote: "FortiAnalyzer also supports log file checksums. When enabled

FortiAnalyzer calculates a checksum for each log file and logs the checksum value. You can use the checksum to verify log file integrity." This reinforces that the core purpose is integrity verification (B)

which is the basis for detecting tampering from any source

including a MitM attack (A).

In FortiAnalyzer RAID management, a Degraded status specifically indicates that the RAID array has lost one or more of its member hard drives. Despite the loss of a drive, the array remains operational, albeit without its full redundancy. The system can continue to handle read and write requests by using the remaining drives and parity data (for RAID levels like 5 or 6). This state is a critical alert that the array's fault tolerance is compromised and requires immediate attention, typically by replacing the failed drive.

A: This description corresponds to the Inactive status, where a drive is explicitly taken offline and is no longer part of the RAID volume.

C: This describes the Rebuilding status, which is the process of restoring data to a new replacement drive to return the array to an Optimal state.

D: While invalid parity data is a critical error, the Degraded status is specifically triggered by a missing or failed drive, not by a parity data validity check.

1. FortiAnalyzer Administration Guide 7.4.2

Page 21

System Information widget > RAID Status. The guide explicitly defines the RAID statuses:

Degraded: "One or more drives are missing from the FortiAnalyzer unit."

Rebuilding: "The device is writing data to the disk to restore the volume to an optimal state."

Inactive: "The hard drive is no longer being used by the RAID controller."

Fabric authorization is a process where an administrator explicitly approves a FortiGate's request to connect to FortiAnalyzer. To perform this action, the administrator must first log in to the FortiAnalyzer's graphical user interface (GUI). This login requires a valid username and password, which are the FortiAnalyzer credentials. Once authenticated, the administrator can navigate to the Device Manager, locate the unauthorized FortiGate, and authorize it. Therefore, possessing valid FortiAnalyzer credentials is a fundamental prerequisite to perform the authorization.

A. A FortiGate ADOM: An ADOM is the administrative domain where a device is placed after it has been successfully authorized, not a requirement for the authorization action itself.

B. The FortiGate serial number: The FortiGate automatically sends its serial number to the FortiAnalyzer for identification. The administrator uses this to identify the device but does not provide it as a credential to authorize.

C. A pre-shared key: A pre-shared key is used for a different, manual method of adding a device and is not part of the standard Security Fabric discovery and authorization workflow.

1. FortiAnalyzer Administration Guide 7.4.0

Page 100

Section: "Authorizing devices". This section details the procedure for authorizing a device from the Unauthorized Devices list within the Device Manager. The entire process is performed by an administrator logged into the FortiAnalyzer GUI

which inherently requires valid credentials.

2. FortiAnalyzer Administration Guide 7.4.0

Page 99

Section: "Adding devices". This section outlines that when a device is configured to send logs

it appears in the Unauthorized Devices list

and "You can then authorize the device". This "You" refers to the authenticated administrator operating the FortiAnalyzer.

The output from the diagnose log test command provides a clear status of the logging connection from the FortiGate. The line FortiAnalyzer (10.0.1.251:514): status: unavailable explicitly states that the FortiAnalyzer is not reachable. This is further confirmed by Last status: conn-failed, indicating the last connection attempt failed. Concurrently, the output shows Total logs generated: 1 and Total logs cached: 1, which demonstrates that the FortiGate has produced and is holding at least one log message in its queue, ready to be sent. Therefore, the most accurate conclusion is that the FortiGate has logs to transmit, but it cannot due to the FortiAnalyzer being unavailable.

A. The connection between FortiGate and FortiAnalyzer is overloaded.

The status is unavailable and conn-failed, which signifies a connection failure, not an overload. A queue size of one does not indicate an overloaded state.

C. FortiGate is configured to send logs in batches.

The command output does not provide information about the log transmission mode (real-time vs. batch). Logs are queued because the destination is unreachable, not because of a batch configuration.

D. FortiGate is sending logs again after it performed a reboot.

There is no information within the provided output to suggest that the FortiGate has recently been rebooted. The log generation and caching are normal operational behaviors.

1. FortiAnalyzer Administration Guide 7.4.1

Page 278

"Troubleshooting tips" > "Logs are not being received from a FortiGate device". The guide recommends using the diagnose log test command on the FortiGate to verify connectivity. It states that if the status is unavailable

you should check the network connectivity between the devices.

2. FortiOS CLI Reference 7.4.2

Page 1088

diagnose log test. The documentation defines the output fields:

status: unavailable: The remote logging device is unavailable.

Last status: conn-failed: The last connection attempt failed.

Total logs cached: The number of logs cached on the device

waiting to be sent.

This directly supports the conclusion that logs are cached because the connection to the unavailable FortiAnalyzer has failed.

In FortiAnalyzer, logs are categorized into two primary types for storage: Analytics logs and Archive logs. Analytics logs are indexed in an SQL database for fast querying and reporting, and are often referred to as "online logs". In contrast, Archive logs are the original raw logs stored in a compressed format for long-term retention and compliance. These compressed, non-indexed logs are officially referred to as "offline logs". They are not immediately available for analysis and must be restored to the analytics database if needed for reporting.

B: This option describes analytic logs, also known as online logs, which are indexed and stored in the SQL database for active analysis, the direct opposite of offline logs.

C: This describes a log collection scenario from a device that was temporarily disconnected. While these logs are collected, the term "offline logs" refers to a storage state on FortiAnalyzer, not the status of the source device.

D: Real-time logs that are not yet indexed are in the ingestion and processing queue. This is a transient state before logs are written to either the analytic (online) or archive (offline) storage.

1. FortiAnalyzer 7.4 Administration Guide

"Log View and Log Quota management" section. It states: "Analytics logs are also called online logs

and Archive logs are also called offline logs."

2. FortiAnalyzer 7.4 Administration Guide

"Data management" section. It clarifies: "FortiAnalyzer stores two types of logs: Analytics logs (online) and Archive logs (offline). Analytics logs are indexed in the SQL database... Archive logs are compressed raw logs."

3. FortiAnalyzer 7.4 Administration Guide

"Log Storage" section. This section details the distinction: "FortiAnalyzer saves Analytics logs in a structured SQL database... It saves Archive logs as compressed flat files." This confirms that offline (archive) logs are compressed.

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

The disk quota for an Administrative Domain (ADOM) on a FortiAnalyzer represents the total, shared amount of disk space allocated for storing logs from all devices managed within that specific ADOM. When multiple devices are grouped into an ADOM, their logs collectively consume space from this single, pre-configured quota. The System Settings > Storage Info pane displays this total allocated space for the ADOM and how much of it has been used by the combined logs of all its member devices.

A: The quota is a shared pool for the entire ADOM, not a separate limit applied to each individual device within the ADOM.

B: This describes the total physical or virtual disk capacity of the FortiAnalyzer appliance itself, from which individual ADOM quotas are carved out.

C: The quota is configured for a specific ADOM instance, not determined by a generic "ADOM type" (e.g., FortiGate ADOM).

1. FortiAnalyzer Administration Guide 7.4.1

Page 101

"Configuring ADOMs" section: "You can configure the maximum disk space to be used by the devices in the ADOM. The disk quota is the amount of disk space that the ADOM can use." This confirms the quota is for the ADOM as a whole

encompassing all its devices.

2. FortiAnalyzer Administration Guide 7.4.1

Page 103

"System Settings > All ADOMs" section: The table shows a "Disk Quota (MB)" column for each ADOM

reinforcing that the quota is an attribute of the ADOM itself.

3. FortiAnalyzer CLI Reference 7.4.1

Page 198

config system adom command: The set disk-quota parameter is defined as "Disk quota for this ADOM in MBs (0 means no limit)." This shows the quota is a singular setting for the entire ADOM.