Fortinet NSE4_FGT_AD-7.6 Fortinet NSE 4 - FortiOS 7.6 Administrator Exam Practice Test

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.

From the exhibits:

The firewall policy has NAT enabled and is configured to Use Dynamic IP Pool.

The selected IP pool (Internet-pool) is configured as:

Type: One-to-One

External IP Range: 100.65.0.110–100.65.0.111 (only two public IPs)

PC1 and PC2 can access the internet because each one-to-one NAT mapping consumes one public IP from the pool. When PC3 is added, there is no third public IP available in the pool, so FortiGate cannot allocate a one-to-one mapping for PC3 and the session fails.

FortiOS behavior here is standard: with one-to-one IP pools, the available pool size limits how many distinct internal sources can be translated concurrently (depending on allocation and sessions), and a pool with only two IPs will not reliably support three separate hosts needing translations.

Therefore, the administrator can fix this in two valid ways:

B. In the IP pool configuration, set end ip to 100.65.0.112.

This expands the pool by adding an additional public IP address, making three public IPs available (.110, .111, .112), so PC3 can be assigned an address for one-to-one NAT.

D. In the IP pool configuration, set type to overload.

Changing the pool type to overload enables PAT (many-to-one), allowing multiple internal hosts (PC1, PC2, PC3) to share the pool address(es) using different source ports. This removes the “one public IP per internal host” limitation inherent to one-to-one pools.

Why the other options are not correct:

A. Multiple Interface Policies is unrelated to IP pool exhaustion and does not solve NAT allocation limits.

C. match-vip affects VIP matching behavior for destination NAT/virtual IP usage and does not address the source NAT pool shortage causing PC3 to fail.

According to the FortiOS 7.6 Study Guide and Parallel Path Processing documentation, flow-based antivirus inspection is designed to provide security with minimal impact on performance.

First, a defining characteristic of modern flow-based AV (specifically in its "hybrid" mode) is that FortiGate buffers the whole file but transmits to the client at the same time (Statement A). This behavior allows the client to start receiving data immediately to prevent session timeouts, while the FortiGate reassembles the file in memory to perform a signature check before the final packet is released.

Second, starting with recent FortiOS versions including 7.6, flow-based inspection uses a hybrid of the scanning modes (Statement B). Previously, flow mode offered "Quick" or "Full" scans; now, it combines these techniques to offer a balance between the speed of stream-based scanning and the thoroughness of archive inspection.

Third, the primary motivation for selecting this mode is that flow-based inspection optimizes performance compared to proxy-based inspection (Statement D). It processes traffic in a single pass using the IPS engine, avoiding the overhead associated with the WAD (proxy) process. Statement C is incorrect because if a virus is detected, the last packet is withheld and the connection is reset to prevent the file from being completed. Statement E is less accurate as the IPS engine loads the AV engine to perform the task rather than acting as a "standalone" entity in the context of file scanning.

In FortiOS 7.6, if an administrator wants to block traffic only after an IPS signature is triggered a specific number of times within a defined time window, this must be done using IPS filters with rate-based settings.

Why option D is correct

IPS filters allow administrators to match signatures based on attributes such as:

Severity

Protocol

CVE

Signature ID

IPS filters support rate-based actions using:

rate-mode periodical

rate-count

rate-duration

With rate-mode periodical, FortiGate:

Counts how many times a signature is triggered

Within a defined time period

And applies the configured action (for example, block) once the threshold is exceeded

This directly matches the requirement:

“block traffic that triggers the signature set number of times during a specific time period.”

Why the other options are incorrect

A. IPS group signatures, set rate-mode 60Group signatures do not provide the required per-period rate-based blocking logic.

B. IPS packet logging optionLogging does not enforce blocking behavior.

C. IPS signatures, rate-mode periodical optionRate-based controls are applied via IPS filters, not directly on individual signature definitions.

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

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.

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.

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

According to the FortiOS 7.6 Administration Guide and Security Fabric documentation, automation stitches are designed to automate responses to security and system events across the network. A core characteristic of these stitches is their flexibility in action execution; specifically, multiple actions can run in parallel (Statement C). While the system allows for sequential execution with configurable delays between actions, the default behavior or configuration option allows for simultaneous responses, such as sending an email notification while simultaneously triggering a webhook or quarantining a host.

Furthermore, triggers can involve external connectors (Statement D). While many triggers are local to the FortiGate (such as reboots or log events), the Security Fabric allows the FortiGate to monitor and react to events from external components like FortiAnalyzer, FortiSIEM, or FortiClient EMS. For example, a FortiAnalyzer event handler can act as the trigger for a stitch on the root FortiGate. Statement A is incorrect because actions can target external systems like AWS Lambda or Slack which are not internal Fabric devices. Statement B is incorrect because each automation stitch is typically defined by a single trigger, though that trigger itself can be broad (e.g., "Any Security Rating Notification").

Based on the FortiOS 7.6 Authentication and User Group documentation, the correct answer is A.

Meaning of “Include in every user group” (FortiOS 7.6)

When configuring a RADIUS server on FortiGate, enabling Include in every user group has a very specific and documented effect:

The configured RADIUS server object is automatically added to all FortiGate user groups.

As a result, any user who successfully authenticates against that RADIUS server becomes a valid member of every FortiGate user group, unless additional group filtering (such as RADIUS attributes) is applied.

This simplifies configuration when the same external authentication source must be accepted across multiple firewall policies that reference different user groups.

This behavior is explicitly described in the FortiOS 7.6 Administrator Guide under RADIUS authentication servers and user groups.

Why Option A is Correct

FortiGate user groups can include:

Local users

LDAP servers

RADIUS servers

Enabling Include in every user group causes FortiGate to:

Insert the RADIUS server into all existing and future FortiGate user groups

Therefore, all users authenticating via this RADIUS server are implicitly allowed in every FortiGate user group.

This is exactly what option A describes.

Why the Other Options Are Incorrect

B: FortiGate does not push users or groups into the RADIUS server. Authentication is always initiated by FortiGate toward RADIUS.

C: FortiGate does not manage or modify RADIUS-side group definitions.

D: LDAP and RADIUS user groups are separate authentication mechanisms; this setting does not merge or affect LDAP groups.

Comprehensive and Detailed 150 to 200 words of Explanation From Exact Extract of FortiOS 7.6 documents:

According to FortiOS 7.6 High Availability documentation, the FortiGate Cluster Protocol (FGCP) provides robust mechanisms for both link monitoring and stateful data synchronization. Link failover is a primary trigger for cluster renegotiation; if a monitored interface goes down—including when an administrator manually sets the interface to administratively down—the primary unit's priority is effectively reduced, triggering a failover to a secondary unit to ensure path continuity.5 This is a standard method for testing HA failover behavior.

Furthermore, to achieve a seamless stateful failover where active sessions are not dropped, the FortiGate performs incremental synchronization of critical runtime data.6 This specifically includes Forwarding Information Base (FIB) entries, which represent the compiled routing table, and IPsec Security Associations (SAs).7 By synchronizing IPsec SAs, the secondary unit 8can resume encrypted tunnels immediately after a failover without requiring a f9ull IKE re-negotiation.10 Statement A is incorrect because in-band and out-of-band management can coexist using reserved management interfaces and management-ip settings.11 Statement C is incorrect because while heartbeat interfaces use link-local IPs in the 169.254.0.x range, the specific IP .2 is not universally required for all heartbeats and depends on the number of cluster members and serial numbers.

When the Application sensor receives traffic on that port, the protocol decoder will try to determine if the received data matches the HTTPS traffic In this case it will not match because it is P2P traffic, so this will class as violation and blocked The protocol decoder also try to determine what type of traffic it is, and even if it could not figure out it is P2P traffic, it still count as a violation because even though it does not know what it is, it knows for fact it is not HTTPS

In FortiOS 7.6, SD-WAN steering decisions are recorded in traffic logs only when traffic matches an explicit SD-WAN rule (SD-WAN service rule). When no configured SD-WAN rule matches a session, FortiGate uses the implicit (default) SD-WAN rule/behavior to select a member (often resulting in load-balancing or default selection based on the configured SD-WAN algorithm).

In the exhibit, traffic is permitted by firewall policy ID 1, and the Destination Interface alternates between port1 and port2, but SD-WAN Rule Name remains empty. This is consistent with the sessions being forwarded by the implicit SD-WAN rule, which does not populate a named rule in the log columns.

Why the other options are not correct:

A: SD-WAN rule name logging is not a “delayed display” behavior requiring refresh; it is populated per-session when an explicit rule matches.

B: Application Control is not required for SD-WAN rule name to appear. Rule name logging depends on SD-WAN rule match, not on whether Application Control is enabled.

C: Feature visibility affects GUI display options, but the exhibit already shows the SD-WAN columns enabled; the issue is that no explicit SD-WAN rule is being hit.

The exhibit shows a FortiGate UTM application control log with fields such as:

type="utm"

subtype="app-ctrl"

action="block"

policyid=1

appid=30220

appcat="Video/Audio"

service="HTTP"

apprisk="elevated"

This is a forward traffic security log, generated by Application Control applied to a firewall policy.

Why the correct answers are C and D

C. By filtering by policy universally unique identifier (UUID) and application name in the log entry

Correct.

FortiOS logs can be viewed and filtered in:

Log & Report → Forward Traffic

Administrators can filter logs using fields such as:

Policy ID / Policy UUID

Application name (app)

Application ID (appid)

The log entry clearly includes application-related fields, making filtering by policy and application a valid and documented way to view these logs.

D. In the Forward Traffic section

Correct.

The log is a UTM Application Control log for traffic passing through a firewall policy.

Such logs are displayed under:

Log & Report → Forward Traffic

This is the standard and correct location to view application control, web filter, IPS, and other security profile logs related to user traffic.

Why the other options are incorrect

A. By right clicking the implicit deny policy

Incorrect.

Implicit deny policies do not generate UTM forward traffic logs like the one shown.

Application control logs are generated only by explicit firewall policies with security profiles enabled.

B. Using the FortiGate CLI command diagnose log test

Incorrect.

diagnose log test is used to test log connectivity and log settings, not to view historical log entries.

It does not display traffic or UTM logs.

In FortiOS 7.6, when multiple dialup IPsec VPNs are configured on the same FortiGate—especially in Aggressive Mode—FortiGate must identify which Phase 1 configuration a connecting client should match.

How FortiGate selects a dialup IPsec tunnel

For dialup VPNs:

The remote peer (user or device) does not have a fixed IP address

Multiple Phase 1 interfaces may exist on the HQ FortiGate

FortiGate uses identifying information sent during IKE Phase 1 to select the correct tunnel

Aggressive Mode behavior

Aggressive mode sends ID information in clear text during Phase 1

This allows FortiGate to match incoming peers to the correct Phase 1 configuration

Why Peer ID is the correct answer

C. Peer ID

Peer ID (also called IKE ID) is used to:

Identify the remote peer

Differentiate between multiple dialup tunnels

Common Peer ID formats:

FQDN

User FQDN

Key ID

FortiGate matches the received Peer ID against the Phase 1 configuration to select the correct tunnel

This is the documented and recommended method for:

Mapping users to different department tunnels

Supporting multiple dialup IPsec VPNs in aggressive mode

Why the other options are incorrect

A. Local GatewayIdentifies the local FortiGate interface/IP, not the remote user.

B. Dead Peer DetectionUsed only for tunnel health monitoring, not tunnel selection.

D. IKE Mode ConfigUsed for assigning IP addresses and pushing settings, not for selecting the Phase 1 tunnel.

Based on the FortiOS 7.6 Infrastructure and IPsec VPN documentation, Dead Peer Detection (DPD) can be configured in three primary modes: On Demand, On Idle, and Disabled.

On Demand (Default Mode): This mode is specifically designed to minimize unnecessary traffic. In this mode, FortiGate sends DPD probes only when there is no inbound traffic but the FortiGate is attempting to send outbound traffic. Because network communication is typically bidirectional, the absence of inbound traffic while outbound traffic is being sent is a primary indicator of a potentially dead tunnel. This matches the specific requirement described in the question.

On Idle: In this mode, DPD probes are sent if no traffic (neither inbound nor outbound) has been observed in the tunnel for a specific period. It verifies the tunnel status even when the connection is completely idle.

Enabled: In older versions or specific CLI contexts, "Enabled" may refer to periodic DPD, but in the current FortiOS 7.x/7.6 GUI and CLI terminology for Phase 1 settings, the active modes are defined as on-demand or on-idle.

Disabled: In this mode, the FortiGate does not send DPD probes but will still respond to DPD probes sent by the remote peer.

The requirement that the administrator wants probes sent only when there is no inbound traffic (usually implying the FortiGate is sending but not receiving) is the fundamental definition of the On Demand mechanism in the Fortinet curriculum.

In FortiOS 7.6, web filter profiles are inspection-mode dependent. Certain advanced web filtering features—such as daily category usage quota—are only supported when the firewall policy is operating in proxy-based inspection mode.

Why the profile is not visible

The profile restrictmedia-profile includes a daily category usage quota.

Daily quotas are a proxy-based web filtering feature.

If the firewall policy is configured with:

Inspection mode: Flow-based

Then FortiGate will not display proxy-only web filter profiles in the Web Filter drop-down list.

FortiGate automatically filters the available profiles based on feature compatibility with the policy’s inspection mode.

This behavior is explicitly documented in the FortiOS 7.6 Web Filtering and Inspection Mode Compatibility sections.

Why the other options are incorrect

A. Already referenced in another firewall policyWeb filter profiles can be reused across multiple policies. This does not hide them.

B. Firewall policy is in no-inspection mode instead of deep-inspectionSSL inspection depth affects HTTPS visibility, not whether a web filter profile appears in the drop-down list.

C. Naming convention restrictionFortiOS does not restrict profile selection based on naming conventions.