Fortinet Fortinet NSE 5 - FortiAnalyzer 7.6 Analyst - FCP_FAZ_AN-7.6 Practice Questions

Explanation:

This question tests whether you can identify different log formats that FortiAnalyzer handles. When logs arrive from FortiGate devices, FortiAnalyzer processes them in specific ways. The key is recognizing what "normalized" and "raw" actually mean in this context.

✅ A. This is a normalized log.
Correct. This log has been normalized by FortiAnalyzer. Normalization is the process where FortiAnalyzer takes logs from different Fortinet devices and standardizes them into a consistent format with predictable field names and structures.
Look at the log structure: you see standardized key-value pairs like devname=, logid=, type=, subtype=, eventtype=, etc. These consistent field names across different log types and devices are the hallmark of normalized logs. FortiAnalyzer does this so you can query and analyze logs uniformly, regardless of which device sent them.

✅ D. This log is in a raw log format.
Correct. Raw format means the log is presented as a single-line string with key-value pairs separated by spaces and special characters. This is the native format that FortiGate sends and FortiAnalyzer stores.
Raw logs look exactly like what you see here: a continuous string of field=value pairs. This format is efficient for storage and transmission but harder for humans to read. It's the opposite of a formatted or pretty-printed view where data would be organized into tables or structured layouts.

❌ B. This is a formatted view of the log.
Wrong. A formatted view would present the log data in a human-readable structure like a table with columns and rows, or organized sections with labels. What you're seeing here is the raw string format—just a long line of key-value pairs mashed together.
When you view logs in FortiAnalyzer's GUI in "formatted view," it breaks out fields into separate columns or sections. This exhibit is definitely not that. It's the raw text string, which is harder to parse visually but closer to how the data is actually stored.

❌ C. This is the original log that FortiAnalyzer received from FortiGate.
Wrong. This is not the original log as it came from FortiGate. While it looks raw, FortiAnalyzer has already normalized it. The original log from FortiGate might have slightly different field names or structures depending on the FortiOS version and log type.
FortiAnalyzer processes incoming logs and normalizes them into its own schema before storage. So what you're seeing is post-normalization but still in raw format (not formatted for display). The normalization happened, but the presentation is still raw text.

Reference
https://docs.fortinet.com

Explanation:

FortiAnalyzer's Security Fabric integration lets it connect with other Fortinet devices—like fellow FortiAnalyzers or FortiGates—in a fabric for centralized management, logging, and analytics. HA clusters count as single fabric nodes, but all listed units must show compatible Fabric Connector enablement and downstream roles to join seamlessly. ​

Correct Answer

✅ D. All devices listed can be members.
Spot on—the outputs confirm FortiAnalyzer1 (primary HA node), FortiAnalyzer2 (secondary HA node), and FortiAnalyzer3 (standalone) all have Security Fabric enabled with matching roles like "Downstream." HA pairs operate as one fabric entity, and the standalone unit shares the same Fabric Connector setup, allowing full fabric membership without conflicts. ​ ​

Why Others Are Wrong

❌ A. FortiAnalyzer1 and FortiAnalyzer3.
This overlooks FortiAnalyzer2, which is integral as the HA secondary—excluding it ignores how HA clusters function as unified fabric participants. A frequent pitfall is treating HA members separately rather than as a cohesive unit. ​

❌ B. FortiAnalyzer1 and FortiAnalyzer2.
Misses FortiAnalyzer3 entirely, despite its identical Fabric settings confirming eligibility. People often fixate on HA pairs alone, but fabric rules allow multiple analyzers to interconnect. ​

❌ C. FortiAnalyzer2 and FortiAnalyzer3.
Leaves out the primary HA node (FortiAnalyzer1), breaking the cluster logic since secondaries don't join fabrics independently. Misconception here: HA roles don't restrict fabric joins, but all must align. ​

Reference:
https://docs.fortinet.com/product/fortianalyzer/7.6

Explanation:

❌ A. Only FGT-B will create traffic logs.
Traffic logging (forward traffic logs) normally happens at each FortiGate that processes the session—especially since all policies have logging enabled. FGT-B would log the session as it enters and exits, and FGT-A would also generate its own traffic log after NAT. This option ignores FGT-A's role entirely. A common mix-up is thinking only the first device logs traffic, but in Fabric setups both typically do (though FortiAnalyzer correlates them smartly).

❌ B. FGT-B will see the MAC address of FGT-A as the destination and notifies FGT-A to log this flow.
This sounds like a creative guess, but FortiGates don't "notify" each other to create logs in that way for standard traffic flows. In the Security Fabric, devices share topology awareness (including MACs of directly connected peers), but logging responsibility isn't delegated like this. Traffic logs are generated locally by each device that handles the packets. No such notification mechanism exists for basic web traffic logging.

❌ C. FGT B will create traffic logs and will create web filter logs if it detects a violation.
FGT-B does create traffic logs (agreed—policies have logging enabled). But would FGT-B generate the web filter violation log? Here's the key reflection: since FGT-A (the root) is performing NAT, and web filtering typically needs to see the real destination URL/category before NAT obscures things, in standard Security Fabric outbound flows with downstream → root NAT, the deep content inspection (including web filter category blocking/violation) usually happens at the egress/root FortiGate that owns the public IP and performs NAT. FGT-B is more likely just routing/forwarding without applying the final web filter decision/logging. This is a subtle but frequent point of confusion in Fabric scenarios.

✅ D. Only FGT-A will create web filter logs if it detects a violation.
This aligns most closely with typical behavior in this exact topology. Because FGT-A is the NAT boundary and the final policy enforcement point before Internet egress, it performs the web filter inspection on the actual requested URL/category. If a violation occurs (e.g., blocked category), only FGT-A generates the web filter log (since profiles log violations only). FGT-B may apply its own policy and log traffic, but the violation-specific UTM log comes from the device that made the blocking decision—here, the root with NAT. FortiAnalyzer then correlates everything nicely across the Fabric. ​

Reference:
https://docs.fortinet.com/product/fortianalyzer

Explanation:

This question checks whether you understand the relationship between log rate and message rate in FortiAnalyzer diagnostics. These two values are closely related and normally track each other. When they don’t, it can indicate a problem in the logging pipeline. The exhibit shows a clear imbalance, and the question asks what conclusion you can reasonably draw from that.

✅ Correct Answer: D. The log rate higher than the message rate is not normal
In a healthy FortiAnalyzer system, the message rate should be equal to or higher than the log rate, because:
🔹 Messages are processed internally by fortilogd
🔹 Logs are the resulting records written after processing
If the log rate is significantly higher than the message rate, as shown in the output, this is abnormal. It suggests that logs are being generated or counted faster than messages are being processed, which can point to processing inconsistencies, backlog issues, or abnormal behavior in the logging subsystem.
This mismatch is exactly what the diagnostic output is highlighting, and it warrants attention.

❌ Incorrect Options

A. The low indexing values require investigation.
Indexing is not shown in this output at all. The commands used (diagnose fortilogd lograte and diagnose fortilogd msgrate) report rates, not indexing performance. Drawing conclusions about indexing here is unsupported.

B. The output is not ADOM specific.
While it’s true that these commands are global diagnostics, that is not the key takeaway from the exhibit. The question asks what you can conclude about the output itself, not the scope of the command. This option is technically irrelevant to the observed issue.

C. There are more event logs than traffic logs.
Nothing in the output differentiates event logs vs traffic logs. The diagnostics only show aggregate message and log rates. Choosing this option means inventing data that is simply not present. ​

Reference:
Fortinet Documentation

Explanation:

✅ D. They are not used in macros.
This is the correct answer. Within FortiAnalyzer, macros are small, reusable pieces of pre-defined SQL logic, but they themselves are not full SELECT queries. Instead, macros are defined using the SELECT statement and then saved as a named object (like $src_ip). They are used within SELECT queries in reports or charts to simplify complex logic. You would insert a macro ($src_ip) into the SELECT clause of your main query. So, the complete SELECT query is the container, and the macro is a component inside it.
Think of it this way: You use a SELECT query to build and employ a macro, but the final saved macro isn't itself a standalone SELECT query you run. This is a subtle but important distinction in the FortiAnalyzer architecture.

❌ A. They can be used to purge log entries from the database.
This is incorrect. The SELECT statement is a Data Query Language (DQL) command. Its only function is to read or retrieve data from the database. It cannot modify or delete data. To purge or delete log entries, you would use a Data Manipulation Language (DML) command like DELETE. FortiAnalyzer intentionally restricts this capability to protect data integrity; log purging is typically done through administrative functions (like Archive & Purge) or automatic retention policies, not via direct SQL DELETE commands.

❌ B. They must be followed immediately by a WHERE clause.
This is incorrect. A WHERE clause is optional in a SELECT query. It is used to filter results. A basic, valid SELECT query could simply be:
SELECT datetime, srcip, action FROM $log
This would return all records from the log view. While WHERE is extremely common for filtering, it is not a syntactic requirement.

❌ C. They can be used to display the database schema.
This is a tricky one but incorrect in the FortiAnalyzer context. In standard SQL, you can use specialized SELECT queries on system tables (like information_schema) to discover the schema. However, FortiAnalyzer does not expose its underlying database schema in this way to users. The log database structure is abstracted through predefined log views (like $log, $traffic). Analysts write SELECT queries against these views, not against the raw database tables. Therefore, you cannot use a SELECT query in FortiAnalyzer's report editor to explore or display the internal schema. ​

Reference:
Official Fortinet Documentation

Explanation:

When you can't find a log in FortiView, it’s usually because of how FortiAnalyzer handles data. FortiAnalyzer stores logs in two main "states": Archive (raw logs saved as compressed .gz files) and Analytics (logs indexed in an SQL database for fast searching and dashboarding).
FortiView relies entirely on the SQL database (Analytics). If the database is out of sync or if the logs haven't been indexed yet, they won't show up in FortiView, even if the FortiAnalyzer actually received them.

The Breakdown

✅ Option B: Rebuild the SQL database and check FortiView.
This is a primary troubleshooting step. If logs exist on the disk but aren't appearing in FortiView, it often means the SQL index is corrupt or incomplete. Rebuilding the database (using execute sql-local rebuild-db) forces FortiAnalyzer to re-scan the raw archive files and re-insert them into the SQL database, making them visible to FortiView again.

✅ Option D: Check logs in the Log Browse.
Log Browse is the best place to verify if the "raw" data actually exists. Unlike FortiView, Log Browse shows the actual files stored on the disk (the Archive logs). If you can see the logs here but not in FortiView, you know the issue is with the SQL indexing (Analytics). If the logs aren't even in Log Browse, then the FortiAnalyzer never received them in the first place.

❌ Option A: Open .gz log files in FortiView.
This is a technical impossibility. FortiView is a graphical dashboard that queries a database; it cannot "open" or read compressed .gz files directly. You would use Log Browse to download or view these raw files, but not FortiView.

❌ Option C: Review the ADOM data policy.
While the data policy controls how long logs are kept (retention), changing it won't help you find a missing log that should be there currently. The policy determines when logs are deleted or moved from Analytics to Archive, but it isn't a tool for investigating why a specific existing log isn't appearing in a dashboard.

Teacher's Tip for the Exam
A common "trap" in FortiAnalyzer questions is confusing Log View (which uses the SQL database) with Log Browse (which uses the raw file system). Always remember:
🔹 FortiView/Reports/Log View = SQL Database (Analytics).
🔹 Log Browse = Raw Files (Archive). ​

Reference:
Fortinet Document Library

Explanation:

In FortiAnalyzer (and FortiOS), the “Unhandled” status in event logs typically indicates that a security event was detected but no blocking or mitigating action was taken—meaning traffic was allowed to pass. This is often used for monitoring or alerting purposes only, not enforcement. So, if a security feature detects a threat but is configured to “pass” (i.e., allow) the traffic, FortiAnalyzer may classify that event as Unhandled, because the system did not actively handle (block, quarantine, etc.) the threat.

Correct Answer

✅ B. An IPS log with action=pass.
When an Intrusion Prevention System (IPS) signature matches traffic but is set to action=pass, FortiGate logs the event but allows the traffic to continue. Since no protective action was taken—no block, reset, or drop—the event is considered “Unhandled” in FortiAnalyzer’s event view. This is by design: “Unhandled” reflects detection without intervention, which is exactly what action=pass means in IPS policies.

Incorrect Answers

❌ A. An AV log with action=quarantine.
If antivirus (AV) scanning results in quarantine, the malicious file has been actively handled—isolated from the system. This is a clear enforcement action, so the event status will be “Handled”, not “Unhandled.” Quarantine is a definitive response, not passive observation.

❌ C. A WebFilter log with action=dropped.
When Web Filtering drops a request (e.g., due to a category block), the connection is terminated. This is an active enforcement action. FortiAnalyzer marks such events as “Handled” because the threat or policy violation was addressed by blocking access.
💡 Note: The option says “willaction=dropped”—likely a typo for “with action=dropped.” Regardless, the intent is clear.

❌ D. An AppControl log with action=blocked.
Application Control logs with action=blocked mean the application was explicitly denied. Like WebFilter and AV quarantine, this is an active control measure. Therefore, the event is Handled, not Unhandled.

Why This Matters?
Understanding the distinction between detection-only (pass) and enforcement (block, quarantine, drop) is crucial for interpreting FortiAnalyzer reports, especially when auditing security posture or investigating why certain threats weren’t stopped. ​

Reference:
https://docs.fortinet.com/product/fortianalyzer/7.6