Free Fortinet NSE4_FGT_AD-7.6 Practice Exam with Questions & Answers

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.

With a dialup IPsec VPN on FortiGate, when add-route is enabled, FortiGate will only install the corresponding route when it has enough negotiated information from the tunnel. In FortiOS 7.6, that means the route is tied to the Phase 2 (Quick Mode) selectors and is created dynamically when the IPsec SA is actually up.

B. The administrator must ensure phase 2 is successfully established

This is required. FortiGate does not install the add-route route just because Phase 1 exists or because the configuration is present. The route is added when the tunnel is effectively usable, which requires Phase 2 (IPsec SA) to be up. If Phase 2 is not established, there is no active SA and FortiGate will not inject the related route into the routing table.

So, if the static route is not showing, one correct explanation is that Phase 2 is not up.

C. The administrator must define the remote network correctly in the phase 2 selectors

This is also required. For dialup tunnels, FortiGate derives what route to add from the remote subnet(s) defined in the Phase 2 selector (proxy ID). If the remote network in Phase 2 is missing, incorrect, or too broad/too narrow in a way that prevents negotiation, the tunnel either won’t come up (so no route), or the route that would be installed won’t match what the administrator expects.

So, another correct explanation is that the Phase 2 remote network is not correctly defined, preventing the correct route from being created.

Why the other options are incorrect

A. Policy route instead of a static route

Add-route does not require policy routes. It is specifically a feature that injects a route (route-table entry) associated with the IPsec tunnel/SA and the Phase 2 selector networks.

D. Enable a dynamic routing protocol

Dynamic routing protocols (OSPF/BGP/RIP) are not required for add-route. Add-route is independent of dynamic routing and works by installing routes locally based on the negotiated selectors.

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

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.

According to the FortiOS 7.6 Study Guide and technical documentation, conserve mode is a protective state triggered when memory utilization reaches the Extreme Threshold (typically 95% by default). When this occurs, the FortiGate implements several measures to prioritize system stability over new functionality. One of the primary restrictions is that the FortiGate refuses to accept configuration changes (Statement B). This prevents the system from initiating new processes or allocating additional memory that could lead to a total system crash.

Regarding traffic handling, the behavior is determined by specific " fail-open " settings. For the IPS engine, if the fail-open global setting is enabled, the FortiGate continues to transmit packets without IPS inspection (Statement D). This ensures that network connectivity is maintained even when the system lacks the memory resources to perform deep packet inspection. In contrast, Statement A is incorrect because the system may skip non-essential actions to save memory. Statement C is incorrect because conserve mode is designed to avoid a system halt; the device remains operational and will automatically exit conserve mode once memory usage drops below the Release Threshold (typically 82%).

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.

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.

" Also, advanced mode supports nested or inherited groups; that is, users can be members of subgroups that belong to monitored parent groups. " " In advanced mode, you can configure FortiGate as an LDAP client and configure the group filters on FortiGate. You can also configure group filters on the collector agent. "

Collector Agent Advanced Mode provides deeper integration between FortiGate, LDAP, and Active Directory, compared to standard mode.

Key features of Collector Agent Advanced Mode

B. FortiGate can be configured as an LDAP client and group filters can be configured on FortiGate.

Correct

In advanced mode:

FortiGate directly queries LDAP/AD

User group filters are configured on FortiGate, not only on the Collector Agent

This allows more flexible and scalable user/group-based policies

D. Advanced mode supports nested or inherited groups.

Correct

Advanced mode supports:

Nested AD groups

Inherited group memberships

This is one of the primary reasons advanced mode is used in complex AD environments

Why the other options are incorrect

A. Security profiles only to user groups

Incorrect.

Security profiles can be applied to users or groups, depending on policy configuration.

C. Uses NetBIOS Domain\Username format

Incorrect.

NetBIOS naming is associated with standard mode

Advanced mode typically uses LDAP DN-based identification

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.