Fortinet Network Security Expert 8 Written - NSE8_812 Practice Questions

Explanation:

The default load balancing mode for the SD-WAN implicit rule is source IP based. This means that traffic will be load balanced evenly between the overlay members, regardless of the member's priority.
To prevent traffic from being load balanced, you can configure the priority of each overlay member to 10. This will make the member ineligible for load balancing.
The other options are not correct. Changing the load balancing mode to source-IP based will still result in traffic being load balanced. Creating a new static route with the internet sdwan-zone only will not affect the load balancing of the overlay interface. Configuring the cost in each overlay member to 10 will also not affect the load balancing, as the cost is only used when the implicit rule cannot find a match for the destination IP address.

Explanation:

The MTA adapter in FortiSandbox allows SMTP-based email traffic to be relayed for sandboxing. In an HA cluster, only the primary node handles MTA adapter functions to avoid duplicate processing and ensure consistent policy enforcement. Secondary nodes do not process MTA traffic, maintaining HA integrity and load control.

❌ Why Other Options Are Incorrect

A. The configuration of the MTA Adapter Local Interface is different than on port1.
This is misleading. The MTA adapter can be bound to any interface, including port1, but the configuration syntax and behavior are consistent across interfaces. The key distinction in HA is not the interface used, but the node role (primary vs secondary).

C. The MTA adapter mode is only detection mode.
ncorrect. The MTA adapter supports both detection and inline blocking modes depending on policy configuration. Detection mode logs threats, while inline mode can quarantine or block malicious content. The adapter is not limited to detection-only.

D. The configuration is different than on a standalone device.
The configuration syntax and interface binding are the same. What differs is operational behavior in HA: only the primary node processes MTA traffic. This ensures centralized control and avoids redundant scanning across nodes.

📚 Reference:

Fortinet Documentation – FortiSandbox MTA Adapter:
“In HA clusters, the MTA adapter is only active on the primary node. Secondary nodes do not process email traffic.”

Explanation:

The FortiWeb server pool uses weighted-round-robin load balancing. Server 1 has a weight of 50, and Server 2 has a weight of 100. The total weight is 150. Therefore, Server 1 receives 50 150 = 33.3 % of sessions, and Server 2 receives 100 150 = 66.6 % .

❌ Why Other Options Are Incorrect

A. Server 1 will receive 25%, Server 2 75%
This implies a 1:3 weight ratio, which would require weights of 50 and 150 respectively. The actual weights are 50 and 100, so the ratio is 1:2, not 1:3. This makes the percentage split incorrect.

B. Server 1 will receive 20%, Server 2 66.6%
These percentages don’t align with any valid weight ratio. 20% would imply Server 1 has a weight of 30 compared to Server 2’s 120, which is not the case. Also, the total doesn’t sum to 100%, making this option invalid.

D. Server 1 will receive 0%, Server 2 100% Server 1
is marked as a backup server, but FortiWeb still includes it in the weighted-round-robin unless the primary (Server 2) fails. During normal operation, both servers participate based on their weights. So Server 1 does receive traffic unless failover is triggered.

📚 Reference

Fortinet FortiWeb Admin Guide:
“Weighted-round-robin distributes sessions proportionally based on server weights. Backup servers participate unless failover conditions are met.”

Explanation:

Transit VPC with FortiGate HA (A):
Centralizes inspection between departmental VPCs while keeping their management separate. Spoke VPCs peer to the transit VPC, and routing forces east–west traffic through FortiGate for L3–L7 security.

Transit Gateway with FortiGate auto-scaling (D):
Scales and centralizes security via TGW attachments from each VPC to a FortiGate security VPC, preserving departmental autonomy while enforcing inspection on inter-VPC flows.

Why the other options are incorrect

B: Grants the cybersecurity IAM account management over both VPCs, violating separate VPC management. Per-VPC FortiGate HA clusters plus IPsec between them can secure traffic, but central control over both VPCs breaks the requirement of separate management domains.

C: Migrating all instances into a single VPC consolidates departments, eliminating separate VPC management. It also introduces major re-architecture risk. AWS and Fortinet recommend centralized security using Transit VPC or TGW to keep VPCs separate while inspecting inter-VPC traffic.

References:

Fortinet Deployment Guide: AWS Transit VPC with FortiGate NGFW – hub-and-spoke security for inter-VPC traffic.
AWS Whitepaper: Centralized network security for VPC-to-VPC traffic using Transit VPC, TGW, GWLB.

Explanation:

FortiGuard Outbreak Protection Service (VOS) enhances FortiGate antivirus by querying FortiGuard with file hashes. When a file is scanned, its hash is checked against FortiGuard’s Global Threat Intelligence database. If a match is found, the file is flagged as malicious, providing rapid outbreak detection without full signature downloads.

❌ Why Other Options Are Incorrect

A. The FortiGuard VOS can be used only with proxy-based policy inspections. Incorrect.
VOS is not limited to proxy-based inspection. It works with both flow-based and proxy-based AV policies, as long as the FortiGate can generate file hashes and query FortiGuard. Restricting it to proxy-only would reduce flexibility, which is not the case in FortiOS design.

B. If third-party AV database returns a match the scanned file is deemed to be malicious. Incorrect.
VOS relies on FortiGuard’s own Global Threat Intelligence database, not third-party AV databases. Fortinet maintains its own intelligence network and outbreak detection system. Third-party AV databases are not queried by FortiGate in this context.

D. The AV engine scan must be enabled to use the FortiGuard VOS feature. Incorrect.
VOS can operate independently of full AV scanning. It specifically uses file hashes to query FortiGuard, which means even if full signature-based AV scanning is not enabled, VOS can still provide outbreak detection. AV scanning enhances detection but is not a prerequisite for VOS.

📚 Reference:

Fortinet Documentation – FortiGuard Outbreak Protection Service:
“Outbreak Prevention queries FortiGuard with file hashes against the Global Threat Intelligence database to detect emerging threats.”
Fortinet Docs – Outbreak Prevention Service

Explanation:

You must convert the event's known UTC time to the FortiAnalyzer's local time zone for accurate filtering in its GUI. FortiGate logs store timestamps based on the device's local time, but all logs in FortiAnalyzer are normalized and indexed in UTC in the database. The FortiAnalyzer GUI automatically converts your local filter input from its configured time zone back to UTC for searching.
Known Event Time: The event occurred at 20:37:08 UTC.
FortiAnalyzer Time Zone: The FortiAnalyzer appliance is configured for GMT-08:00 (8 hours behind UTC).
Conversion: To find the local time on the FortiAnalyzer, subtract its offset from UTC:
FortiAnalyzer Local Time = 20:37:08 (UTC) - 8 hours = 12:37:08.
Therefore, to find this specific log entry, you must set the time filter in the FortiAnalyzer GUI to 12:37:08.

Why Other Options Are Incorrect

A (20:37:08):
This is the event time in UTC, not the FortiAnalyzer's local time. The GUI expects input in the appliance's configured time zone.

B (10:37:08):
This is the FortiGate's local time (GMT-10). Using this in the FortiAnalyzer (GMT-8) would search for logs from a different UTC moment, yielding no results.

C (17:37:08):
This would correspond to the FortiAnalyzer being at GMT-3, which is the administrator's browser time zone, not the appliance's configured time zone. The GUI uses the appliance's time zone setting for filter input unless explicitly overridden, which is not indicated here.

Reference
Fortinet documentation on log timestamps and FortiAnalyzer time zone handling states that logs are stored in UTC and that the FortiAnalyzer GUI displays and accepts filter times based on the appliance's own configured system time zone.

Explanation:

The provided curl command attempts to update (-X PUT) an SSO group. Let's analyze the options based on standard FortiAuthenticator REST API behavior and the flawed command syntax.

D. The syntax is incorrect because the API calls needs the get method.
This is correct. The customer's goal is to retrieve an SSO group ("SalesGroup"). The command uses -X PUT, which is the HTTP method for updating or creating a resource. To retrieve information, the correct HTTP method is GET. Using PUT with a GET operation will cause a method mismatch error. Furthermore, the URL path and JSON data format are malformed for a simple retrieval.

B. This API call will fail because it requires that API version 2
This is correct. For operations on SSO groups (like api/v1/ssogroup/100/), FortiAuthenticator's REST API requires version 2 (v2) of the API. Using v1 in the endpoint path will result in failure because the ssogroup resource is not available or fully functional under the older API version. The correct endpoint should be /api/v2/ssogroup/.

Why Other Options Are Incorrect

A. Only users with the "Full permission" role can access the REST API
Incorrect. REST API access is controlled by a specific API web service access key, not by the admin user's GUI role permissions. A dedicated key must be generated in the FortiAuthenticator GUI under System > Admin > Administrators > REST API Admin. Any administrator with privileges to generate this key can use it for API calls.

C. If the REST API web service access key is lost, it cannot be retrieved and must be changed.
Incorrect. The FortiAuthenticator GUI does not display the API key in plain text after creation for security reasons. If lost, you cannot retrieve the original key. However, you do not necessarily "change" the existing one; you must generate a new key, which automatically invalidates the old one. The statement is misleading because it implies a change procedure rather than regeneration.

Reference
FortiAuthenticator Administration Guide, REST API chapter, specifies:
The API endpoint for SSO group management is /api/v2/ssogroup/
HTTP methods: GET (retrieve), POST (create), PUT (update), DELETE (remove)
Access requires a valid API key, not a user role.