Fortinet NSE 6 - SD-WAN 7.6 Enterprise Administrator — Free Practice Questions
10 free sample questions from a bank of 42, with the correct answers and explanations. No signup required — start practising right now.
- SD-WAN rules are skipped if the best route to the destination is not an SD-WAN member.
- Routes to directly connected subnets have precedence over SD-WAN rules.
- SD-WAN rules are skipped if the best route to the destination is a static route.
- SD-WAN members are skipped if they do not have a valid route to the destination.
- Internet Service Database (ISDB) routes have precedence over SD-WAN rules.
The short version
A, B, D — FLIP: routing principles are member-best-path gating, connected precedence, and no-route skipping. ISDB does not precede SD-WAN (Q54's banked lookup order proves it).
Key concepts in this question
- Best-route gating: rules apply only when the best path rides a member.
- Connected routes beat SD-WAN; routeless members are skipped.
Why A, B and D are correct
Gating (A), connected precedence (B), and member validity (D) are the documented principles.
Why the others are wrong
- C. Static-via-member routes still steer; no static skip exists.
- E. Q54's lookup order (policy, SD-WAN, ISDB, BGP) puts SD-WAN ahead of ISDB — no ISDB precedence.
SD-WAN exam tip
SD-WAN steers when best path is a member; connected always wins.
- The template Corp-SOT defines a single-hub topology
- branch3_fgt is configured with three SD-WAN overlay tunnels and one is dead.
- The three spokes have tunnels that are out of SLA.
- Three tunnels of branch2_fgt are out of SLA.
The short version
D — approved. The hover popup plus orange out-of-SLA lines show branch2_fgt has three tunnels breaching SLA, while the topology is dual-hub.
Key concepts in this question
- SD-WAN Monitor Template View: Hover shows device role, failed health-check interfaces and down underlays for the selected template.
- Down vs out-of-SLA: Down interfaces list dead tunnels; orange device/lines mean some health checks pass and some breach SLA.
- Dual-hub reading: HUB1-VPNx plus HUB2-VPNx names prove two hubs, ruling out single-hub.
Why D is correct
On image1.png the branch1_fgt popup lists Down Interfaces HUB2-VPN1, HUB2-VPN2 and HUB2-VPN3, proving HUB1+HUB2 dual-hub overlays exist. The map lines for branch2_fgt (Miami) are orange, which per Template View logic means some health checks breach SLA, matching three branch2 tunnels out of SLA.
Why the others are wrong
- A. Single-hub is false because both HUB1-VPNx and HUB2-VPNx interfaces appear in the popup.
- B. Nothing shows branch3_fgt with three tunnels and one dead; the dead list belongs to branch1_fgt.
- C. Only branch2 shows out-of-SLA lines, not all three spokes.
NSE6_SDW_AD-7.6 exam tip
Orange spoke = some SLA breached; red down list = dead tunnels; HUB1+HUB2 names = dual-hub.
- On the hubs, auto-discovery-forwarder must be enabled on the IPsec VPNs to hubs.
- On the spokes, auto-discovery-receiver must be enabled on the IPsec VPNs to the hub.
- On the hubs, auto-discovery-receiver must be enabled on the IPsec VPNs to spokes.
- On the spokes, auto-discovery-sender must be enabled on the IPsec VPNs to hubs.
The short version
A and B — inter-region ADVPN needs hub forwarders plus spoke receivers. Hubs relay queries across regions; spokes accept them.
Key concepts in this question
- auto-discovery-forwarder: hubs forward shortcut queries to peer hubs.
- auto-discovery-receiver: spokes receive shortcut offers and queries.
- Redundant hub-to-hub VPNs: the forwarding path between Region A and Region B.
Why A and B are correct
Spoke A1 and spoke B2 sit behind different hubs, so the shortcut query must transit Hub A1 to Hub B2. That transit requires forwarder enabled on the hub-to-hub IPsec VPNs (A). Each spoke must be able to receive the resulting shortcut data on its hub-bound VPN, which is the receiver role (B).
Why the others are wrong
- C. Receiver on hub-to-spoke VPNs inverts the direction; hubs forward and send, spokes receive.
- D. Sender on spokes describes query origination, not the required receiving plus forwarding pair for this cross-hub design.
SD-WAN exam tip
Cross-hub shortcut = forwarder on hubs, receiver on spokes.
- UDP traffic destined to the subnet 10.22.0.0/24 matches a policy route.
- At least one SD-WAN rule is defined with application categories as the destination.
- At least one SD-WAN rule allows traffic load balancing.
- UDP traffic destined to the subnet 10.22.0.0/24 matches a manual SD-WAN rule.
The short version
A and B — policy route covers 10.22.0.0/24 UDP and app-based SD-WAN rules exist. First entry is a policy route; later entries match applications.
Key concepts in this question
- diagnose firewall proute list: shows policy routes plus SD-WAN (vwl_service) entries.
- Policy route vs SD-WAN rule: id=1 has no vwl_service, so it is a policy route.
- Application control destinations: Microsoft.Portal, Storage.Backup and Social.Media prove app-aware rules.
Why A and B are correct
Entry id=1 matches protocol 17 (UDP) to 10.22.0.0-10.22.0.255 via 10.0.1.253 with no SD-WAN service tag, so UDP to that subnet matches a policy route (A). The vwl_service entries list application-control categories as destinations, proving at least one SD-WAN rule uses application categories (B).
Why the others are wrong
- C. Multiple oifs show candidate members, not proof of a load-balancing strategy; mode cannot be read here.
- D. The 10.22.0.0/24 UDP entry lacks vwl_service, so it is not a manual SD-WAN rule.
SD-WAN exam tip
No vwl_service = policy route; app-control lines = app-aware SD-WAN rules.
- The best quality strategy supports only the round-robin hash mode.
- When applicable, FortiGate load balances the traffic through all members that meet the SLA target.
- You can select the best quality strategy and allow SD-WAN load balancing.
- You can select the lowest cost service level agreement (SLA) strategy and allow SD-WAN load balancing.
The short version
B and C — quality-aware balancing needs best-quality plus eligible members. The strategy picks among members meeting the SLA target.
Key concepts in this question
- Best-quality strategy: picks the healthiest eligible member.
- SLA eligibility: only members meeting the target serve traffic.
- Cost/round-robin myths: no lowest-cost SLA strategy; hashing is not round-robin-only.
Why B and C are correct
FortiGate balances through all members meeting the SLA target under the best-quality strategy.
Why the others are wrong
- A. Best quality is not restricted to round-robin hashing.
- D. No lowest-cost SLA strategy exists for this purpose.
SD-WAN exam tip
Quality balancing is best-strategy plus SLA-eligible members. Cost never steers.
- The traffic will be routed over HUB1-VPN1.
- The traffic will be load balanced across all three overlays.
- The traffic will be routed over HUB1-VPN2.
- The traffic will be routed over HUB1-VPN3.
The short version
C — matching traffic goes over HUB1-VPN2. Best-SLA member VPN3 has no route to the destination, so next-best VPN2 wins.
Key concepts in this question
- SLA bitmask: sla(0x3) beats 0x2 beats 0x0 for two configured SLAs.
- Route gating: members without a valid route to the destination are skipped.
- Mode sla: pick best SLA among routable members.
Why C is correct
Rule 3 targets Corp-net (10.1.0.0/16 in the service output). VPN3 has sla(0x3), both SLAs met, but the routing table has 10.1.0.0/24 only via VPN1 and VPN2, with 10.2.0.0/24 via VPN3, so VPN3 is skipped for this destination. Between the routable members, VPN2 at sla(0x2) beats VPN1 at sla(0x0), so traffic steers to HUB1-VPN2.
Why the others are wrong
- A. VPN1 meets no SLA (0x0) and loses to VPN2 despite top cfg_order.
- B. Mode is sla, not load-balance; only one member is selected.
- D. VPN3 is best-SLA overall but has no valid route to 10.1.0.0/24.
SD-WAN exam tip
SLA first, then route check: best SLA with a route wins.
- On the hub, set the tunnel type to static.
- On the spoke, set the parameter net-device to enable.
- On the spoke, configure the parameter localid.
- On the hub, set the parameter mode-cfg to enable.
The short version
B and D — BGP-over-IPsec hub-spoke needs spoke net-device plus hub mode-cfg. Interface mode meets dialup config.
Key concepts in this question
- net-device enable on spokes exposes tunnel interfaces for BGP.
- mode-cfg on hubs serves spokes dynamic config.
Why B and D are correct
The two documented recommended settings (3v2).
Why the others are wrong
- A. Static tunnel types defeat dialup spoke scaling.
- C. localid is optional, not recommended-required.
SD-WAN exam tip
BGP hub-spoke = net-device + mode-cfg.
- FortiManager will create an overlay tunnel on the port2 interface.
- FortiManager will define port5 as a BGP neighbor.
- FortiManager will create an overlay tunnel on the port1 interface.
- FortiManager will define port2 as a BGP neighbor.
The short version
A and C — secondary hub builds one overlay per underlay: port1 and port2. Port5 is advertised, not a BGP peer.
Key concepts in this question
- Underlay to overlay mapping: each WAN Underlay entry spawns an overlay tunnel.
- Network Advertisement: Connected plus Interface port5 means advertise, not peer.
- BGP on Loopback off with Dynamic BGP: neighbors are dynamic overlay peers, not local ports.
Why A and C are correct
The exhibit lists WAN Underlay 1 on port1 and WAN Underlay 2 on port2 for dc2_fgt, so the orchestrator creates an overlay tunnel on each interface. That yields both port1 and port2 tunnels regardless of the Private Link toggle, which only marks link type.
Why the others are wrong
- B. Port5 under Network Advertisement is a network to advertise, not a BGP neighbor definition.
- D. Port2 is an underlay source interface; BGP neighbors form over overlays and loopbacks, not the underlay port itself.
SD-WAN exam tip
Two underlays = two overlays; advertisement interfaces are not BGP neighbors.
- Define metadata variable values for each device.
- Create model devices.
- Create a zero-touch provisioning (ZTP) template.
- Create a policy blueprint.
The short version
B and C — 50 branches pre-stage with model devices plus ZTP templates. Model now, touch never.
Key concepts in this question
- Model devices pre-create branch objects.
- ZTP templates deliver zero-touch onboarding.
Why B and C are correct
The two documented advance tasks.
Why the others are wrong
- A. Per-device metadata needs devices first.
- D. Policy blueprints follow, not precede, modeling.
SD-WAN exam tip
Scale branches = model + ZTP.
- SD-WAN service rule 3 and interface HUB1-VPN2.
- SD-WAN service rule 4 and port1 or port2.
- SD-WAN service rule 3 and interface HUB1-VPN3.
- SD-WAN service rule 4 and interface port2.
The short version
C — LAN to 10.2.5.254 uses service 3 over HUB1-VPN3. Lower rule ID wins; FIB tie-break picks VPN3.
Key concepts in this question
- Rule precedence: service 3 is evaluated before service 4.
- Tie break fib: among SLA-eligible members, the FIB route decides.
- FIB for 10.2.5.0/24: points via HUB1-VPN3.
Why C is correct
Both service 3 (10.0.0.0/8) and service 4 (10.2.0.0/16) cover 10.2.5.254, so service 3 wins by order. Its members VPN1, VPN2 and VPN3 are all alive and selected with tie break fib. The routing table carries 10.2.5.0/24 via HUB1-VPN3, so the FIB tie-break steers the flow to HUB1-VPN3 under rule 3.
Why the others are wrong
- A. VPN2 is eligible but not the FIB choice for 10.2.5.0/24.
- B. Service 4 with port1/port2 never evaluates because service 3 already matches.
- D. Port2 under service 4 is shadowed by the earlier service 3 match.
SD-WAN exam tip
Overlapping rules: lowest ID wins, then FIB breaks the tie.
Want the full bank of 42 questions for Fortinet NSE 6 - SD-WAN 7.6 Enterprise Administrator? See all practice exams.