Fortinet FCP_FAZ_AD-7.4 Practice Questions

Summary
The log-checksum setting on a FortiAnalyzer is a critical feature for ensuring data integrity. When enabled, it instructs the FortiAnalyzer to calculate a cryptographic hash (in this case, using MD5) for log files it receives. This hash acts as a digital fingerprint, allowing the system to detect any corruption or tampering with the log data after it has been received and stored.

Correct Option

D. To verify the integrity of the log files received.
This is correct. The primary purpose of the set log-checksum command is integrity verification. By calculating and storing an MD5 hash for log files, the FortiAnalyzer can later re-calculate the hash of the same file and compare it to the stored value. If the hashes match, the log file is intact and has not been altered. If they differ, it indicates the file has been corrupted.

Incorrect Option

A. To record the hash value and authentication code of log files.
This is partially descriptive but misleading. The command does record a hash value (the MD5 checksum). However, it does not record an "authentication code" in the sense of a digital signature for source verification; it is purely for internal integrity checking after the logs have been received and stored.

B. To encrypt log transfer between FortiAnalyzer and other devices.
This is incorrect. The log-checksum command has no bearing on encryption during transmission. Log transfer encryption is handled by the protocol itself, such as the use of OFTP over TLS/SSL. The checksum is calculated on the log file after it has been received and is used for storage integrity, not transfer security.

C. To create the secure channel used by the OFTP process.
This is incorrect. The secure channel for OFTP (Over FortiAnalyzer Transfer Protocol) is established using SSL/TLS certificates and encryption protocols, which are configured under different system settings (e.g., set ssl-protocol, set oftp-ssl-protocol). The log-checksum is a separate feature that operates on the log files themselves, independent of the transport channel.

Reference
Fortinet Documentation Library: global (The CLI Reference for config system global lists the log-checksum option and its purpose).

Summary
Upgrading a High Availability (HA) cluster requires a specific procedure to maintain service availability and prevent a complete outage. The process is sequential, not simultaneous, to ensure one device remains operational to handle logs and management traffic while the other is being upgraded. The correct order of operations is critical for a successful, non-disruptive upgrade.

Correct Option

D. First, upgrade the secondary devices, and then upgrade the primary device.
This is correct. The standard procedure is to upgrade the secondary (subordinate) units first, one at a time. After a secondary unit reboots with the new firmware, it rejoins the cluster. Once all secondary units are successfully upgraded and the cluster is stable, you then manually fail over to a secondary unit and upgrade the original primary. This method ensures that a functioning unit is always available to serve as the active primary, minimizing service interruption.

Incorrect Option

A. You can perform the firmware upgrade using only a console connection.
This is incorrect. While a console connection can be used, it is not the only method and is often not the primary one. FortiAnalyzer firmware upgrades are typically performed through the web-based manager (GUI) by uploading the firmware image file. The CLI can also be used, but a direct console cable is not a strict requirement if network management access is available.

B. All FortiAnalyzer devices will be upgraded at the same time.
This is incorrect. Upgrading all cluster members simultaneously would cause a complete service outage, as all devices would reboot at once. The core principle of an HA upgrade is a rolling or sequential update, where devices are upgraded one after the other to preserve continuous operation.

C. Enabling uninterruptible-upgrade prevents normal operations from being interrupted during the upgrade.
This is misleading. The uninterruptible-upgrade feature helps automate the failover process during the upgrade of a single unit, but it does not prevent all interruption. When a unit is rebooting, there is a brief period of failover. The feature makes this failover smoother and more automatic, but "normal operations" are still technically interrupted for a brief moment during the switchover. The core service remains available, but the upgrade process itself involves managed interruptions for each device.

Reference
Fortinet Documentation Library: Upgrading a cluster

Summary
In FortiAnalyzer reporting, a Dataset is a fundamental building block that defines the specific log data to be analyzed. It acts as a database query, specifying the tables, fields, and filters used to select a subset of information from the vast amount of stored logs. All charts and layouts in a report are built upon the data retrieved by a dataset.

Correct Option

A. They determine what data is retrieved from the database.
This is correct. A dataset is essentially a structured query. It defines the source log tables (e.g., traffic, virus, webfilter), the specific fields to include, and any filters or conditions (e.g., time range, specific IP address) that must be met. When a report is run, the dataset executes this "query" against the SQL database to retrieve the precise set of records for the report to use.

Incorrect Option

B. They provide the layout used for reports.
This is incorrect. The layout is provided by the Report Template. The template determines the structure, formatting, and arrangement of elements (like charts, text, and logos) on the page. The dataset feeds the data into this pre-defined layout.

C. They are used to set the data included in templates.
This is incorrect and reverses the relationship. A Report Template contains or references one or more datasets. The dataset defines the data, and the template uses that dataset to populate its charts and tables. You do not use a dataset to configure a template; you configure a template to use specific datasets.

D. They define the chart types to be used in reports.
This is incorrect. The chart type (e.g., pie chart, bar graph, line chart) is defined within the Chart object itself when you are building a report widget. The dataset is the source of the data for that chart, but it does not dictate how that data will be visualized.

Reference
Fortinet Documentation Library: Datasets

Summary
When a managed device, like a FortiGate, is moved between ADOMs (Administrative Domains) on a FortiAnalyzer, the handling of its existing logs is a critical process. Analytics logs (used for reporting and FortiView) are stored in an SQL database, while archived logs (raw log files) are stored in the file system. Their migration is not instantaneous and requires a specific administrative action.

Correct Option

B. Archived logs will be moved to ADOM1 from the root ADOM automatically.
This is correct. Archived logs, which are the original, compressed log files, are automatically moved to the file system storage of the destination ADOM (ADOM1) when the device is moved. This process is handled by the system in the background.

D. Analytics logs will be moved to ADOM1 from the root ADOM after you rebuild the ADOM1 SQL database.
This is correct. Analytics logs are indexed in an SQL database specific to each ADOM. Simply moving the device does not transfer this SQL data. To make the historical analytics data available in the new ADOM, an administrator must manually initiate a "Rebuild" of the ADOM1 SQL database. This process migrates and re-indexes the analytics logs from the root ADOM into ADOM1's database.

Incorrect Option

A. Analytics logs will be moved to ADOM1 from the root ADOM automatically.
This is incorrect. The movement of analytics logs is not automatic. It requires the manual step of rebuilding the SQL database for the target ADOM (ADOM1). Without this step, the historical data will not appear in the reports and FortiView of the new ADOM.

C. Logs will be presented in both ADOMs immediately after the move.
This is incorrect. After the move, the device will only be associated with ADOM1. New logs will be processed there. The historical logs will no longer be visible in the root ADOM, and they will only become visible in ADOM1 after the SQL database rebuild is complete. They are not simultaneously present in both.

Reference
Fortinet Documentation Library: Moving a device to a different ADOM (This document outlines the process and explicitly states the need to rebuild the database for analytics logs).

Summary
A FortiAnalyzer system backup is designed to save the device's configuration and operational data to allow for restoration after a failure or for cloning to a new unit. It is crucial to understand that this backup is not a full archive of all collected logs, but rather a snapshot of the system itself, its settings, and the metadata required to manage logs and reports.

Correct Option

A. System information
This is correct. The system backup includes all core configuration settings of the FortiAnalyzer itself. This encompasses network settings, admin accounts and profiles, ADOM configurations, HA settings, system certificates, and other global parameters that define how the FortiAnalyzer operates.

C. Report information
This is correct. The backup contains the definitions and layouts for reports. This includes report templates, datasets, and scheduled report settings. However, it is important to note that it contains the report structure and queries, not the historical log data that populates them when run.

Incorrect Option

B. Logs from registered devices
This is incorrect. A standard system backup does not include the actual log data (analytics or archives) collected from registered FortiGate devices. The primary purpose of the backup is configuration recovery, not log retention. Logs must be protected and migrated using separate methods, such as log forwarding to another FortiAnalyzer or using the built-in log migration tools.

D. Database snapshot
This is incorrect. The system backup does not contain a full snapshot of the SQL database. The SQL database holds all the analytics and log data, which is a massive and constantly changing dataset. Including this in a configuration backup would be impractical. The backup may contain database schemas or metadata about the database structure, but not the actual log data within it.

Reference
Fortinet Documentation Library: Backup and Restore (This section details what is included in a configuration backup file).

Summary:
The exhibit displays an Event Handler listing 13 events (10 unique from the top summary and 3 distinct from the bottom list) with statuses Mitigated or Unmitigated, all tagged with "Malicious Code Detection by Endpoint" or similar. The playbook uses an On Demand starter, Get Events action via Local connector (LOCALHOST GET EVENTS), Attach Data to Incident connector with Match All Conditions selected, and a filter with Time Range but no specified Field, Match Criteria, or Value. This configuration retrieves all 13 events within the time range and attaches them to the created incident, as the absence of additional filter criteria means all available events match the "all conditions" logic (effectively no restrictive conditions).

Correct Option:

D. Thirteen events will be added.
The Event Handler shows 13 total events: 10 unique from the summary view (with counts like (2) indicating grouped but attachable instances) and 3 distinct in the detailed list, all within a recent time frame. With Match All Conditions selected but no explicit filter fields or values defined, the Get Events action fetches all events from the handler without restriction, and the Attach Data to Incident connector includes every matching event (all 13) in the incident for comprehensive logging and analysis.

Incorrect Option:

A. Ten events will be added.
This overlooks the 3 additional distinct events in the bottom detailed list (e.g., Internal intrusion MS-ISAPI), which are separate from the 10 summarized above. The playbook's lack of restrictive filters ensures all 13 are retrieved and attached, not just the top summary count; grouping in the UI does not limit attachment in playbook actions.

B. No events will be added.
The configuration explicitly uses Get Events from the Local connector tied to the Event Handler, which contains active events. Even with Match All Conditions, the empty filter (no Field/Value) acts as a universal match, ensuring events are fetched and attached; failure would require misconfiguration like invalid time range, which is not indicated here.

C. Five events will be added.
No basis for limiting to five exists in the exhibit; the handler lists 13 total, and the playbook's filter is non-restrictive. This might confuse the (2) counts in some event names as exclusions, but all instances are included in attachment, making five an arbitrary undercount.

Reference:
https://docs.fortinet.com/document/fortianalyzer/7.4.1/administration-guide/500000/creating-incidents

https://docs.fortinet.com/document/fortianalyzer/7.4.1/administration-guide/978383/playbooks

Summary
Log Insert Lag Time is a key performance metric in FortiAnalyzer that measures the efficiency of the internal log processing pipeline. It specifically tracks the delay between a log being accepted by the system and it being fully processed and indexed into the SQL database, making it available for searching, reporting, and analysis within FortiView.

Correct Option

C. The amount of time that passes between the time a log was received and when it was indexed on FortiAnalyzer.
This is correct. The process involves two main stages: first, the log is received and queued ("Receive Time"), and second, it is parsed, processed, and inserted into the SQL database ("Insert Time"). The Log Insert Lag Time is the difference between these two timestamps. A high lag time indicates the indexing engine is falling behind, often due to high log volume or system resource constraints.

Incorrect Option

A. The number of times in the logs where end users experienced slowness while accessing resources.
This is incorrect. This describes a performance issue experienced by users on the network, which might be recorded in application or traffic logs. Log Insert Lag is a metric internal to the FortiAnalyzer's performance, not a measure of user experience or network latency.

B. The amount of lag time that occurs when the administrator is rebuilding the ADOM database.
This is incorrect. Rebuilding an ADOM database is a separate, heavy administrative task. While it may cause high insert lag during the rebuild, "Log Insert Lag Time" is a continuous, real-time metric for normal operations, not a specific measure for the duration of a rebuild job.

D. The amount of time FortiAnalyzer takes to receive logs from a registered device.
This is incorrect. This describes network latency or transfer delay between the FortiGate and the FortiAnalyzer. The Log Insert Lag Time metric begins after the log has been successfully received by the FortiAnalyzer and is concerned with internal processing, not network transfer.

Reference
Fortinet Documentation Library: Performance Monitor (The official documentation on performance metrics covers the meaning of Insert Lag and other key indicators).