Important Fortinet NSE4_FGT_AD-7.6 Exam Questions

Answer: C

Explanation:

From the exhibits:

The Web Filter profile is configured with Feature set = Flow-based.

The Firewall policy is configured with Inspection mode = Proxy-based and has Web Filter enabled.

In FortiOS 7.6, security profiles that have a feature set selection (Flow-based vs Proxy-based) must match the inspection mode used by the firewall policy. If the profile's feature set does not match the policy's inspection mode, the profile behavior will not align with what the administrator expects (and in many cases FortiOS will prevent correct use/selection, or the feature behavior will not apply as intended).

That mismatch explains why the configured URL filter entry for www.facebook.com (set to Monitor) is not producing the expected result, and instead the session is being evaluated by category rating and blocked (shown as Malicious Websites on the FortiGuard block page).

Why the other options are not the best fit:

A: A web rating override is not shown in the exhibits, and nothing indicates an override misconfiguration.

C: While the policy inspection mode could be changed, the root cause shown is the profile feature set mismatch (profile is Flow-based).

D: The URL filter action shown is Monitor, which would not produce a block page by itself.

Answer: D

Explanation:

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.

Answer: B

Explanation:

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 accprofile Incorrect. 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 list Incorrect. Admin profile order has no impact on session timeout behavior.

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

Answer: B, D

Explanation:

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.

Answer: D

Explanation:

Based on the exhibit and FortiOS 7.6 Active Authentication (captive portal) behavior, the most likely reason the user is not presented with a login prompt is that DNS is missing from the firewall policy.

What the exhibit shows

The firewall policy configured for active authentication includes:

Source: HQ_SUBNET and Remote-users

Destination: all

Services:

HTTP

HTTPS

ALL_ICMP

Security Profiles: Web filter and SSL inspection enabled

Authentication: Active (user group referenced)

DNS is not included as a service in the policy.

Why DNS is required for active authentication

In FortiOS 7.6, active authentication (captive portal) works as follows:

The user attempts to access a website using a URL (for example, www.example.com).

The client must first perform a DNS lookup to resolve the domain name.

FortiGate intercepts the initial HTTP/HTTPS request and redirects the user to the authentication portal.

If DNS traffic is blocked or not allowed:

The hostname cannot be resolved.

The HTTP/HTTPS request never properly occurs.

FortiGate has nothing to intercept, so the login prompt is never triggered.

This is explicitly documented in the FortiOS 7.6 Authentication and Captive Portal requirements, which state that DNS must be permitted for captive portal--based authentication to function correctly.

Why the other options are incorrect

A . No matching user account exists for this user

Incorrect.

If the user account did not exist, the login page would still appear, but authentication would fail after credentials are entered.

B . The Remote-users group must be set up correctly in the FSSO configuration

Incorrect.

This policy is using active authentication, not FSSO.

FSSO configuration is irrelevant for active authentication login prompts.

C . The Remote-users group is not added to the Destination

Incorrect.

User groups are applied in the Source field for authentication-based policies.

Destination does not accept user groups.