Fortinet NSE 6 SD-WAN 7.6 Enterprise Administrator - NSE6_SDW_AD-7.6 Practice Questions

Explanation :

FortiManager fails to install the configuration because the firewall policies reference SIA and DIA as outgoing interfaces. These are SD-WAN zones defined within an SD-WAN template. In FortiManager's architecture, SD-WAN template zones are not exposed as selectable interfaces in the firewall policy object database. During pre-install validation, FortiManager cannot resolve these zone references, resulting in a "Conf Failed" error. The policies must use concrete interfaces (e.g., port2, wan1) or a regular interface zone defined at the device level, not an SD-WAN template zone.

Correct Option

B is correct. Firewall policies in a policy package cannot use an SD-WAN zone from a template as an egress interface. These zones are part of the SD-WAN configuration namespace and are unavailable to the firewall policy engine, causing a validation failure upon installation.

Incorrect Options

A: Incorrect. The error is not about routing SIA traffic to a VPN tunnel; it is a configuration validation failure. A policy can successfully use a VPN tunnel interface (e.g., to_HUB) as its egress interface.

C: Incorrect.You can install policies that reference an individual SD-WAN member interface (e.g., port1). These are standard, concrete interfaces that exist in the global object database and are valid for policy configuration.

D: Incorrect. A FortiGate device can host both SIA and DIA rules simultaneously. The error is specific to the invalid interface reference in the policy configuration, not a conflict between SIA and DIA functionalities.

Reference:
FortiManager Administration Guide (v7.6): SD-WAN zones configured within an SD-WAN template are not available as outgoing interfaces in firewall policies. Policies must reference interfaces or zones defined at the device/global level. This separation prevents policy binding to dynamic SD-WAN objects, ensuring clean template management. The validation failure occurs when a policy package references an unresolved interface object from an SD-WAN template.

Explanation:

The exhibit shows a network with various Fortinet devices (FortiGate, FortiExtender, FortiSwitch, FortiAP). In a Fortinet SD-WAN fabric, hub devices are critical for establishing the overlay VPN mesh and managing control-plane traffic.

The key consideration is that hub FortiGates must be dedicated to the SD-WAN routing function. If a FortiGate acts as a hub and also manages local extensions (like a FortiSwitch, FortiAP, or FortiExtender) via FortiLink, it can lead to complex dependencies and potential traffic loops. Specifically, if the SD-WAN overlay relies on an underlay interface that is also part of a FortiLink aggregate (e.g., for switch or AP management), a failure in the local extension could destabilize the entire SD-WAN overlay.

Therefore, hubs should be devices without local FortiLink-managed extensions to ensure stability and simplified troubleshooting.

Why other options are incorrect:

A: Incorrect. Hubs should not have FortiExtender (or other extensions like FortiSwitch/FortiAP) managed via FortiLink, as this creates underlay dependency on the extension, risking SD-WAN stability.

C: Incorrect. While FortiManager is recommended for centralized management, it is not mandatory to build an SD-WAN topology. SD-WAN can be configured directly on FortiGates.

D: Incorrect. You do not need separate topologies per extension type. You can have a single SD-WAN topology, but spoke devices can have extensions (e.g., a branch FortiGate with FortiSwitch). The restriction primarily applies to hub devices.

Reference
Fortinet SD-WAN 7.6 Deployment Guide - Design Considerations: Recommends that SD-WAN hub FortiGates should not be used as FortiLink aggregation devices for switches, APs, or extenders to avoid underlay dependency and ensure overlay stability.

Explanation:

The health-check "Passive" is configured with detect-mode passive and applied to the SD-WAN service rule for Facebook and YouTube. This setup has specific operational characteristics:

A is correct: In passive detect mode, the FortiGate measures performance only using existing TCP traffic flows that match the SD-WAN rule (here, Facebook/YouTube). It does not generate active probes or use non-TCP traffic.

D is correct: A key limitation of passive mode is dead member detection. Since measurement relies solely on Facebook/YouTube traffic, if those applications aren't passing through a member, the FortiGate cannot determine if that member is alive or dead. It may not detect a failure until traffic attempts to use that path.

Why other options are incorrect:

B: Incorrect.
The performance metrics are not averaged across applications. Each traffic flow is measured individually, and the rule evaluates member performance based on real-time measurements of whatever matching traffic exists.

C: Incorrect.
The configuration does not exclude encrypted traffic. Facebook and YouTube traffic (HTTPS) is encrypted, and passive measurement works on this encrypted traffic by analyzing TCP characteristics (latency, packet loss) at the transport layer without decrypting.

Reference
FortiOS 7.6 SD-WAN Guide > Performance SLA: States that in passive detect mode, "the FortiGate monitors only TCP traffic matching the rule for performance metrics" and "cannot detect dead members without matching traffic flow."

Explanation:

C is correct: The primary purpose of referencing an SLA target in an SD-WAN rule is to validate that selected members meet the defined performance thresholds (latency, jitter, loss) before being used for traffic steering.

E is correct: An SD-WAN rule can reference multiple SLA targets from different performance SLA configurations. This allows a rule to enforce composite performance requirements (e.g., one target for latency, another for jitter).

A is correct: SLA target measurement (active probing or passive monitoring) is only performed for members in rules that reference that SLA target. If no rule uses a particular SLA target, its probes are not sent, conserving bandwidth.

Why other options are incorrect:

B: Incorrect. SLA targets are not exclusive to Lowest Cost (SLA) strategy. They can also be used in Priority, Weighted, and Manual strategies to validate member performance before selection.

D: Incorrect. While you can select multiple SLA targets, they can be from different performance SLAs, not necessarily the same one. The requirement "from the same performance SLA" is false; you can mix targets across different SLA configurations.

Reference
FortiOS 7.6 SD-WAN Administration Guide > Configuring SD-WAN > Performance SLA:
SLA targets define thresholds; rules reference them to validate members.
Rules can use multiple targets from different SLA configurations for comprehensive checks.
Health-check probes run only for SLA targets referenced by active rules.
This ensures efficient resource usage and flexible performance validation across various traffic types.

Explanation:

In an existing ADVPN-enabled SD-WAN topology, upgrading to ADVPN 2.0 does not require redesigning SD-WAN or hub configurations. The primary enhancement in ADVPN 2.0 is the ability for branches to dynamically establish shortcut tunnels directly with other branches. This behavior is controlled at the IPsec layer, not by SD-WAN policies. Because the hub already serves as a registration and routing point, it continues to function without modification. Therefore, updating the branch IPsec tunnel configuration is sufficient to enable ADVPN 2.0 functionality.

Why the incorrect options are wrong

A. Update the IPsec tunnel configurations on the hub
This is incorrect because ADVPN 2.0 eliminates the need for hub-assisted shortcut creation. The hub configuration remains unchanged in an existing ADVPN setup.

B. Update the SD-WAN configuration on the branches
SD-WAN is responsible for traffic steering, not for establishing ADVPN shortcut tunnels. Shortcut negotiation occurs at the IPsec level.

D. Delete the existing ADVPN configuration and configure ADVPN 2.0
ADVPN 2.0 is backward-compatible and implemented by modifying existing IPsec settings, not by rebuilding the configuration.

References
Fortinet FortiOS 7.6 IPsec VPN Administration Guide – Details ADVPN configuration and branch-initiated shortcuts.

Explanation:

To add an interface to an SD-WAN zone, that interface must not be referenced by any other configuration object that would conflict with SD-WAN's dynamic path control. The exhibit shows that port1 is currently used by two static routes.

SD-WAN zones manage egress path selection dynamically, while static routes define fixed egress paths. If port1 is simultaneously a member of an SD-WAN zone and referenced in static routes, this creates a configuration conflict. The FortiGate will not allow the same interface to be used in both static routing and SD-WAN zone membership unless the static routes are removed first.
Therefore, the first action is to delete the static routes that use port1 as the egress interface.

Why other options are incorrect:

A: Defining port1 as an SD-WAN member is part of the process, but it cannot be done while port1 is still bound to static routes. The static routes must be removed first.

C: Deleting the "Test" SD-WAN zone is unnecessary. It contains only port2 and does not conflict with adding port1 to a new zone.

D: Deleting firewall policies is not required. The policies shown use port1 as a source/destination interface in rules, which is permissible. Firewall policies can coexist with SD-WAN zones.

Reference
FortiOS 7.6 SD-WAN Administration Guide > Configuring SD-WAN Members: An interface cannot be added to an SD-WAN zone if it is already referenced in a static route. The static route must be removed or modified to use a different interface or an SD-WAN zone itself before the interface can become an SD-WAN member.

Explanation:

Traffic from 10.0.1.130 to 128.66.0.125 matches Router Policy 1, which has an action of deny. Router policies (policy-based routing) are evaluated before SD-WAN rules in the packet processing flow. Since a matching router policy with a deny action is found, the packet is discarded immediately. The SD-WAN rule (Service 4) that also matches this destination is never reached or evaluated. Therefore, despite SD-WAN being configured for load balancing, the traffic is blocked at the routing stage and never forwarded.

Correct Option

A is correct because a router policy with a deny action takes precedence over SD-WAN rules.
The matching policy (src 10.0.1.128/25, dst 128.66.0.0/24, action deny) causes the FortiGate to drop the packet before any SD-WAN path selection occurs.

Incorrect Options:

B: Incorrect. The forwarding information base (FIB) is not used because the router policy denies the traffic first, halting the routing process.

C: Incorrect. The traffic is not load-balanced; it is dropped. Additionally, the SD-WAN members are port1 and port2, not port7 and port8.

D: Incorrect. The traffic is not steered through any interface; it is denied. The referenced interface (port7) is also not a member of the relevant SD-WAN service, which uses port1 and port2.

Reference:
FortiOS 7.6 Router Policy Guide: Router policies are processed in the routing stage before SD-WAN evaluation. If a router policy matches and has action deny, the packet is discarded. The SD-WAN rule logic is only applied if the router policy action is permit or no router policy matches. This order ensures routing policies can override SD-WAN path selection, including blocking traffic entirely.