Fortinet NSE 4 - FortiOS 7.6 Administrator - NSE4_FGT_AD-7.6 Practice Questions

Explanation:

This question tests knowledge of FortiGate web filter profile compatibility with firewall policies. Certain web filter features, such as daily category usage quotas, only work with specific inspection modes. If the firewall policy uses an inspection mode that doesn’t support the feature, the profile will not appear in the policy dropdown.

✔️ Correct option:
The daily category usage quota in a web filter profile requires full (deep) inspection. If the firewall policy uses flow-based or no-inspection mode, the profile becomes unavailable. Option D correctly identifies that the mismatch between the profile’s feature set and the policy’s inspection mode is the reason it isn’t listed.

❌ Incorrect Options:

A. The web filter profile is already referenced in another firewall policy
The profile can be applied to multiple policies simultaneously, so being used elsewhere does not prevent it from appearing in the dropdown. This option misunderstands FortiGate’s design, as profile usage is not exclusive to a single policy.

B. The firewall policy is in no-inspection mode instead of deep-inspection
While no-inspection mode would indeed block some web filter features, the issue is more specific: it must support the feature set of the profile, not just any inspection type. Simply being in no-inspection mode is an incomplete explanation.

C. The naming convention used in the web filter profile is restricting it in the firewall policy
FortiOS does not restrict web filter profiles based on naming. The profile’s availability is determined by feature compatibility, not how it is named, making this option irrelevant.

Reference:
⇒ Fortinet Documentation – Category usage quotas

Explanation:

The correct answer is A. FortiGate will enable strict RPF on all its interfaces and port1 will be exempted from RPF checks.

Here's what this configuration actually does:

✔️ config system settings → set strict-src-check enable
This globally enables strict Reverse Path Forwarding (RPF) mode for the VDOM.
In strict mode, FortiGate performs a stricter anti-spoofing check: for every incoming packet, it looks up the best route back to the source IP. If that best reverse route doesn't point out the same interface the packet came in on, the packet is dropped.
(By default, without this setting, it's feasible/loose mode, which only requires at least one feasible route back via the incoming interface.)

✔️ config system interface → edit port1 → set src-check disable
This disables the source/RPF check completely on port1 only.
So even though strict mode is active globally, port1 ignores the RPF check entirely—packets coming in on port1 won't be dropped for failing the reverse path check (useful for asymmetric routing scenarios or certain VPNs where return traffic takes a different path).

The per-interface src-check disable overrides the global strict-src-check setting for that specific interface. Strict mode applies to every other interface, but port1 is fully exempted from any RPF validation.

Why the others are incorrect:

B — "port1 will be enable for asymmetric routing" is vague and not precise. Disabling src-check on port1 does allow asymmetric traffic through that interface (since RPF won't block it), but the phrasing "enable for asymmetric routing" isn't how FortiGate describes it, and it doesn't match the full impact.

C — No, the interface-level setting takes precedence over the global one here. Global doesn't override per-interface disable.

D — "Flexible RPF" isn't a real term in FortiGate. The modes are strict vs feasible (loose). Disabling src-check isn't "flexible"—it's completely off for that interface.

Reference:
Fortinet's official documentation (e.g., FortiOS 7.6 Administration Guide → Routing concepts section) and the key technical tip on community.fortinet.com explain this behavior clearly:
🔹 strict-src-check enable → strict RPF globally
🔹 src-check disable on interface → bypasses RPF entirely on that interface, overriding the global mode

Explanation:

Why C is correct
With full SSL inspection, FortiGate performs a man-in-the-middle operation on HTTPS traffic. It resigns the server certificate using a local CA certificate configured in the SSL/SSH inspection profile.
If the client browser does not trust that CA, it cannot validate the certificate chain, so it throws a certificate warning.

This behavior only affects HTTPS because:
🔹 HTTPS uses certificates and trust chains.
🔹 HTTP does not use certificates at all, so no warning appears.
This is the classic and expected outcome when the FortiGate CA certificate has not been installed and trusted on the client.

Why the other options are wrong

A. The option invalid SSL certificates is set to allow on the SSL/SSH inspection profile.
Incorrect.
This setting controls how FortiGate handles upstream server certificates that are invalid (expired, self-signed, etc.). It does not affect whether the client trusts FortiGate’s own inspection certificate. Even if set to allow, the browser will still warn if it does not trust FortiGate’s CA.

B. The matching firewall policy is set to proxy inspection mode.
Incorrect.
Proxy mode is required for full SSL inspection and web filtering. It is not the cause of certificate warnings. If anything, proxy mode is functioning correctly here.

D. The certificate used by FortiGate for SSL inspection does not contain the required certificate extensions.
Incorrect.
FortiGate-generated CA certificates include the necessary extensions for SSL inspection by default. Missing extensions would indicate a broken or manually misconfigured certificate, which is not the standard cause tested in NSE4. The exam expects you to recognize the client trust issue, not certificate structure problems.

Key exam takeaway
Full SSL inspection always causes certificate warnings unless the FortiGate CA certificate is trusted by the client.

Reference (Fortinet official)
🔹 FortiOS Administration Guide – SSL/SSH Inspection
Explains that the FortiGate re-signs certificates and requires the CA certificate to be installed on client devices.
Fortinet Documentation → FortiOS 7.6 → Security Profiles → SSL/SSH Inspection​

Explanation:

This question tests how to verify if reliable logging (also known as reliable syslog or OFTP over TCP with acknowledgment) is enabled when FortiGate sends logs to FortiAnalyzer. Reliable logging ensures logs are not lost by using TCP-based transmission with sequence numbers and acknowledgments, unlike default UDP. The key is to check the FortiGate configuration for the setting that enables reliable mode to FortiAnalyzer.

✔️ B. Option B
The CLI output shows the command config log fortianalyzer setting with set status enable, set server "10.0.13.125", and importantly set upload-option realtime. In FortiOS, upload-option realtime enables reliable logging to FortiAnalyzer (using OFTP over TCP with reliability features). This is the direct way to confirm reliable logging is active on HQ-NGFW-1.

❌ A. Option A
This is the FortiAnalyzer GUI showing the logging device (HQ-NGFW-1) as "Up" with "Real Time" logging mode. While it indicates the connection is active and logs are arriving in real time, it does not prove reliable logging is configured on the FortiGate side — only that FortiAnalyzer sees real-time logs.

❌ C. Option C
Similar to A, this is another FortiAnalyzer device list view showing HQ-NGFW-1 as "Up" with "Real Time" mode. It confirms connectivity and log reception but does not verify the reliable setting was enabled on the FortiGate configuration.

❌ D. Option D
This is a packet sniffer output on HQ-NGFW-1 showing UDP packets to 10.0.13.125:514 (standard syslog port). UDP is unreliable by nature (no acknowledgments). Seeing UDP traffic here actually suggests default/unreliable logging is in use — the opposite of reliable logging.

Reference:
⇒ https://docs.fortinet.com/document/fortigate/7.6.0/cli-reference/84566/fortios-cli-reference — CLI reference confirms upload-option {realtime | store-and-forward}; realtime = reliable logging with acknowledgments.

Explanation:

The two correct features of collector agent advanced mode are:
🔹 Advanced mode supports nested or inherited groups.
🔹 In advanced mode, FortiGate can be configured as an LDAP client and group filters can be configured on FortiGate.
The information is consistent across multiple exam preparation sites. The table below breaks down why each answer choice is correct or incorrect.

✅ Correct

A. Supports nested or inherited groups
This is a key feature of advanced mode, allowing it to recognize users in subgroups within monitored Active Directory groups.

B. FortiGate as LDAP client with group filters
In advanced mode, FortiGate can query LDAP/AD directly, and group filters are configured on the FortiGate itself for more granular control.

❌ Incorrect

C. Security profiles only for user groups
In both standard and advanced modes, security profiles can be applied to individual users or groups. This is not a distinguishing feature of advanced mode.

D. Uses Windows convention (NetBIOS)
This is actually a feature of standard mode. Advanced mode typically uses the LDAP naming convention (CN=User, OU=Name, DC=Domain).

✍️ Key Takeaway for the Exam
The main distinctions between standard and advanced mode often center on nested group support and where configuration occurs (agent vs. FortiGate). To solidify this, focus on understanding the operational differences in how user and group information is retrieved and processed in each mode.

Explanation:

This question tests your knowledge of FortiGate's conserve mode, which is a critical state triggered when system memory resources become critically low. Understanding its behavior is crucial for maintaining network stability and security.

✔️Correct Option:

A. FortiGate refuses to accept configuration changes:
To prevent further memory consumption and maintain stability, the FortiGate will block attempts to apply new configurations or modify existing ones while in conserve mode.

D. FortiGate continues to run critical security actions, such as quarantine:
Even under severe resource constraints, the FortiGate prioritizes and attempts to maintain essential security functions like firewall policy enforcement, session cleanup, virus detection, and quarantining to protect the network.

❌Why the Other Options Are Wrong:

B. FortiGate halts complete system operation and requires a reboot to regain available resources:
This is incorrect. Conserve mode is designed to prevent a complete system halt. The FortiGate attempts to recover by shedding non-critical processes and may not require an immediate reboot.

C. FortiGate continues to transmit packets without IPS inspection when the fail-open global setting in IPS is enabled:
The "fail-open" setting for IPS usually refers to hardware bypass during specific failures. In conserve mode, the FortiGate might drop traffic or limit inspection due to resource constraints, but it does not universally "fail-open" all traffic without inspection in this context.

Reference:
⇒ FortiGate Conserve Mode (This section explains the different conserve mode levels and the actions FortiGate takes, including blocking configuration changes and maintaining critical security functions to prevent system crashes.)

Explanation:

The correct answers are C and D.
✔️ C. They must have the heartbeat interfaces in the same subnet
✔️ D. They must have the same HA group ID.

Here's the breakdown:
For FGCP HA to form a cluster successfully, the FortiGates must match on several key HA-specific settings so they can discover each other, negotiate, and synchronize properly via the heartbeat.

✅ Heartbeat interfaces in the same subnet (C):
The dedicated heartbeat interfaces (usually ha1/ha2 or whatever you designate) need direct Layer 2 connectivity. They communicate using multicast/broadcast packets, so they must be in the same subnet (same broadcast domain). If they're not, the units can't see each other's heartbeats, and the cluster won't form. This is a hard requirement for FGCP heartbeat communication.

✅ Same HA group ID (D):
The group ID must match exactly on all members. It's used during discovery and negotiation—FortiGates only form a cluster with others that have the identical group ID (along with matching mode, password, etc.). Different group IDs mean they ignore each other, even if physically connected. This is explicitly required for cluster formation.

Why the others are not required:

A. Same hard drive configuration:
Yes, hardware must generally match (same model, same number of hard disks, same firmware, etc.), but the exact "configuration" (like RAID setup or partitioning) doesn't have to be identical for the cluster to form. The base hardware match is needed for sync and operation, but this option is worded too specifically and isn't a strict formation prerequisite like the heartbeat/group ID items.

B. Same number of configured VDOMs:
This is a common misconception. The number of configured (enabled/created) VDOMs doesn't need to match for HA to form. What matters is the VDOM mode (single vs multi) and having compatible VDOM licenses if using more than the base allowance. But mismatched counts of actual configured VDOMs won't prevent cluster formation—the configs sync anyway.

Reference:
FortiOS 7.6 Administration Guide → High Availability section (specifically FGCP overview and HA heartbeat interface pages):
→ Docs confirm identical HA settings (group-id, password, mode) are required for negotiation.
→ Heartbeat interfaces must share the same broadcast domain/subnet for communication.
→ Hardware parity (model, firmware, disk count) is listed, but not "configuration" details or exact VDOM count as blockers for initial cluster formation.