Fortinet FCP_FAZ_AD-7.4 Practice Questions

Summary
On FortiAnalyzer, logs are processed and stored in two primary formats to balance performance and long-term retention. "Offline logs" refer to the long-term storage format where logs are compressed and archived in their original binary form. These are distinct from the logs that are actively indexed for immediate analysis and reporting.

Correct Option

A. Compressed logs, also known as archive logs
This is correct. Offline logs are synonymous with archive logs. After logs are received and indexed into the SQL database for analytics, they are compressed and moved to long-term storage in the file system. These archived/offline logs are not immediately searchable through the GUI but are retained for compliance, forensic purposes, and can be restored to the database if needed for historical analysis.

Incorrect Option

B. Logs that are indexed and stored in the SQL database
This is incorrect. Logs that are indexed and stored in the SQL database are referred to as Analytics logs or online logs. These are the logs used for FortiView, reports, and charts. Offline logs are the compressed version of these, stored after the indexing process is complete.

C. Any logs collected from offline devices after they boot up
This is incorrect. This describes a different scenario known as log buffering and forwarding. When a FortiGate device cannot connect to the FortiAnalyzer, it may buffer logs locally and forward them once the connection is restored. These logs, once received, are processed normally into analytics and archive logs; they are not defined by the term "offline logs."

D. Real-time logs that are not yet indexed
This is incorrect. Logs that have been received but are waiting to be processed and inserted into the SQL database reside in a queue. They are often referred to as "logs in the insert buffer" or unindexed logs. Once indexed, they become analytics logs, and later they are compressed into offline/archive logs.

Reference
Fortinet Documentation Library: Log storage and archiving (This section explains the lifecycle of logs, including the distinction between analytics and archive/offline logs).

Summary
FortiAnalyzer processes logs in two primary stages to optimize for both real-time analysis and long-term storage. Analytics logs represent the processed and indexed data that is immediately available for interactive queries, reporting, and visualizations. They are the "working set" of logs that power the FortiAnalyzer's analytical features.

Correct Option

C. Logs that are indexed and stored in the SQL.
This is correct. Analytics logs are the logs that have been parsed, processed, and inserted into the FortiAnalyzer's SQL database. This indexing is what makes them searchable and allows for the fast generation of charts, reports, and the data displayed in FortiView widgets. They are the foundation for all analytical operations on the platform.

Incorrect Option

A. Log type Traffic logs.
This is incorrect. "Traffic logs" is a specific category or type of log content generated by a FortiGate. Both analytics logs and archive logs can contain traffic log data. "Analytics logs" refers to the state of the log (indexed in SQL), not its content type (e.g., traffic, threat, webfilter).

B. Logs that roll over when the log file reaches a specific size.
This is incorrect. This behavior describes raw log file management, which is characteristic of archive logs (also called offline logs). Analytics logs are stored in a structured SQL database, not in individual files that roll over based on size.

D. Raw logs that are compressed and saved to a log file.
This is incorrect. This is the exact definition of archive logs or offline logs. Analytics logs are the opposite; they are the uncompressed, parsed, and indexed version of the raw logs, stored in a database for quick access, not compressed in files.

Reference
Fortinet Documentation Library: Log storage and archiving (This document explains the difference between analytics logs (in the database) and archive logs (compressed files)).

Summary
FortiAnalyzer uses Administrative Domains (ADOMs) to logically separate the management and data of different departments or customers. To limit an administrator's scope, you must explicitly grant them permissions only to the specific ADOMs they are authorized to manage. This is a fundamental access control mechanism within the FortiAnalyzer user management system.

Correct Option

B. Assign the ADOMs to the administrator’s account
This is correct. When creating or editing a local administrator account, there is a specific section to define ADOM permissions. You can select individual ADOMs from a list and assign a role/profile (like Read Only, Read Write, or custom profiles) for each one. An administrator will only see and have access to the ADOMs that have been explicitly assigned to their account.

Incorrect Option

A. Set the ADOM mode to Advanced
This is incorrect. The ADOM mode (Normal vs. Advanced) determines whether devices can be shared between ADOMs. It is a global setting that affects ADOM behavior, not a tool for restricting an individual administrator's access to a subset of ADOMs.

C. Configure trusted hosts
This is incorrect. Trusted hosts restrict where an administrator can log in from (based on source IP address), not what they can access (which ADOMs) after they have successfully authenticated.

D. Assign the default Super_User administrator profile
This is incorrect. Assigning the Super_User profile grants an administrator full permissions across all ADOMs and the global system settings. This is the opposite of restricting access to a subset; it provides unlimited access.

Reference
Fortinet Documentation Library: Administrators (This section details how to create an administrator and assign specific ADOM permissions to their account).

Summary
FortiAnalyzer supports multiple authentication methods to verify administrator logins, providing flexibility for integrating with existing enterprise security systems. Beyond local user accounts, it can leverage industry-standard remote authentication servers to centralize credential management and enforce stronger security policies like multi-factor authentication.

Correct Option

A. RADIUS
This is correct. RADIUS (Remote Authentication Dial-In User Service) is a widely supported networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management. FortiAnalyzer can be configured as a RADIUS client to forward administrator login requests to a RADIUS server for validation.

C. LDAP
This is correct. LDAP (Lightweight Directory Access Protocol) is used to communicate with directory services like Microsoft Active Directory. FortiAnalyzer can authenticate administrators by binding to an LDAP server, allowing organizations to use their existing domain user accounts and groups for access control.

E. TACACS+
This is correct. TACACS+ (Terminal Access Controller Access-Control System Plus) is another AAA protocol, often used specifically for network device administration. FortiAnalyzer supports TACACS+ as a remote authentication method, which can provide more detailed authorization control and accounting logs compared to RADIUS.

Incorrect Option

B. Local
This is incorrect. "Local" refers to user accounts and passwords that are stored directly on the FortiAnalyzer's internal database. This is not a remote authentication server; it is the default, built-in authentication method. The question specifically asks for remote authentication servers.

D. PKI
This is incorrect. PKI (Public Key Infrastructure) is used for certificate-based authentication, often for IPsec or SSL-VPNs. While FortiAnalyzer uses certificates for securing communication channels (e.g., OFTP), it does not use administrator PKI certificates as a method for logging into the web-based manager or CLI as a remote authentication server type. Administrator authentication is handled by Local, RADIUS, LDAP, and TACACS+.

Reference
Fortinet Documentation Library: Remote authentication servers (This section details the configuration of RADIUS, LDAP, and TACACS+ servers for administrator authentication).

Summary
FortiAnalyzer devices that support hardware RAID (typically RAID 1) are designed for fault tolerance. If a hard disk fails, the system can continue operating using the remaining good disk(s) without interruption. The correct procedure leverages this capability by allowing the administrator to replace the faulty component while the system is still running, minimizing downtime.

Correct Option

C. Perform a hot swap of the disk.
This is correct. For a FortiAnalyzer with supported hardware RAID, the best practice is to perform a hot swap. This means identifying the failed disk (often indicated by an LED), physically removing it from the bay while the unit is powered on, and inserting a new, compatible disk. The hardware RAID controller will automatically begin rebuilding the data from the healthy disk onto the new one, all without requiring a system shutdown.

Incorrect Option

A. There is no need to do anything because the disk will self-recover.
This is incorrect. A physically failed disk cannot repair itself. While the RAID array will maintain operations, the failed disk must be replaced to restore fault tolerance. Leaving a failed disk in place leaves the system vulnerable; if the remaining good disk fails, data loss and system outage will occur.

B. Run execute format disk to format and restart the FortiAnalyzer device.
This is incorrect and dangerous. The execute format command is used for initial setup or major troubleshooting and will erase all data on the specified disk. Running this command on a working disk in a degraded RAID array would destroy the only remaining copy of the data, resulting in a complete data loss.

D. Shut down FortiAnalyzer and replace the disk.
This is not the best approach for a device that supports hot-swapping. Shutting down the FortiAnalyzer causes unnecessary service interruption for all log collection and reporting. The hot-swap capability is specifically designed to avoid this downtime, making a shutdown an outdated and disruptive procedure when a hot swap is available.

Reference
Fortinet Documentation Library: Replacing a failed hard disk (This guide outlines the hot-swap procedure for replacing a failed disk in a supported appliance).

Summary
The goal is to filter FortiAnalyzer's own system logs (operation logs) for specific login events. The filter must identify login events (operation=login) that originated from the specific administrative workstation (srcip=Laptop1's IP) and were performed by any user who is not the default "admin" account. This is a common audit requirement to monitor for privileged access from non-standard accounts.

Correct Option

A. operation=login & dstip==10.1.1.210 & user!=admin
This is correct. This filter accurately combines all the required conditions:

operation=login:
Isolates log entries specifically for login actions.

dstip==10.1.1.210:
Specifies that the login destination was the FortiAnalyzer's IP address (the target of the management session).

user!=admin:
Matches any log where the username is not "admin", fulfilling the requirement to see all other users. The use of & (AND) ensures all these conditions must be true for a log to match.

Incorrect Option

B. operation=login & srcip==10.1.1.100 & dstip==10.1.1.210 & user==admin
This is incorrect because it uses user==admin. This filter would show only the login attempts made by the "admin" user from Laptop1, which is the exact opposite of what is requested. The requirement is to see logins from users other than "admin".

C. operation=login & performed_on=="GUI(10.1.1.210)" & user!=admin
This is incorrect. While user!=admin is correct, the performed_on field typically refers to the object being acted upon, not the source of the action. In system event logs for a login, the source IP (srcip) is the correct field to filter by to identify the machine where the administrator is working. The performed_on field is not standard for capturing the client source IP in a login event.

D. operation=login & performed_on=="GUI(10.1.1.100)" & user!=admin
This is incorrect for two reasons. First, it uses the non-standard performed_on field. Second, it specifies the Laptop1 IP (10.1.1.100) as the target (performed_on), which is illogical. The FortiAnalyzer (10.1.1.210) is the target of the login, not the laptop. The source IP of the login attempt is 10.1.1.100.

Reference
Fortinet Documentation Library: Log views and filters (This section details how to build filters using fields like operation, srcip, dstip, and user).

Summary
FortiAnalyzer uses specialized processes, known as daemons, to handle different aspects of log management. Each daemon has a specific role, such as receiving logs, indexing them into the database, or managing the log files on the disk. The enforcement of log file size limits and the subsequent archiving process is handled by one of these core daemons.

Correct Option

B. logfiled
This is correct. The logfiled daemon is responsible for managing the log files on the FortiAnalyzer's disk. Its functions include writing incoming logs to files, enforcing the configured maximum log file size, and handling the rollover process. When a log file reaches its size limit, logfiled closes it, compresses it into an archive (offline log), and starts a new log file.

Incorrect Option

A. sqlplugind
This is incorrect. The sqlplugind daemon is responsible for parsing the raw log data and inserting (indexing) it into the SQL database. This process creates the "analytics logs" used for reporting and FortiView. It does not manage the size or archiving of the raw log files on the disk.

C. miglogd
This is incorrect. The miglogd (migration log daemon) handles the movement and migration of log data. Its primary roles include transferring logs between devices in a FortiAnalyzer Fabric and managing the backup of logs to external storage. It works with the archive files created by logfiled but does not control their initial size.

D. ofrpd
This is incorrect. ofrpd is not a standard daemon related to core log management on FortiAnalyzer. It may be a distractor or refer to a process not involved in log file size enforcement. The key daemons for log processing are logfiled, sqlplugind, and miglogd.

Reference
Fortinet Documentation Library: FortiAnalyzer processes (daemons) (This section describes the function of key daemons like logfiled and sqlplugind).