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

The exhibit displays a diagnose log device output on a FortiAnalyzer, showing details about disk

space usage and quotas for different FortiGate devices and ADOMs (Administrative Domains). Here’s

a breakdown of key details:

Disk Quota for Quarantined Files:

The output includes columns labeled for used space in categories such as "logs," "quarantine,"

"content," and "DB." For each device, the quarantine column consistently shows 0.0KB used,

indicating that there is no disk quota allocated or utilized for quarantining files.

Conclusion: Correct.

FGT_B as Security Fabric Root:

There is no direct indication from this output that specifies FGT_B is the root of the Security Fabric.

Information on Security Fabric topology or root designation would typically come from a Security

Fabric configuration command rather than a disk usage summary.

Conclusion: Incorrect.

Allocated Disk Quota for ADOM1:

The output shows the quota for ADOM1 is "unlimited," not a fixed 3 GB quota. Therefore, there is no

set 3 GB limit for ADOM1.

Conclusion: Incorrect.

Comparison of Archive Logs and Analytic Logs:

The output does not differentiate between archive logs and analytic logs; it only shows overall disk

usage by type (e.g., logs, quarantine). Therefore, no conclusion can be made about which type of

logs (archive or analytic) is using more space.

Conclusion: Incorrect.

Conclusion:

Correct Answe r : A. There is no disk quota allocated to quarantining files.

This answer aligns with the observed data, where no disk space is used or allocated for quarantine

files.

Reference:

FortiAnalyzer 7.4.1 documentation on diagnose log device command usage and disk quota settings.

In this output, we see two diagnostic commands executed on a FortiAnalyzer device:

diagnose fortilogd lograte: This command shows the rate at which logs are being processed by the

FortiAnalyzer in terms of log entries per second.

diagnose fortilogd msgrate: This command displays the message rate, or the rate at which individual

messages are being processed.

The values provided in the exhibit output show:

Log rate (lograte): Consistently high, showing values such as 70.0, 132.1, and 133.3 logs per second

over different time intervals.

Message rate (msgrate): Lower values, around 1.4 to 1.6 messages per second.

Explanation

Interpretation of log rate vs. message rate: In FortiAnalyzer, the log rate typically refers to the rate of

logs being stored or indexed, while the message rate refers to individual messages within these logs.

Given that a single log entry can contain multiple messages, it's common to see a lower message

rate relative to the log rate.

Understanding normal operation: In this case, the message rate being lower than the log rate is

expected and typical behavior. This discrepancy can arise because each log entry may bundle

multiple related messages, reducing the message rate relative to the log rate.

Conclusion

Correct Answe r : A. The message rate being lower than the log rate is normal.

This aligns with the normal operational behavior of FortiAnalyzer in processing logs and messages.

There is no indication that both logs and messages are nearly finished indexing, as that would

typically show diminishing rates toward zero, which is not the case here. Additionally, there’s no

information in this output about specific ADOMs or a comparison between traffic logs and event

logs. Thus, options B, C, and D are incorrect.

Reference:

FortiOS 7.4.1 and FortiAnalyzer 7.4.1 command guides for diagnose fortilogd lograte and diagnose

fortilogd msgrate.

In FortiAnalyzer, when a playbook is run, each task’s status impacts the overall playbook status.

Here’s what happens based on task outcomes:

Status When All Tasks Succeed:

If all tasks finish successfully, the playbook status is marked as Success.

Status When Some Tasks Fail:

If one or more tasks in the playbook fail, but others succeed, the playbook status generally changes

to Attention required. This status indicates that the playbook completed execution but requires

review due to one or more tasks failing.

This is different from a complete Failed status, which is used if the playbook cannot proceed due to a

critical error in an early task, often one that upstream tasks depend on.

Option Analysis:

A . Attention required: This is correct as the playbook has completed, but with partial success and a

task requiring review.

B . Upstream_failed: This status is used if a task cannot run because a prerequisite or "upstream" task

failed. Since four out of five tasks completed, this is not the case here.

C . Failed: This status would imply that the playbook completely failed, which does not match the

scenario where only one task out of five failed.

D . Success: This status would apply if all tasks had completed successfully, which is not the case

here.

Conclusion:

Correct Answe r : A. Attention required

The playbook status reflects that it completed, but an error occurred in one of the tasks, prompting

the administrator to review the failed task.

Reference:

FortiAnalyzer 7.4.1 documentation on playbook execution statuses and task error handling.

Macros in FortiAnalyzer are used to streamline reporting tasks by automating data extraction and

report generation. Here’s a breakdown of each option to determine the correct answer:

Option A - Macros are Predefined Templates for Reports and Cannot be Customized:

This statement is incorrect. Macros in FortiAnalyzer are not simply fixed templates; they allow for

customization to tailor data extraction and reporting based on specific needs and configurations.

Conclusion: Incorrect.

Option B - Macros are Useful in Generating Excel Log Files Automatically Based on the Report

Settings:

This statement is accurate. Macros in FortiAnalyzer can be configured to automate the generation of

reports, including outputting log data to Excel format based on predefined report settings. This

makes them especially useful for scheduled reporting and data analysis.

Conclusion: Correct.

Option C - Macros are ADOM-Specific and Each ADOM Type Has Unique Macros Relevant to that

ADOM:

Macros are not limited to specific ADOMs, nor are they ADOM-specific. Macros can be applied across

various ADOMs based on report configurations but are not inherently tied to or unique for each

ADOM type.

Conclusion: Incorrect.

Option D - Macros are Supported Only on the FortiGate ADOMs:

This is not true. Macros in FortiAnalyzer are not restricted to FortiGate ADOMs; they can be utilized

across different ADOMs that FortiAnalyzer manages.

Conclusion: Incorrect.

Conclusion:

Correct Answe r : B. Macros are useful in generating excel log files automatically based on the report

settings.

This answer correctly describes the functionality of macros in FortiAnalyzer, emphasizing their role in

automating report generation, especially for Excel log files.

Reference:

FortiAnalyzer 7.4.1 documentation on macros and report generation functionalities.

The command diagnose sql status sqlreportd is used in FortiAnalyzer to obtain specific information

about the SQL reporting process and caching status. Here’s what this command accomplishes and an

analysis of each option:

Command Functionality:

sqlreportd is the FortiAnalyzer daemon responsible for managing SQL-based reporting processes.

The diagnose sql status sqlreportd command provides information on active SQL query connections

and the hcache (historical cache) status, which helps in monitoring and troubleshooting SQL report

generation.

Option Analysis:

Option A - To View a List of Scheduled Reports:

This option is incorrect because the command does not list scheduled reports. Instead, it focuses on

SQL reporting processes and cache details.

Option B - To List the Current SQL Processes Running:

While the command may show active SQL connections, its primary focus is not a detailed list of all

SQL processes but rather the connections and cache status for reporting.

Option C - To Display the SQL Query Connections and hcache Status:

This is correct. The command specifically provides information on SQL query connections related to

the reporting process (sqlreportd) and displays the hcache status.

Option D - To Identify the Database Log Insertion Status:

This is incorrect. The command does not provide details on log insertion status. Log insertion status is

typically monitored through different diagnostic commands focused on database processes and log

handling.

Conclusion:

Correct Answe r : C. To display the SQL query connections and hcache status

This command is used to monitor SQL reporting activities and cache status, aiding in the analysis of

report generation performance and connection health.

Reference:

FortiAnalyzer 7.4.1 documentation on SQL diagnostic commands, particularly those related to

reporting (sqlreportd) and caching mechanisms.

:

In FortiOS 7.4.1 and FortiAnalyzer 7.4.1, the "Unhandled" status in logs typically signifies that the

FortiGate encountered a security event but did not take any specific action to block or alter it. This

usually occurs in the context of Intrusion Prevention System (IPS) logs.

IPS logs with action=pass: When the IPS engine inspects traffic and determines that it does not match

any known attack signatures or violate any configured policies, it assigns the action "pass". Since no

action is taken to block or modify this traffic, the status is logged as "Unhandled."

Let's look at why the other options are incorrect:

An AV log with action=quarantine: Antivirus (AV) logs with the action "quarantine" indicate that a file

was detected as malicious and moved to quarantine. This is a definitive action, so the status wouldn't

be "Unhandled."

A WebFilter log will action=dropped: WebFilter logs with the action "dropped" indicate that web

traffic was blocked according to the configured web filtering policies. Again, this is a specific action

taken, not an "Unhandled" event.

An AppControl log with action=blocked: Application Control logs with the action "blocked" mean that

an application was denied access based on the defined application control rules. This is also a clear

action, not "Unhandled."

In FortiOS and FortiAnalyzer logging systems, when an event has a status of "Mitigated" in the Event

Status column, it typically indicates that the system took action to address the identified threat. In

this case, the Web Filter blocked the web request to a suspicious destination, and the event status

"Mitigated" confirms that the action was successfully implemented to neutralize or block the security

risk.

Let's review the answer options:

Option A: The risk source is isolated.

This is incorrect because "isolated" would imply that FortiGate took further steps to prevent the

source device from communicating with the network. There is no indication of isolation in this event

status.

Option B: The security risk was blocked or dropped.

This is correct. The "Mitigated" status, along with the Web Filter event type and the accompanying

description, implies that the FortiGate or FortiAnalyzer successfully blocked or dropped the

suspicious web request, which corresponds to the term "mitigated."

Option C: The security event risk is considered open.

This is incorrect because an open status would indicate that no action was taken, or the threat is still

present. The "Mitigated" status indicates that the threat has been addressed.

Option D: An incident was created from this event.

This option is not correct or evident based on the given display. Although FortiAnalyzer or FortiGate

could escalate certain events to incidents, this is not indicated here.

Reference:

The FortiOS 7.4.1 and FortiAnalyzer 7.4.1 documentation specify that "Mitigated" status in logs

means the identified threat was handled, usually by blocking or dropping the action associated with

the event, particularly with Web Filter and Security Policy logs​.

:

When a new playbook is created on FortiAnalyzer, the system requires some time to parse and

validate the playbook before it can be executed. Parsing involves checking the playbook's structure,

ensuring that all syntax and logic are correct, and preparing the playbook for execution within

FortiAnalyzer’s automation engine. This initial parsing step is necessary for FortiAnalyzer to load the

playbook into its operational environment correctly.

Here’s why the other options are incorrect:

Option A: FortiAnalyzer needs that time to parse the new playbook

This is correct. The delay is due to the parsing and setup process required to prepare the new

playbook for execution. FortiAnalyzer’s automation engine checks for any issues or dependencies

within the playbook, ensuring that it can run without errors.

Option B: FortiAnalyzer needs that time to debug the new playbook

This is incorrect. Debugging is not an automatic process that FortiAnalyzer undertakes after playbook

creation. Debugging, if necessary, is a manual task performed by the administrator if there are issues

with the playbook execution.

Option C: FortiAnalyzer needs that time to back up the current playbooks

This is incorrect. FortiAnalyzer does not automatically back up playbooks every time a new one is

created. Backups of configuration and playbooks are typically scheduled as part of routine

maintenance and are not triggered by playbook creation.

Option D: FortiAnalyzer needs that time to ensure there are no other playbooks running

This is incorrect. FortiAnalyzer can manage multiple playbooks running simultaneously, so it does not

require waiting for other playbooks to finish before initiating a new one. The waiting time specifically

relates to the parsing process of the newly created playbook.

Reference: FortiAnalyzer documentation states that after creating a playbook, a brief delay is

expected as the system parses and validates the playbook. This ensures that any syntax errors or

logical inconsistencies are resolved before the playbook is executed, making option A the correct

answer​.

:

:

When you frequently use the same search parameters in FortiAnalyzer’s Log View, setting up a

reusable filter or view can save considerable time. Here’s an analysis of each option:

Option A - Configure a Custom Dashboard:

Custom dashboards are useful for displaying a variety of widgets and summaries on network activity,

performance, and threat data, but they are not designed for storing specific search filters for log

views.

Conclusion: Incorrect.

Option B - Configure a Custom View:

Custom views in FortiAnalyzer allow analysts to save specific search filters and configurations. By

setting up a custom view, you can retain your frequently used search parameters and quickly access

them without needing to reapply filters each time. This option is specifically designed to streamline

the process of recurring log searches.

Conclusion: Correct.

Option C - Configure a Data Selector:

Data selectors are used to define specific types of data for FortiAnalyzer reports and widgets. They

are useful in reports but are not meant for saving and reusing log search parameters in Log View.

Conclusion: Incorrect.

Option D - Configure a Macro and Apply It to Device Groups:

Macros in FortiAnalyzer are generally used for automation tasks, not for saving log search filters.

Applying macros to device groups does not fulfill the requirement of saving specific log view search

parameters.

Conclusion: Incorrect.

Conclusion:

Correct Answe r : B. Configure a custom view.

Custom views allow you to save specific search filters, enabling quick access to frequently used

parameters in Log View.

Reference:

FortiAnalyzer 7.4.1 documentation on creating and using custom views for log searches.

:

In FortiAnalyzer's incident management system, analysts have the option to manually manage

incidents, which includes attaching relevant reports to an incident for further investigation and

documentation. This feature allows analysts to consolidate information, such as detailed reports on

suspicious activity, into an incident record, providing a comprehensive view for incident response.

Let's review the other options to clarify why they are incorrect:

Option A: You can manually attach generated reports to incidents

This is correct. FortiAnalyzer allows analysts to manually attach reports to incidents, which is

beneficial for providing additional context, evidence, or analysis related to the incident. This

functionality is part of the incident management process and helps streamline information for

tracking and resolution.

Option B: The status of the incident is always linked to the status of the attached event

This is incorrect. The status of an incident on FortiAnalyzer is managed independently of the status of

any attached events. An incident can contain multiple events, each with different statuses, but the

incident itself is tracked separately.

Option C: Severity incidents rated with the level High have an initial service-level agreement (SLA)

response time of 1 hour

This is incorrect. While incidents have severity levels, specific SLA response times are typically set

according to the organization’s incident response policy, and FortiAnalyzer does not impose a default

SLA response time of 1 hour for high-severity incidents.

Option D: Incidents must be acknowledged before they can be analyzed

This is incorrect. Incidents on FortiAnalyzer can be analyzed even if they are not yet acknowledged.

Acknowledging an incident is often part of the workflow to mark it as being actively addressed, but it

is not a prerequisite for analysis.

Reference: According to FortiAnalyzer documentation, analysts can attach reports to incidents

manually, making option A correct. This feature enables better tracking and documentation within

the incident management system on FortiAnalyzer​.