Free Fortinet NSE4_FGT_AD-7.6 Practice Exam with Questions & Answers | Set: 3

The study guide text surfaced from the PDF did not return a matching paragraph for fabric-object-unification, but the exhibit itself shows these critical details:

On HQ-NGFW-1 , set configuration-sync default and set fabric-object-unification local

On HQ-ISFW , set configuration-sync default

The new address object on HQ-NGFW-1 has Fabric global object enabled

Those exhibit settings indicate that the object is intended to be a fabric-wide object, but the root FortiGate is currently configured with fabric-object-unification local , which prevents that object from being unified across the fabric.

Technical Deep Dive:

The correct answer is C .

Here is the key logic:

The address object was created on the root FortiGate with Fabric global object enabled .

Normal configuration sync is already set to default , so this is not a generic sync-disabled problem.

The root device is specifically configured with set fabric-object-unification local .

That setting keeps fabric objects local to the device rather than unifying them across downstream fabric members.

Therefore, to make the object propagate as a shared Security Fabric object, the administrator must change the root setting to:

config system csf

set fabric-object-unification default

end

Why the other options are wrong:

A is wrong because the downstream device already has configuration-sync default, and changing it to local would make synchronization more restrictive, not less.

B is wrong because saml-configuration-sync is unrelated to firewall address object synchronization.

D is wrong because downstream-access controls downstream management access behavior, not fabric object propagation.

Operationally, this feature matters when you want shared address objects, services, and policy-referenced objects to remain consistent across the Security Fabric. It reduces duplicate object administration and helps keep policy logic normalized across root and downstream FortiGate devices.

“With these multiple filters, which one has the priority? After the IPS engine examines the traffic stream for a signature match, FortiGate scans packets for matches, in this order, for the application control profile:

1. Application and filter overrides ...”

“Next, the scan checks for application and filter overrides. Because a filter override is configured to block applications that use excessive bandwidth, it blocks all applications using excessive bandwidth , regardless of other categories that allow these applications.”

“In this scenario, the filter override (Excessive-Bandwidth) is blocked and, since Dailymotion falls under the excessive bandwidth category, Dailymotion is blocked even though it is set to Monitor in the Application and Filter Overrides section. The priority in which application and filter overrides are placed takes precedence. ”

“To allow web filtering, DNS filtering, or application control for HTTPS traffic , you must select an SSL inspection profile with certificate inspection or a deep inspection enabled.”

Technical Deep Dive:

The problem is not flow-based mode and not the SSL profile. Your firewall policy already has certificate-inspection , and the study guide explicitly says that application control for HTTPS traffic works with certificate inspection or deep inspection . So option B is unnecessary, and option A is unrelated.

The real issue is the override order inside the application sensor:

Priority 1: Filter = Excessive-Bandwidth , Action = Block

Priority 2: Vendor = Google , Action = Monitor

FortiGate evaluates overrides from top to bottom and applies the first match . Many Google applications match the Excessive-Bandwidth filter, so they are blocked before the later Google/Monitor override is ever reached. That is why Google apps fail while www.fortinet.com still works.

So the correct fix is to move the Google override above the Excessive-Bandwidth filter , making Google the first match.

A representative CLI-style logic would be:

config application list

edit " default "

config entries

edit 1

set vendor " Google "

set action monitor

next

edit 2

set filter " Excessive-Bandwidth "

set action block

next

end

next

end

That preserves the bandwidth block for other apps while allowing Google applications to match the higher-priority override first.

“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.

“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.

“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.

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.

The exhibit shows the output of the following command:

diagnose test application ipsmonitor 1

pid = 2044, engine count = 0 (+1)

0 - pid:2074:2074 cfg:1 master:0 run:1

How to interpret this output (FortiOS 7.6 – IPS internals)

ipsmonitor displays the status of IPS engines running on the FortiGate.

engine count = 0 means:

No IPS scanning engines are currently active

IPS is not processing any traffic

In FortiOS, IPS engines are started on demand.

Critical documented behavior

IPS processes are only spawned when at least one firewall policy is configured with an IPS profile and traffic matches that policy.

If no firewall policy references an IPS profile, the IPS engine:

Does not start

Shows engine count = 0

Appears “not working,” even though the IPS profile exists

This is exactly what the diagnose output indicates.

Why option A is correct

A. There is no firewall policy configured with an IPS security profile.

Creating an IPS profile alone is not sufficient

IPS must be applied to an active firewall policy

Traffic must match that policy for the IPS engine to run

Otherwise, ipsmonitor will show engine count = 0

This matches FortiOS 7.6 IPS operational behavior.

Why the other options are incorrect

B. Administrator entered the command diagnose test application ipsmonitor 5.

Incorrect.

The exhibit clearly shows ipsmonitor 1

Using a different argument would not explain engine count = 0

C. FortiGate entered into IPS fail open state.

Incorrect.

In fail-open, IPS engines may be bypassed, but they still initialize

engine count = 0 specifically indicates IPS is not in use at all

D. Administrator entered the command diagnose test application ipsmonitor 99.

Incorrect.

The command argument affects debug level, not engine creation

Again, the exhibit shows ipsmonitor 1