Pearson NSE4_FGT_AD-7.6 New Attempt

“FortiGate looks for the matching firewall policy from top-to-bottom and, if a match is found, the traffic is processed based on the firewall policy. If no match is found, the traffic is dropped by the default implicit deny firewall policy. ”

Technical Deep Dive:

The debug flow output clearly points to the implicit deny :

ret-no-match

policy-0 is matched, act-drop

Denied by forward policy check (policy 0)

On FortiGate, policy 0 is the internal representation of the default implicit deny firewall policy . That means the packet did not match any user-defined forward firewall policy, so FortiGate dropped it automatically.

Why the other options are wrong:

B is wrong because an RPF failure would show a reverse-path-related drop reason, not Denied by forward policy check (policy 0).

C is wrong because the trace does not show a matched explicit policy ID with deny action; it shows policy 0 , which is the implicit rule.

D is wrong because the trace actually shows a route lookup result: find a route: ... gw-0.0.0.0 via port2. So this is not a next-hop reachability failure.

In packet-flow troubleshooting, this pattern is one of the most important to recognize. If you see policy 0 in FortiGate debug flow, the first things to verify are:

diagnose debug flow filter addr < src_or_dst_ip >

diagnose debug flow show function-name enable

diagnose debug enable

Then review whether a firewall policy exists with the correct incoming interface, outgoing interface, source, destination, schedule, and service . If any one of those does not match, FortiGate falls through to policy 0 and drops the session.

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

“FortiSASE provides secure access to remote users for the following use cases:

• SIA enables secure web browsing for remote users to protect from known and unknown threats

• SPA enables explicit application access under a zero-trust access or with SD-WAN integration to ensure secure application access

• SSA addresses shadow IT visibility challenges and safeguards data loss prevention ”

“FortiCASB provides cloud-based and API-based features to enable deep inspection of SaaS applications to enable detailed monitoring, analysis, and reporting features... Data loss prevention (DLP) helps to identify, monitor, and protect organizational data at rest and in motion. ”

Technical Deep Dive:

The correct answer is C. Secure SaaS access (SSA) .

The question gives two very specific requirements:

Shadow IT visibility

Prevent sensitive files from leaving the organization without approval

The study guide maps both directly to SSA . In FortiSASE, SSA aligns with SaaS governance and CASB-style controls. That is the right architecture when you need visibility into sanctioned and unsanctioned SaaS usage, plus DLP controls for uploads, sharing, and file movement.

Why the other options are wrong:

SIA focuses on securing internet browsing and remote web traffic.

SPA is for explicit zero-trust access to private applications.

SSD-WAN is not the FortiSASE method for SaaS visibility/DLP control.

In practice, SSA is the choice because it combines SaaS visibility, activity monitoring, and DLP-style enforcement . That lets an administrator detect shadow SaaS usage and apply controls such as blocking uploads, monitoring sharing events, or restricting file transfers based on policy. This is a CASB-oriented use case, not just generic web security.

From the exhibits:

The firewall policy has Application Control enabled and uses certificate-inspection for SSL inspection.

The application sensor has Application and Filter Overrides with the following order (priority):

Excessive-Bandwidth with action Block

Google (vendor filter) with action Monitor

In FortiOS, Application and Filter Overrides are evaluated by priority (top-down). The first matching override is applied. If traffic matches an earlier override with Block, it will be blocked even if a later override would Monitor/Allow it.

Why Google apps fail while works:

Many Google applications can be detected as (or can trigger) the Excessive-Bandwidth behavior/signature depending on the specific service and traffic pattern.

Because Excessive-Bandwidth (Block) is above Google (Monitor), Google-related traffic may match the first rule and be blocked before the Google override is evaluated.

Access to works because that traffic is not matching the Excessive-Bandwidth override.

Therefore, to resolve:

B. Move up Google in the Application and Filter Overrides section to set its priority higher

This ensures Google matches the Google override before any broader blocking override is applied.

E. Set the action for Google in the Application and Filter Overrides section to Allow

This explicitly permits Google applications once the higher-priority match occurs (stronger than Monitor for troubleshooting and ensuring access).

Why the other options are not the best fit here:

A (deep-content inspection) can help identify more HTTPS applications, but the exhibit already shows a specific Google override configured; the immediate issue is the override evaluation order and action.

C relates to Web Filter URL categories, but the problem is occurring under Application Control behavior/vendor overrides.

D (flow-based) is not required to fix an override priority/action conflict.