NSE4_FGT_AD-7.6 Fortinet NSE 4 - FortiOS 7.6 Administrator Questions and Answers

“To perform SSL inspection on traffic flowing through the FortiGate device, you must allow the traffic with a firewall policy and apply an SSL inspection profile to the policy. Note that an SSL inspection profile alone will not trigger a security inspection. You must combine it with other security profiles like Antivirus, Web Filter, Application Control, or IPS.”

“By default, firewall policies are set with the no-inspection SSL profile. Therefore, any encrypted traffic flows through uninspected... For antivirus or IPS control, you should use a deep-inspection profile. ”

“When you use deep inspection, FortiGate impersonates the recipient of the originating SSL session, and then decrypts and inspects the content to find threats and block them . It then re-encrypts the content and sends it to the real recipient. Deep inspection protects from attacks that use HTTPS and other commonly used SSL-encrypted protocols...”

Technical Deep Dive:

The correct answer is D . HTTP and FTP are working because FortiGate can inspect those payloads directly with the antivirus profile. HTTPS is different because the traffic is encrypted. If the firewall policy uses only certificate inspection or another non-decrypting SSL mode, FortiGate can identify certificate/SNI information, but it cannot see the downloaded file contents. Without decrypting the HTTPS session, the antivirus engine never receives the payload to scan, so EICAR or other malware can pass.

Why the other options are wrong:

A is not the issue here. The exhibit shows the antivirus profile and policy are already aligned for proxy-based operation, and the failure is specific to HTTPS visibility.

B is wrong because web filter is not required for antivirus scanning.

C is wrong because firewall policies commonly use ACCEPT with security profiles; the antivirus engine can still block the file after policy match. The study guide explicitly says ACCEPT allows the session and then applies antivirus scanning and other packet-processing features.

To fix it, apply deep-inspection on the firewall policy:

config firewall policy

edit < policy-id >

set ssl-ssh-profile " deep-inspection "

set av-profile " HTTP_AV_Profile "

next

end

On real FortiGate hardware, this also has performance implications. Simple flow handling can often stay on accelerated paths, but full SSL deep inspection forces decryption and content scanning through the inspection engine, increasing CPU/WAD workload.

Phase 1 being up confirms the two FortiGate devices can authenticate and build the IKE SA. Phase 2 failing indicates the IPsec (Quick Mode) SA negotiation is failing due to mismatched Phase 2 parameters.

From the exhibit, the Phase 2 mismatches that would prevent SA establishment are:

1) Phase 2 selectors must mirror each other (Proxy IDs)

HQ-NGFW Phase 2 selector shows:

Local: 10.0.11.0/24

Remote: 172.20.1.0/24

BR1-FGT Phase 2 selector shows:

Local: 172.20.1.0/24

Remote: 10.11.0.0/24 ⟵ does not match HQ’s local subnet (10.0.11.0/24)

In FortiOS, Phase 2 comes up only when the peers’ selectors (proxy IDs) match as opposite pairs (local on one side = remote on the other).

✅ Fix: A. On BR1-FGT, set Remote Address to 10.0.11.0/255.255.255.0.

2) Phase 2 proposal must match (encryption/authentication)

HQ-NGFW shows encryption AES128 (with SHA1)

BR1-FGT shows encryption AES256 (with SHA1)

For Phase 2 to establish, both peers must have at least one common proposal (same encryption and authentication settings). With one side set to AES128 and the other to AES256, there is no match.

✅ Fix: D. On HQ-NGFW, set Encryption to AES256.

Why the other options are not correct

B. Enable Diffie-Hellman Group 2: The exhibit’s mismatch is not resolved by adding DH group 2, and DH group must match when PFS is enabled. This option does not align the peers based on what’s shown.

C. Set Seconds to 43200: Phase 2 lifetime mismatches typically do not prevent Phase 2 from coming up (the negotiated lifetime can be adjusted by the peers). The hard blockers here are the selectors and proposal mismatch.

From the exhibits, there are three relevant firewall policies from LAN (port4) to WAN (port2), each using a different IP pool for source NAT:

TCP traffic

Service: ALL_TCP

Destination: BR1-FGT

IP Pool: SNAT-Pool → 100.65.0.49

PING traffic

Service: PING

Destination: all

IP Pool: SNAT-Remote1 → 100.65.0.99

IGMP traffic

Service: IGMP

Destination: all

IP Pool: SNAT-Remote → 100.65.0.149

The user on HQ-PC-1 (10.0.11.50) is pinging BR1-FGT (100.65.1.111). In FortiOS, policy matching is based on (among other fields) source, destination, and service, and the first matching policy in top-down order is applied.

Because the traffic is ICMP echo (ping), it matches the policy named PING traffic (service PING, destination all). That policy explicitly uses Use Dynamic IP Pool with SNAT-Remote1, which is configured with external IP 100.65.0.99.

Therefore, the source NAT IP used for this ping is 100.65.0.99.

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.

“The Security Rating page is separated into three major scorecards: Security Posture, Fabric Coverage, and Optimization, which provide an executive summary of the three largest areas of security focus in the Security Fabric .” ( Fortinet Document Library )

“On the root FortiGate , go to Security Fabric > Security Rating.” ( Fortinet Document Library )

“The Info and Compliance tab includes the security controls used for the test and links to specific FSBP, PCI, or CIS compliance policies .” ( Fortinet Document Library )

“A new Security Rating Insights feature provides immediate access to crucial security information. Hover over any tested object to reveal a tooltip...” and “Objects, such as firewall policies, with security rating recommendations are highlighted... click Security Rating Insights to display relevant issues.” ( Fortinet Document Library )

Technical Deep Dive:

The correct answers are B and C .

B is correct because Security Rating is viewed from the root FortiGate and its scorecards provide an executive summary for the Security Fabric, not just an isolated downstream unit. The root device is the point from which the Security Fabric summary is presented. ( Fortinet Document Library )

C is correct because the Security Rating results include an Info and Compliance view with references to PCI compliance policies. That means PCI-related compliance results are part of the Security Rating reporting associated with the security categories, including Security Posture. ( Fortinet Document Library )

Why the others are incorrect:

A is incorrect because Fortinet documents state there is a base set of free checks and a separate licensed set of checks. A license is not required just to obtain the executive summary view itself. ( Fortinet Document Library )

D is incorrect because Security Rating Insights are not limited to the Security Rating page. Fortinet documents show they also appear as tooltips and buttons on other GUI objects and pages . ( Fortinet Document Library )

“The only security features you can apply using SSL certificate inspection mode are web filtering and application control... Note that while offering some level of security, certificate inspection does not allow FortiGate to inspect the flow of encrypted data.”

“To perform SSL inspection on traffic flowing through the FortiGate device, you must allow the traffic with a firewall policy and apply an SSL inspection profile to the policy... For antivirus or IPS control, you should use a deep-inspection profile.”

“When you use deep inspection, FortiGate impersonates the recipient of the originating SSL session, and then decrypts and inspects the content to find threats and block them. It then re-encrypts the content and sends it to the real recipient.”

Technical Deep Dive:

The exhibit shows that the policy is allowing HTTPS and the SSL/SSH inspection profile is certificate-inspection , not deep-inspection . That is the key issue. With certificate inspection, FortiGate can inspect only SSL metadata such as the certificate and SNI/hostname context; it cannot decrypt the HTTPS payload itself. Because EICAR is detected by antivirus through payload inspection, FortiGate must see the file contents. Without deep SSL inspection, the antivirus engine never gets the decrypted payload, so the file can pass even though the antivirus profile is attached.

Option A is incorrect because FortiGate firewall policies often use ACCEPT + security profile enforcement ; the session can still be blocked by antivirus after policy match. Option B is incorrect because web filter is not required for antivirus detection. Option C is incorrect because the real requirement is deep SSL inspection , not specifically proxy-based mode; full SSL inspection is the deciding factor here.

In practice, to block EICAR over HTTPS, you would apply a deep-inspection SSL profile to the policy, for example:

config firewall policy

edit < policy-id >

set inspection-mode flow

set av-profile " default "

set ssl-ssh-profile " deep-inspection "

next

end

On real hardware, this also matters for performance design. Simple firewall/NAT sessions are often NP fast-pathed, but once you enable deep SSL inspection and content scanning, traffic is typically handed to CPU/WAD/content-inspection path for decryption and scanning, so throughput is lower than certificate-inspection or no-inspection.

“To reduce the number of log messages generated and improve performance, you can enable a session table entry of dropped traffic. This creates the denied session in the session table and, if the session is denied, all packets for that session are also denied. This ensures that FortiGate does not have to perform a policy lookup for each new packet matching the denied session, which reduces CPU usage and log generation.”

“The CLI command is ses-denied-traffic. You can also set the duration for block sessions. This determines how long a session will be kept in the session table by setting block-session-timer in the CLI. By default, it is set to 30 seconds.”

Technical Deep Dive:

The correct answers are A and B .

When set ses-denied-traffic enable is configured, FortiGate creates a session-table entry for denied traffic . That means once traffic is denied, subsequent packets that belong to the same denied flow do not need a full policy lookup again. FortiGate can drop them immediately based on the existing denied-session entry. That directly confirms B .

Because FortiGate no longer re-evaluates every repeated denied packet in the same way, the device generates fewer logs and uses less CPU for repeated denied traffic. That is exactly why A is also correct.

Why the other two are wrong:

C is incorrect because block-session-timer 30 means 30 seconds , not 30 minutes. The denied session entry is kept in the session table for that duration.

D is incorrect because these settings do not disable session helpers. They only control how denied traffic is tracked in the session table.

In operational terms, this feature is useful when a host repeatedly retries traffic that FortiGate is already denying. Instead of doing a fresh lookup for every retry, FortiGate caches the denied decision temporarily and drops the repeated packets faster.

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.

“As previously stated, collector agent-based polling mode has three methods (or options) for collecting login information. The order on the slide from left to right shows most recommend to least recommended:

• WMI ...

• WinSecLog ...

• NetAPI ...”

Technical Deep Dive:

The correct three AD polling methods are WMI, WinSecLog, and NetAPI . These are the collector-agent polling options FortiGate FSSO uses against Windows domain controllers. WMI is generally the most efficient because the DC returns requested login events directly. WinSecLog polls Windows Security Event Logs and is typically more reliable than NetAPI for not missing recorded logons. NetAPI can be faster, but it is more prone to missing events under load because it depends on temporary session information rather than persistent security logs.

Why the other options are wrong:

DNS reverse lookup is not one of the three AD polling methods. DNS is used by FSSO to resolve workstation names to IP addresses and to track IP changes, but it is not itself a polling method for collecting AD logon events. FSSO REST API is also not one of the documented collector-agent AD polling methods in the study guide.

From an operational standpoint, FSSO login collection and workstation verification are separate functions. The collector agent may still rely on DNS and workstation checks after a login is learned, but the actual AD polling methods remain only WMI, WinSecLog, and NetAPI . On a FortiGate, when troubleshooting FSSO behavior, you would typically validate the collector feed and user cache with commands such as:

diagnose debug authd fsso list

diagnose debug authd fsso server-status

Those commands help confirm whether the users gathered by the collector through one of those three polling methods are reaching FortiGate correctly.

Exact Extract:

“In IKEv1, there are two possible modes in which the IKE SA negotiation can take place: main, and aggressive mode. Settings on both ends must agree; otherwise, phase 1 negotiation fails and both IPsec peers are not able to establish a secure channel.”

“When both peers know each other ' s IP address or FQDN, you may want to use main mode to take advantage of its more secure negotiation. In this case, FortiGate can identify the remote peer by its IP address and, as a result, associate it with the correct IPsec tunnel.”

“FortiGate supports three DPD modes... The default DPD mode is On Demand .”

“ Diffie-Hellman (DH) ... is used during IKE SA negotiation. The use of DH in phase 1 is mandatory and can’t be disabled . You must select at least one DH group.”

Technical Deep Dive:

The correct answers are B and C .

B is correct because phase 1 fails when IKE mode settings do not match between peers. The study guide explicitly says phase 1 settings on both ends must agree. Since this is a static site-to-site tunnel and both peers know each other’s IP addresses, Main (ID protection) is the appropriate mode.

C is correct based on the exhibit: BR1-FGT appears bound to the wrong physical interface. The screenshot shows Interface = port1 , while the diagram/answer choice indicates the tunnel should be using port2 . If the phase 1 is bound to the wrong WAN interface, FortiGate sends IKE packets out the wrong path and phase 1 will not come up.

Why the others are not the fix:

A is not correct because DH is mandatory in phase 1. The issue is not “disable DH group 2” by itself; the real requirement is that the peers negotiate a compatible proposal. The option as written is not the proper corrective action from the guide.

D is not correct because DPD does not determine whether phase 1 can initially establish. It is a tunnel health/failure-detection feature after negotiation behavior, and On Demand is already the default mode.

“When you enable reliable logging on FortiGate, the log transport delivery method changes from UDP to TCP. TCP provides reliable data transfer, guaranteeing that the transferred data remains intact and arrives in the same order in which it was sent.”

“Optionally, if using reliable logging, you can encrypt communications using SSL-encrypted OFTP traffic, so when a log message is generated, it is safely transmitted across an unsecured network.”

Technical Deep Dive:

The correct answer is C . The study guide explicitly ties reliable logging to TCP transport and optionally to SSL-encrypted OFTP . Among the choices, the padlock icon is the only one that meaningfully indicates secure, reliable log transport behavior. A green check icon usually indicates that the FortiGate–FortiAnalyzer connection is simply up , not specifically that reliable logging is enabled. Interface status being up is unrelated, and real-time logging mode describes delivery behavior, not the reliable transport indicator itself.

So, exam-wise, the best answer is C .

From the CLI perspective, reliable logging changes the transport from UDP to TCP, and with encryption enabled it uses SSL-protected OFTP. That is why the GUI indicator associated with secure transport is the most relevant visual clue here.

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.

According to the FortiOS 7.6 Administrator Study Guide, while there is a global administrative idle timeout setting that applies to all users by default (typically 5 minutes), FortiOS allows for granular control through Administrator Profiles . The Override Idle Timeout feature is specifically designed to allow different timeout values for different access profiles, which is ide 1 al for environments like a Network Operations Center (NOC) where persistent monitoring is required. 23

To implement this, the administrator must modify the s 4 pecific access profile settings. By using the command config system accprofile 5 and editing the NOC_Access profile, the administrator can enable the admintimeout-override and then increase the admintimeout value (Statement D). This configuration ensures that only the users assigned to that specific profile benefit from the extended session duration, maintaining a higher security posture for other administrative accounts that still follow the global timeout. Other options, such as changing the profile order (A) or assigning the super_admin role (C), do not address the specific requirement for inactivity timeout management. Option B is incorrect as " offline value " is not a standard parameter for this feature.

According to the FortiOS 7.6 Security Fabric documentation and Study Guide, several conditions must be met for a downstream FortiGate to successfully join a Security Fabric.

First, the Upstream FortiGate IP/FQDN configured on the downstream device must point to the IP address of the interface on the upstream device that is listening for fabric connections. In the provided logical topology, the Fabric Root (HQ-NGFW-1) uses port4 with the IP 10.0.11.254 to connect to the internal segmentation firewalls (ISFWs). Since HQ-ISFW-2 is in the same subnet as HQ-ISFW, it is physically and logically connected to the network segment serviced by port4. Therefore, the current configuration of 10.0.13.254 (which is port6, likely the WAN side) is incorrect, and it must be set to 10.0.11.254 (Statement A).

Second, once the downstream device successfully reaches the upstream device, it enters a Pending state. For security purposes, FortiOS does not allow devices to join the fabric automatically; the administrator of the upstream device (in this case, HQ-ISFW or the root) must manually authorize the new device (Statement C) in the Fabric Management console. Until this authorization is granted, the status will remain " Pending " and no fabric data will be synchronized. Statements B and D are incorrect as SAML settings do not block the initial fabric join, and the management IP should be the local device ' s IP, not the upstream ' s IP.

“ Rate-based IPS signatures also allows you to detect anomalies, which are unusual behaviors in the network...”

“There are two ways to add predefined signatures to an IPS sensor. One way is to select the signatures individually... The second way to add a signature to a sensor is using filters.”

“ You can also add rate-based signatures to block specific traffic when the threshold is exceeded. On the CLI, If you set the command rate-mode to periodical, FortiGate triggers the action when the threshold is reached during the configured Duration time period. ”

Technical Deep Dive:

The correct answer is C. Use IPS signatures, rate-mode periodical option.

The guide is explicit that this behavior belongs to rate-based IPS signatures . The question asks for blocking traffic when a signature is triggered a certain number of times within a defined interval. That is exactly what rate-mode periodical does: it evaluates the trigger count over the configured duration window and then applies the configured IPS action when the threshold is met.

Why the other options are wrong:

A is wrong because rate-mode 60 is not the documented syntax or method.

B is wrong because packet logging records packets; it does not implement threshold-based blocking logic.

D is wrong because the guide ties rate-mode periodical to rate-based signatures , not to IPS filters as the mechanism for this threshold behavior.

Operationally, this is used for anomaly-style detection, similar in concept to lightweight rate-based protection. A typical CLI pattern is along these lines:

config ips sensor

edit " custom-ips "

config entries

edit 1

set rule < signature_id >

set rate-mode periodical

set rate-count < threshold >

set rate-duration < seconds >

set action block

next

end

next

end

This works best when applied only to relevant protocols and signatures, because broad use of rate-based signatures can consume more resources and increase false-positive risk.

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.

In FortiOS 7.6, SD-WAN Performance SLAs are used to measure link quality and influence SD-WAN rule decisions. The following three statements are true.

C. All the SLA targets can be configured.

True

SD-WAN Performance SLAs allow administrators to configure:

Latency

Jitter

Packet loss

Mean Opinion Score (MOS) (for voice)

Threshold values for these metrics are fully configurable per SLA.

This is explicitly documented in the SD-WAN Performance SLA configuration section.

D. They are applied in an SD-WAN rule lowest cost strategy.

True

Performance SLAs are commonly used with the Lowest Cost (SLA-based) strategy.

In this strategy:

FortiGate selects the lowest-cost link that meets the SLA requirements.

If a link violates the SLA, it is excluded from selection.

E. They can be measured actively or passively.

True

FortiOS supports:

Active probing (synthetic probes such as ping/HTTP)

Passive measurement (based on real traffic statistics)

Administrators can choose how SLAs are measured depending on the deployment and requirements.

Why the other options are incorrect

A. They rely on session loss and jitter.

Incorrect

SLAs measure packet loss, latency, and jitter.

Session loss is not an SLA metric in FortiOS.

B. They monitor the state of the FortiGate device.

Incorrect

Performance SLAs monitor link quality, not FortiGate system health or device state.

With full SSL inspection, FortiGate performs a man-in-the-middle process: it decrypts the HTTPS session, inspects it, then re-encrypts it. To do this, FortiGate presents a substitute certificate to the client, signed by the CA certificate configured in the SSL/SSH inspection profile (for example, Fortinet_CA_SSL or a custom enterprise CA).

Browsers will show certificate warning errors when the issuing CA is not trusted by the client device/browser trust store. This only happens for HTTPS because certificates are used in TLS; HTTP has no certificate exchange, so no warning appears.

Why the other options are incorrect:

A: Allowing invalid server certificates affects whether FortiGate blocks/permits connections to sites with bad certs; it does not fix the client warning about FortiGate’s substituted cert.

B: Proxy vs flow inspection mode does not inherently cause certificate warnings; the warning is about trust of the signing CA.

D: Missing extensions is not the typical reason across “any HTTPS website”; the standard reason is the client does not trust the FortiGate inspection CA

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.

“You may need to exempt traffic from SSL inspection if it is causing problems with traffic, or for legal reasons.”

“Performing SSL inspection on a site that is enabled with HTTP Strict Transport Security (HSTS), for example, can cause problems with traffic. Remember, the only way for FortiGate to inspect encrypted traffic is to intercept the certificate coming from the server and generate a temporary one. After FortiGate presents the temporary SSL certificate, browsers that use HSTS refuse to proceed.”

“Laws protecting privacy might be another reason to bypass SSL inspection. For example, in some countries, it is illegal to inspect SSL bank-related traffic. Configuring an exemption for sites is simpler than setting up firewall policies for each individual bank. You can exempt sites based on their web category, such as Finance and Banking...”

“The predefined deep-inspection and custom-deep-inspection profiles exclude some web categories—Finance and Banking, and Health and Wellness—and some FQDN addresses...”

Technical Deep Dive:

The correct answers are B and D .

B is correct because the study guide explicitly says SSL inspection may be bypassed for legal reasons , especially where privacy laws restrict inspection of sensitive categories such as Finance and Banking . The same privacy rationale also explains why Health and Wellness is commonly exempted.

D is correct because some sites break under deep inspection due to HSTS . FortiGate must generate and present a temporary certificate during full SSL inspection, and browsers enforcing HSTS can reject that interception flow. That is why some sites are exempted from deep inspection.

Why the others are wrong:

A is not stated in the guide.

C refers to the separate Reputable websites option, which is a FortiGuard-maintained allowlist feature, not the reason the predefined categories shown in the exhibit are excluded.

From an operational standpoint, this is a classic balance between security visibility and application/legal compatibility . Deep inspection gives FortiGate payload visibility, but it can interfere with pinned-certificate/HSTS behavior and can violate privacy policy for regulated content.

In FortiOS 7.6, when a FortiGate is operating in NAT mode, physical interfaces that participate in traffic forwarding (such as LAN and DMZ) must meet certain fundamental requirements.

Correct statements

D. Both interfaces must have IP addresses assigned.

Correct

In NAT mode, FortiGate operates as a Layer-3 device.

Every interface that forwards traffic must have an IP address.

Without an IP address:

The interface cannot participate in routing

Firewall policies cannot be applied correctly

This is a mandatory requirement.

C. Both interfaces must have directly connected routes on the routing table.

Correct

When an IP address is assigned to an interface, FortiGate automatically installs a connected route for that subnet in the routing table.

These connected routes are required so FortiGate:

Knows how to reach the locally attached networks

Can forward traffic between LAN and DMZ

While administrators do not manually create these routes, their presence is required for correct operation.

Why the other options are incorrect

A. Both interfaces must have DHCP enabled and roles assigned.

Incorrect

DHCP is optional; interfaces can use static IPs.

Interface roles (LAN, DMZ, WAN) are administrative/GUI aids, not functional requirements.

B. Both interfaces must have the interface role assigned.

Incorrect

Interface roles affect GUI grouping and some default behavior.

They are not required for NAT mode operation or traffic forwarding.

“FSSO is a software agent that enables FortiGate to identify network users for security policies or for VPN access, without asking for their username and password. When a user logs in to a directory service, the FSSO agent sends FortiGate the username, the IP address , and the list of groups that the user belongs to. FortiGate uses this information to maintain a local database of usernames, IP addresses , and group mappings.”

“To display the list of FSSO users that are currently logged in, use the CLI command diagnose debug authd fsso list . For each user, the user name, user group, IP address , and the name of the workstation from which they logged in shows.”

“You can monitor users who authenticate through your firewall policies using the Dashboard > Assets & Identities > Firewall Users page. It displays the user, user group, duration, IP address , traffic volume, and authentication method.”

Technical Deep Dive:

The first thing to verify is whether FortiGate has actually learned the user correctly in its FSSO active users table , especially the user-to-IP mapping . FSSO enforcement is identity-based, but the real-time match on live traffic still depends on FortiGate associating the traffic’s source IP with the authenticated Windows user. If that mapping is missing, stale, or tied to the wrong IP because of DHCP changes, DNS update lag, or collector-agent timing, the firewall policy match can fail even though the user successfully logged in to Windows.

That is why C is the best first check.

A may be the next thing to verify if the user is present but still denied, but first you must confirm the user is even present in the FSSO table with the correct IP.

B is unrelated to the initial FSSO identity-mapping problem.

D is less likely because the Windows logon already succeeded.

Useful checks:

diagnose debug authd fsso list

diagnose debug authd fsso server-status

execute fsso refresh

These commands confirm whether FortiGate has the user, group, and IP mapping needed for policy matching.