FCP_FAZ_AN-7-4 Practice Questions

:

To ensure that reports generated by FortiAnalyzer are automatically sent to an email inbox, you need

to set up an output profile for the reports. Output profiles specify where and how reports should be

delivered, including the option to send them via email.

Option A - Enable the Option to Email All Reports Under the Mail Server:

The mail server configuration allows FortiAnalyzer to send emails but does not automatically enable

email distribution for reports. This setting alone does not specify which reports to send or to whom.

Conclusion: Incorrect.

Option B - Add a mailto: Option Within the Report Layouts:

Adding an email address within the report layout is not a standard configuration option for report

distribution. Report layouts define the format and content of the report but not its distribution

method.

Conclusion: Incorrect.

Option C - Enable Email Notification Under the Report Calendar:

The report calendar is used to schedule when reports are generated. While it triggers report

generation at specific times, it does not handle email distribution. Emailing reports requires a

configured output profile.

Conclusion: Incorrect.

Option D - Enable an Output Profile on the Reports:

An output profile can be configured on FortiAnalyzer to define delivery options, including emailing

the report to specified recipients. This setup ensures that every time a report is generated according

to the schedule, it is automatically emailed to the configured address.

Conclusion: Correct.

Conclusion:

Correct Answe r : D. Enable an output profile on the reports.

Configuring an output profile is the correct way to set up automatic email distribution of generated

reports in FortiAnalyzer.

Reference:

FortiAnalyzer 7.4.1 documentation on configuring output profiles and report distribution settings.

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

The objective is to create a filter that identifies all login attempts to the FortiAnalyzer web interface

(GUI) coming from Laptop1 (IP 10.1.1.100) and excludes the admin user. This filter should match any

user other than admin.

Filter Components Analysis:

Operation-login: This portion of the filter will target login actions specifically, which is correct for

filtering login attempts.

performed_on==’’GUI(10.1.1.100)’: This indicates that the login attempt must occur on the GUI

interface and originate from the specified IP, which matches Laptop1's IP address (10.1.1.100). This

ensures that the filter only matches GUI logins from this specific device.

user!=admin: This part excludes logins by the admin user, meeting the requirement to capture only

non-admin users.

Option Analysis:

Option A: Correctly specifies the Operation-login, performed_on==’’GUI(10.1.1.100)’, and

user!=admin. This setup effectively filters login attempts to the GUI from Laptop1, excluding the

admin user.

Option B: Uses the incorrect IP 10.1.1.120 in the performed_on filter, which does not match

Laptop1's IP (10.1.1.100).

Option C: This option includes srcip==10.1.1.100 and dstip==10.1.1.210 but incorrectly specifies

user==admin instead of user!=admin, which does not match the requirement to exclude admin

users.

Option D: This option does not specify the performed_on field to restrict it to the GUI and only

includes dstip (destination IP) without srcip. It also incorrectly uses user!-admin instead of the

correct syntax user!=admin.

Conclusion:

Correct Answe r : A. Operation-login and performed_on==’’GUI(10.1.1.100)’ and user!=admin

This filter precisely captures the required conditions: login attempts from Laptop1 to the GUI

interface by any user except admin.

Reference:

FortiAnalyzer 7.4.1 documentation on log filters, syntax for login operations, and GUI login tracking.

In FortiOS and FortiAnalyzer, incident notifications can be sent to multiple external platforms, not

limited to a single method such as email. Fortinet's security fabric and integration capabilities allow

notifications to be sent through various fabric connectors and third-party integrations. This flexibility

is designed to ensure that incident updates reach relevant personnel or systems using preferred

communication channels, such as email, Syslog, SNMP, or integration with SIEM platforms.

Let’s review each answer option for clarity:

Option A: You can send notifications to multiple external platforms

This is correct. Fortinet’s notification system is capable of sending updates to multiple platforms,

thanks to its support for fabric connectors and external integrations. This includes options such as

email, Syslog, SNMP, and others based on configured connectors.

Option B: Notifications can be sent only by email

This is incorrect. Although email is a common method, FortiOS and FortiAnalyzer support multiple

notification methods through various connectors, allowing notifications to be directed to different

platforms as per the organization’s setup.

Option C: If you use multiple fabric connectors, all connectors must have the same settings

This is incorrect. Each fabric connector can have its unique configuration, allowing different

connectors to be tailored for specific notification and integration requirements.

Option D: Notifications can be sent only when an incident is updated or deleted

This is incorrect. Notifications can be sent upon the creation of incidents, as well as upon updates or

deletion, depending on the configuration.

Reference: According to FortiOS and FortiAnalyzer 7.4.1 documentation, notifications for incidents

can be configured across various platforms by using multiple connectors, and they are not limited to

email alone. This capability is part of the Fortinet Security Fabric, allowing for a broad range of

integrations with external systems and platforms for effective incident response​.

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

:

Thank you for your visit.

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.

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