Fortinet NSE4_FGT_AD-7.6 Fortinet NSE 4 - FortiOS 7.6 Administrator Exam Practice Test

From the current HA status, HQ-NGFW-1 is the primary and HQ-NGFW-2 is the secondary.

The administrator then changes these HA parameters:

HQ-NGFW-1: set override disable, set priority 90

HQ-NGFW-2: set override enable, set priority 110

In FGCP (A-P mode), the override (preemption) feature controls whether a higher-priority unit is allowed to take over the primary role.

When override is enabled, the cluster will prefer (and can re-elect) the unit with the highest device priority to become primary (preempting a lower-priority primary when conditions trigger re-election behavior as defined by FGCP).

Here, HQ-NGFW-2 has:

override enabled

higher priority (110) than HQ-NGFW-1 (90)

Therefore, the expected result is that HQ-NGFW-2 becomes the primary.

Why the other options are incorrect:

B is incorrect because it claims HQ-NGFW-2 has lower priority (it is higher: 110 > 90).

C is incorrect because a mismatch in the override setting is not what causes the “configuration out of sync” condition shown in get system ha status (that is about synchronized configuration databases, not a requirement that override values must match to remain in-sync).

D is incorrect because HA settings like override/priority are not synchronized in the way regular configuration objects are; they are device-level HA parameters.

From the HA configuration shown for HQ-NGFW-1:

set memory-based-failover enable

set memory-failover-threshold 70

set memory-failover-monitor-period 50

set memory-failover-sample-rate 10

set memory-failover-flip-timeout 60

set override disable

set priority 200

From the performance status outputs:

HQ-NGFW-1 memory used is 90% (well above the configured threshold of 70%)

HQ-NGFW-2 memory used is about 48.7% (well below the threshold)

What happens in FortiOS 7.6 with memory-based failover

When memory-based failover is enabled, FortiGate monitors memory utilization. If the unit’s memory usage stays above the configured memory-failover-threshold for the configured memory-failover-monitor-period, the cluster triggers a failover away from the unit under memory pressure.

Threshold = 70%

HQ-NGFW-1 is at 90%, so it violates the threshold.

Monitor period = 50 seconds.

The administrator observed for 55 seconds, which is longer than 50 seconds, so the condition is met for long enough to trigger failover.

The memory-failover-flip-timeout 60 is used to prevent rapid back-and-forth role changes (flapping) after a failover decision; it does not prevent the initial failover from occurring once the threshold breach persists for the monitor period.

According to the FortiOS 7.6 High Availability (HA) Administration Guide and FGCP (FortiGate Clustering Protocol) requirements, the correct answers are B and D.

FGCP HA Cluster Mandatory Requirements (FortiOS 7.6)

When forming an HA cluster using FGCP, FortiGate devices must meet several strict compatibility and configuration requirements. Among the options given, the following two are mandatory:

✅ B. They must have the same number of configured VDOMs

In FortiOS HA, all cluster members must have the same VDOM configuration.

This includes:

Same number of VDOMs

Same VDOM names

This is required so configuration synchronization can occur correctly between members.

If VDOM counts differ, HA formation will fail.

✔ This is explicitly required and documented.

✅ D. They must have the same HA group ID

The HA group ID uniquely identifies an HA cluster on the network.

All FortiGate units intended to join the same cluster must share the same HA group ID.

If the group IDs differ, devices will not recognize each other as cluster peers.

✔ This is a fundamental FGCP requirement.

Why the Other Options Are Incorrect

❌ A. They must have the same hard drive configuration

Hard drive presence or size does not have to match for FGCP HA to function.

Disk differences may affect logging behavior, but they do not prevent HA cluster formation.

Therefore, this is not a required condition.

❌ C. They must have the heartbeat interfaces in the same subnet

Heartbeat interfaces must be:

Directly connected

In the same Layer 2 broadcast domain

They do not require IP addressing or being in the same IP subnet.

In many deployments, heartbeat interfaces have no IP addresses at all.

Therefore, “same subnet” is not a documented requirement.

According to the FortiOS 7.6 Administrator Study Guide, the Application Control engine processes traffic by evaluating the Application and Filter Overrides section first, using a top-down matching logic similar to firewall policies. In the provided exhibit, there are two override entries:

Priority 1: A behavior-based filter for Excessive-Bandwidth with the action set to Block.

Priority 2: A vendor-based filter for Apple with the action set to Monitor.

The exhibit titled "Application override configuration" explicitly shows that Apple FaceTime is one of the signatures included within the Excessive-Bandwidth behavior filter. When the FortiGate inspects FaceTime traffic, it matches the first entry (Priority 1) because the signature belongs to the "Excessive-Bandwidth" group. Since the action for this priority is Block, the traffic is dropped immediately.

The phrase "only a few calls" is a common exam distractor; in this context, the "Excessive-Bandwidth" filter refers to the classification of the application (as one that typically consumes high bandwidth) rather than a real-time measurement of the specific session's throughput. Because the engine stops searching once a match is found in the overrides, it never reaches the Priority 2 "Monitor" rule or the general Category settings.

According to the FortiOS 7.6 Administration Guide and Fortinet hardware acceleration (NTurbo) documentation, the correct answer is A.

What NTurbo Is (FortiOS 7.6 – Verified)

NTurbo is a hardware-based acceleration feature available on specific FortiGate models. It is designed to improve antivirus and IPS performance when operating in flow-based inspection mode.

NTurbo works by creating a fast, optimized data path between:

FortiGate ingress interface

IPS/AV engine

FortiGate egress interface

This minimizes CPU involvement and reduces packet traversal overhead.

Why Option A Is Correct

A. For flow-based inspection, NTurbo establishes a dedicated data path to redirect traffic between the IPS engine and FortiGate ingress and egress interfaces.

This is exactly how NTurbo works, as documented:

NTurbo applies to flow-based inspection only

It accelerates IPS and antivirus scanning

It creates a dedicated fast path that bypasses unnecessary processing steps

This significantly improves throughput and lowers latency

This description matches Fortinet’s official explanation of NTurbo.

Why the Other Options Are Incorrect

B. NTurbo creates two inspection sessions

Incorrect. NTurbo does not duplicate sessions; it optimizes the packet path.

C. NTurbo offloads traffic to the content processor (proxy-based)

Incorrect. NTurbo does not apply to proxy-based inspection and does not offload to content processors.

D. NTurbo buffers the whole file and then sends it to the antivirus engine

Incorrect. Buffering entire files is a proxy-based behavior, not NTurbo.

From the exhibits:

System performance output

Memory used: 90%

Free memory: ~5%

Default memory thresholds (FortiOS 7.6)

memory-use-threshold-green 82%

memory-use-threshold-red 88%

memory-use-threshold-extreme 89%

Because memory usage (90%) exceeds the extreme threshold (89%), the FortiGate enters conserve mode.

Effects of conserve mode (FortiOS 7.6 – verified)

B. FortiGate has entered conserve mode.

Correct

When memory usage exceeds the red/extreme threshold, FortiGate automatically enters conserve mode.

This is exactly the condition shown in the system performance output.

D. Administrators can change the configuration.

Correct

Even in conserve mode:

Administrators can still log in (GUI, SSH, console)

Configuration changes are allowed

FortiGate does not lock configuration access during conserve mode.

This behavior is explicitly documented in the FortiOS 7.6 Conserve Mode section.

Why the other options are incorrect

A. Administrators can access FortiGate only through the console port.

Incorrect

Network access (GUI/SSH) is still available in conserve mode unless otherwise restricted.

Console-only access is not a conserve-mode requirement.

C. FortiGate drops new sessions.

Incorrect (as a general statement)

FortiGate may drop or bypass new inspection-required sessions depending on fail-open/fail-close settings.

It does not universally drop all new sessions, so this statement is not always true.

According to the FortiOS 7.6 Troubleshooting and Administration guides, the diagnose debug flow command provides a step-by-step trace of how the FortiGate unit processes a packet.

First, the line "find a route: flag=00000000 gw-0.0.0.0 via port2" indicates that during the routing table lookup, the FortiGate matched the destination against its default route (represented by 0.0.0.0) and determined that the egress interface is port2. This confirms that the default gateway for this traffic is reachable via port2 (Statement A).

Second, the debug trace concludes with the messages "policy-2 Is matched, act-drop" and "Denied by forward policy check (policy 2)". This explicitly indicates that the packet successfully matched the criteria for firewall policy ID 2, and the action configured for that policy is set to Deny (Statement D).

Statement B is incorrect because a Reverse Path Forwarding (RPF) failure would be indicated by a specific "reverse path check fail, drop" message, which is absent here. Statement C is incorrect because the output shows "proto=1", which corresponds to ICMP (Ping) traffic. UDP traffic would be identified as protocol 17.

In FortiSASE Secure Internet Access (SIA) agent-based mode, traffic steering and security enforcement rely on components integrated with the FortiClient agent.

Components used in SIA agent-based mode

A. FortiSASE Firewall-as-a-Service (FWaaS)

Correct.

FWaaS is a core security component of FortiSASE.

It enforces firewall policies, security inspection, and access control for agent-based users.

All user traffic tunneled by the agent is inspected by FWaaS.

C. VPN policies

Correct.

In agent-based mode, the FortiClient establishes a secure tunnel to FortiSASE.

VPN policies define:

Authentication

Access control

Traffic steering

These policies are fundamental to agent-based connectivity.

Why the other options are incorrect

B. Proxy auto-configuration (PAC) filePAC files are used in agentless or proxy-based modes, not agent-based SIA.

D. FortiExtenderFortiExtender is a WAN extension device and is unrelated to FortiSASE SIA agent-based architecture.

Comprehensive and Detailed 150 to 200 words of Explanation From Exact Extract of FortiOS 7.6 documents:

According to FortiOS 7.6 High Availability documentation, the FortiGate Cluster Protocol (FGCP) provides robust mechanisms for both link monitoring and stateful data synchronization. Link failover is a primary trigger for cluster renegotiation; if a monitored interface goes down—including when an administrator manually sets the interface to administratively down—the primary unit's priority is effectively reduced, triggering a failover to a secondary unit to ensure path continuity.5 This is a standard method for testing HA failover behavior.

Furthermore, to achieve a seamless stateful failover where active sessions are not dropped, the FortiGate performs incremental synchronization of critical runtime data.6 This specifically includes Forwarding Information Base (FIB) entries, which represent the compiled routing table, and IPsec Security Associations (SAs).7 By synchronizing IPsec SAs, the secondary unit 8can resume encrypted tunnels immediately after a failover without requiring a f9ull IKE re-negotiation.10 Statement A is incorrect because in-band and out-of-band management can coexist using reserved management interfaces and management-ip settings.11 Statement C is incorrect because while heartbeat interfaces use link-local IPs in the 169.254.0.x range, the specific IP .2 is not universally required for all heartbeats and depends on the number of cluster members and serial numbers.

From the exhibits:

The firewall policy has NAT enabled and is configured to Use Dynamic IP Pool.

The selected IP pool (Internet-pool) is configured as:

Type: One-to-One

External IP Range: 100.65.0.110–100.65.0.111 (only two public IPs)

PC1 and PC2 can access the internet because each one-to-one NAT mapping consumes one public IP from the pool. When PC3 is added, there is no third public IP available in the pool, so FortiGate cannot allocate a one-to-one mapping for PC3 and the session fails.

FortiOS behavior here is standard: with one-to-one IP pools, the available pool size limits how many distinct internal sources can be translated concurrently (depending on allocation and sessions), and a pool with only two IPs will not reliably support three separate hosts needing translations.

Therefore, the administrator can fix this in two valid ways:

B. In the IP pool configuration, set end ip to 100.65.0.112.

This expands the pool by adding an additional public IP address, making three public IPs available (.110, .111, .112), so PC3 can be assigned an address for one-to-one NAT.

D. In the IP pool configuration, set type to overload.

Changing the pool type to overload enables PAT (many-to-one), allowing multiple internal hosts (PC1, PC2, PC3) to share the pool address(es) using different source ports. This removes the “one public IP per internal host” limitation inherent to one-to-one pools.

Why the other options are not correct:

A. Multiple Interface Policies is unrelated to IP pool exhaustion and does not solve NAT allocation limits.

C. match-vip affects VIP matching behavior for destination NAT/virtual IP usage and does not address the source NAT pool shortage causing PC3 to fail.

In FortiOS 7.6, web filter profiles are inspection-mode dependent. Certain advanced web filtering features—such as daily category usage quota—are only supported when the firewall policy is operating in proxy-based inspection mode.

Why the profile is not visible

The profile restrictmedia-profile includes a daily category usage quota.

Daily quotas are a proxy-based web filtering feature.

If the firewall policy is configured with:

Inspection mode: Flow-based

Then FortiGate will not display proxy-only web filter profiles in the Web Filter drop-down list.

FortiGate automatically filters the available profiles based on feature compatibility with the policy’s inspection mode.

This behavior is explicitly documented in the FortiOS 7.6 Web Filtering and Inspection Mode Compatibility sections.

Why the other options are incorrect

A. Already referenced in another firewall policyWeb filter profiles can be reused across multiple policies. This does not hide them.

B. Firewall policy is in no-inspection mode instead of deep-inspectionSSL inspection depth affects HTTPS visibility, not whether a web filter profile appears in the drop-down list.

C. Naming convention restrictionFortiOS does not restrict profile selection based on naming conventions.

Based on the FortiOS 7.6 Authentication and User Group documentation, the correct answer is A.

Meaning of “Include in every user group” (FortiOS 7.6)

When configuring a RADIUS server on FortiGate, enabling Include in every user group has a very specific and documented effect:

The configured RADIUS server object is automatically added to all FortiGate user groups.

As a result, any user who successfully authenticates against that RADIUS server becomes a valid member of every FortiGate user group, unless additional group filtering (such as RADIUS attributes) is applied.

This simplifies configuration when the same external authentication source must be accepted across multiple firewall policies that reference different user groups.

This behavior is explicitly described in the FortiOS 7.6 Administrator Guide under RADIUS authentication servers and user groups.

Why Option A is Correct

FortiGate user groups can include:

Local users

LDAP servers

RADIUS servers

Enabling Include in every user group causes FortiGate to:

Insert the RADIUS server into all existing and future FortiGate user groups

Therefore, all users authenticating via this RADIUS server are implicitly allowed in every FortiGate user group.

This is exactly what option A describes.

Why the Other Options Are Incorrect

B: FortiGate does not push users or groups into the RADIUS server. Authentication is always initiated by FortiGate toward RADIUS.

C: FortiGate does not manage or modify RADIUS-side group definitions.

D: LDAP and RADIUS user groups are separate authentication mechanisms; this setting does not merge or affect LDAP groups.

From the routing table in the exhibit, there is already a static route for 172.20.1.0/24 pointing out port3 with:

Distance = 9

Priority = 2

Type = Static

In FortiOS, route selection prefers (in order) the route with the lowest administrative distance to a destination. Therefore, to make traffic to 172.20.1.0/24 go through port2 only, the administrator must ensure the port2 static route is more preferred than the existing port3 route.

Why C is correct

C. The existing static route through port3 must have the distance set to 11.

If the existing port3 route distance is increased to 11, then a new port2 route with distance 9 will be preferred (9 < 11). This makes the port3 route a backup route instead of the active one.

Why D is correct

D. The new static route must have the distance set to 9

Setting the new port2 route distance to 9 (and increasing the port3 route to 11 as in option C) ensures FortiGate selects the port2 route as the best route for 172.20.1.0/24.

Why A and B are not correct

A (priority 3): By itself it does not guarantee selection over the existing route, and FortiOS route choice is driven primarily by distance.

B (metric 1): Metric is not the primary selector for static route preference compared to administrative distance in this scenario.

So the two criteria that achieve the objective are:

Make the existing port3 route less preferred by increasing its distance (C)

Ensure the new port2 route uses the preferred distance (D)

With a dialup IPsec VPN on FortiGate, when add-route is enabled, FortiGate will only install the corresponding route when it has enough negotiated information from the tunnel. In FortiOS 7.6, that means the route is tied to the Phase 2 (Quick Mode) selectors and is created dynamically when the IPsec SA is actually up.

B. The administrator must ensure phase 2 is successfully established

This is required. FortiGate does not install the add-route route just because Phase 1 exists or because the configuration is present. The route is added when the tunnel is effectively usable, which requires Phase 2 (IPsec SA) to be up. If Phase 2 is not established, there is no active SA and FortiGate will not inject the related route into the routing table.

So, if the static route is not showing, one correct explanation is that Phase 2 is not up.

C. The administrator must define the remote network correctly in the phase 2 selectors

This is also required. For dialup tunnels, FortiGate derives what route to add from the remote subnet(s) defined in the Phase 2 selector (proxy ID). If the remote network in Phase 2 is missing, incorrect, or too broad/too narrow in a way that prevents negotiation, the tunnel either won’t come up (so no route), or the route that would be installed won’t match what the administrator expects.

So, another correct explanation is that the Phase 2 remote network is not correctly defined, preventing the correct route from being created.

Why the other options are incorrect

A. Policy route instead of a static route

Add-route does not require policy routes. It is specifically a feature that injects a route (route-table entry) associated with the IPsec tunnel/SA and the Phase 2 selector networks.

D. Enable a dynamic routing protocol

Dynamic routing protocols (OSPF/BGP/RIP) are not required for add-route. Add-route is independent of dynamic routing and works by installing routes locally based on the negotiated selectors.

In FortiOS 7.6, GUI session inactivity timeout behavior for administrators is controlled by admin profiles, not by general access permissions or profile ordering.

How GUI idle timeout works in FortiOS 7.6

FortiGate has a global admin timeout (admintimeout), but

Admin profiles can override this value using the Override idle timeout setting.

When Override idle timeout is enabled in an admin profile, the timeout value defined inside that profile takes precedence over the global setting.

The exhibit shows that the NOC team logs in using the NOC_Access admin profile. Therefore, to prevent their GUI sessions from disconnecting too quickly during inactivity, the timeout must be adjusted within that specific admin profile.

Why option B is correct

B. Increase the value of the Override Idle Timeout parameter in the NOC_Access admin profile.

This directly controls how long GUI sessions remain active when users assigned to NOC_Access are idle.

It affects only the NOC team, which matches the requirement precisely.

This is the recommended and documented approach in FortiOS 7.6.

Why the other options are incorrect

A. Increase admintimeout under config system accprofileIncorrect. admintimeout is a global admin setting, not configured under accprofile, and it would affect all administrators, not just NOC users.

C. Move NOC_Access to the top of the listIncorrect. Admin profile order has no impact on session timeout behavior.

D. Assign super_admin roleIncorrect and insecure. Super_admin does not control idle timeout and would unnecessarily grant full privileges.

From the exhibits:

The Application Control sensor has these key settings:

Application and Filter Overrides

Priority 1: Excessive-Bandwidth (Type: Filter) with Action Block

Priority 2: Google (Type: Filter) with Action Monitor

Category actions shown include Social Media set to Block (this category includes Facebook).

The firewall policy is using:

Flow-based inspection

Application control enabled (profile: default)

Deep inspection enabled (helps identify applications inside HTTPS)

Logging enabled

FortiOS applies Application Control as follows (top-down within the Application Control profile):

Overrides are evaluated by priority (highest priority first).

The first matching override determines the action (block/monitor/allow) for that traffic.

Category-based actions apply to applications that fall into those categories unless an override matches first.

Why A is correct

A. YouTube access is blocked based on Excessive-Bandwidth Application and Filter override settings.

The profile explicitly blocks the Excessive-Bandwidth behavior filter at the highest override priority.

When YouTube traffic is detected as matching the Excessive-Bandwidth behavior, FortiGate will apply the Block action due to the override.

Because this is a priority override, it is enforced before lower-priority entries.

Why B is correct

B. Facebook access is blocked based on the category filter settings.

The Application Sensor shows Social Media configured with a Block action.

Facebook is categorized under Social Media, so it will be blocked when matched by Application Control.

Why C is not correct

C. Facebook access is allowed but you cannot play Facebook videos...

Since the Social Media category is set to Block, Facebook would be blocked at the category level (not merely video playback).

Why D is not correct

D. YouTube search is allowed based on the Google override...

The Google override action is Monitor, not Allow.

“Monitor” logs/detects but does not override a block condition to “allow” traffic.

Also, YouTube traffic is not guaranteed to be treated as “Google” in a way that would permit it, and any matching block condition (such as Excessive-Bandwidth) would still take precedence.

From the exhibits:

A VIP named VIP-WEB-SERVER is configured on WAN (port2) with:

External IP: 100.65.0.200

Mapped (internal) IP: 10.0.11.50

Port forwarding enabled (TCP)

External service port: 443

Map to IPv4 port: 4443

The inbound firewall policy Web_Server_Access is:

From WAN (port2) to LAN (port4)

Destination: VIP-WEB-SERVER

Service: HTTPS

NAT: Disabled (meaning no source NAT is applied)

What happens to the packet

A host 100.65.1.111 sends TCP SYN dst-port 443 to 100.65.0.200.

When FortiGate matches the VIP and forwards traffic to the internal server, FortiGate performs destination NAT (DNAT) based on the VIP:

Source IP is unchanged because policy NAT is disabled:

Source remains 100.65.1.111

Destination IP is translated by the VIP:

Destination becomes 10.0.11.50

Destination port is translated by the VIP port-forward:

Destination port becomes 4443

Therefore, at the time FortiGate forwards the packet to the destination (internal server), it will be:

Source address: 100.65.1.111

Destination address: 10.0.11.50

Destination port: 4443