Nse7 SD Wan System Configuration And Setup practice questions

Under Firewall Policy.

Why it fails: Firewall policies control traffic flow and security inspection, not interface IP addressing. The gateway address for an SD-WAN member is set within the SD-WAN interface configuration itself, where the member's tunnel endpoint and next-hop gateway are defined. Firewall policy would be the right place for permitting or denying that member's traffic, not for assigning its gateway.

Under Network > Static Routes.

Why it fails: Static routes define destination paths and next hops for routed traffic, not the local gateway address assigned to an SD-WAN member interface. The gateway is configured in the SD-WAN member's interface settings, alongside its IP and tunnel parameters. Static routes would be the correct choice for steering specific subnets over a preferred SD-WAN link.

Under System > Interfaces.

Why it fails: Interface-level IP settings are separate from SD-WAN member gateway definitions.

A FortiManager instance.

Why it fails: FortiManager is optional.

A subscription to FortiGuard SD-WAN service.

Why it fails: SD-WAN is a core feature of FortiOS.

An external load balancer.

Why it fails: FortiGate handles load balancing internally.

The traffic is routed to the management interface.

Why it fails: This is not a default behavior.

The rule becomes inactive.

Why it fails: The rule remains active but with reduced health metrics.

The traffic is dropped.

Why it fails: Traffic defaults to available paths to maintain connectivity.

show system sdwan

Why it fails: This displays the configuration, not the dynamic routing table.

get router info routing-table all

Why it fails: This shows the general routing table, not the specific SD-WAN logic.

diagnose sys route list

Why it fails: This is for traditional static routes.

Load Balance

Why it fails: While a load balance exists, it is often grouped under different naming conventions in some versions, but 'Maximize Bandwidth' is the formal strategy name.

Round Robin

Why it fails: Round Robin is a load balance algorithm, not a rule strategy.

Built-in physical layer cabling.

Why it fails: SD-WAN is a software overlay operating at layers 3 and above; it never provisions or manages physical cabling, which remains a carrier or facilities task. It is tempting because SD-WAN does abstract multiple WAN transports, but that abstraction assumes the underlying links already exist. Benefits centre on path selection, SLA monitoring and failover.

Automatic hardware replacement.

Why it fails: SD-WAN selects paths, monitors SLA and fails over between existing links; it does not dispatch replacement hardware. Hardware replacement is a vendor support or smart-hand replacement entitlement, not an SD-WAN feature. The confusion arises because SD-WAN improves resilience, but that resilience is logical path failover, not physical device substitution.

Enabling SD-WAN in the Feature Visibility menu.

Why it fails: This is usually enabled by default.

Updating the FortiGuard database.

Why it fails: Optional.

Configuring a BGP peer.

Why it fails: Optional.

The FortiGate restarts automatically.

Why it fails: No restart occurs.

The interface automatically reverts to a WAN port.

Why it fails: It remains an interface but without SD-WAN configuration.

All firewall policies referencing the zone are deleted.

Why it fails: They aren't deleted, just potentially broken.

Set the strategy to 'Priority' and assign equal priority to both members.

Why it fails: The 'Priority' strategy selects the member with the highest priority (lowest numeric value) that meets the SLA. It does not distribute traffic across multiple members. Equal priority would still result in only one member being used at a time, failing to utilize both links simultaneously.

Configure a separate SD-WAN rule for each member and enable 'load-balance' in both rules.

Why it fails: Creating separate rules for each member does not achieve simultaneous use of both links for the same traffic. Each rule would be evaluated independently, and traffic would still be directed to a single member per rule. Load balancing across multiple members requires a single rule with a load-balancing strategy.

Set the strategy to 'Lowest Cost (SLA)' and configure both members with equal cost.

Why it fails: 'Lowest Cost (SLA)' selects the member with the lowest cost that meets the SLA, but it does not load-balance traffic across multiple members. Even with equal cost, only one link is used at a time. This strategy is for cost optimization, not for maximizing bandwidth by using multiple links simultaneously.

Priority

Why it fails: 'Priority' selects the member with the highest priority (lowest numeric value) that meets the SLA, regardless of latency or cost. It does not consider latency or cost in its selection process. This strategy is based on administrative preference, not on dynamic performance metrics like latency, so it would not fulfill the stated requirements.

Lowest Cost (SLA)

Why it fails: 'Lowest Cost (SLA)' selects the member with the lowest cost that meets the SLA, but it does not consider latency. In this scenario, you want to prioritize latency first, and then cost as a tiebreaker. This strategy would ignore latency, potentially selecting a higher-latency link if it has lower cost, which does not meet the requirement.

Maximize Bandwidth (SLA)

Why it fails: 'Maximize Bandwidth (SLA)' load-balances traffic across all SLA-compliant members to maximize aggregate bandwidth. It does not select a single member based on latency or cost. This strategy is unsuitable when you need to prioritize the lowest-latency path and use cost only as a secondary criterion.

To define the gateway IP for the route.

Why it fails: The Source field matches traffic by source address to determine which SD-WAN rule applies; the gateway IP is set in the rule's gateway or route configuration. It is tempting because rules do influence forwarding, and it would be the correct field when specifying a next-hop gateway, not for source-based matching.

To force traffic to a specific SD-WAN zone.

Why it fails: The Source field matches traffic originating from specified addresses; forcing traffic into an SD-WAN zone is done through the rule's destination interface or zone setting. It is tempting because both control rule scope, and it would be correct when selecting an outgoing zone, not when identifying source traffic.

To determine which ISP the traffic exits through regardless of SLA.

Why it fails: The Source field matches traffic by originating subnet or address, not by egress interface; ISP selection is driven by the SD-WAN rule's outgoing interfaces and SLA targets. It is tempting because source-based routing does influence path selection, but only as a match criterion feeding the rule, never as a direct ISP override.

show router info bgp

Why it fails: This displays BGP routing table and peer information, not SD-WAN member link status or SLA probe results. It is tempting because BGP neighbours often run across SD-WAN overlays, and would be correct when verifying BGP peering state rather than member health.

get system interface

Why it fails: This lists interface configuration and status, but omits SD-WAN member SLA metrics such as latency, jitter and packet loss. It is tempting because member links are interfaces, and would be correct when checking link up/down state or IP addressing rather than SLA health.

get system sdwan member

Why it fails: This command does not exist in FortiOS; SD-WAN member and SLA status is verified with 'diagnose sys sdwan member' or 'diagnose sys sdwan health-check'. It is tempting because it mirrors the configuration path 'config system sdwan', and would be correct if FortiOS exposed member status through a get system command.

Probe Mode

Why it fails: Probe Mode selects the probe type (ping, HTTP, DNS, TCP) and defines how reachability is tested, not the latency, jitter and packet-loss values that mark an interface unhealthy. It is tempting because probe configuration precedes SLA evaluation, but the thresholds themselves live in the SLA target settings.

Sequence Number

Why it fails: Sequence Number orders SLA probe packets and helps detect reordering or loss; it sets no health threshold. It is tempting because sequence data feeds the measured metrics, yet the values that flip an interface to unhealthy are the latency, jitter and packet-loss thresholds configured in the SLA target.

Update Interval

Why it fails: Update Interval controls how often probe results refresh the SD-WAN routing table, not the values that classify an interface as unhealthy. It is tempting because frequent updates change responsiveness to failures, but the actual unhealthy determination comes from the SLA target's latency, jitter and packet-loss thresholds.

Manual

Why it fails: Manual strategy requires each member's priority to be set by hand and selects a single link; it cannot distribute sessions by bandwidth weight. It tempts because manual is the correct choice when an administrator wants deterministic, fixed link preference rather than automated per-link load sharing based on measured capacity.

Lowest Cost (SLA)

Why it fails: Lowest Cost (SLA) picks the single member meeting the SLA with the cheapest measured link cost, so it cannot spread sessions proportionally by weight. Weighted distribution is the job of the Maximize Bandwidth (SLA) strategy, which load-balances across qualifying members.

SLA Target

Why it fails: SLA Target steers traffic to whichever member satisfies the configured latency, jitter and packet-loss thresholds, selecting one active path rather than apportioning sessions by weight. Weighted distribution across interfaces is performed by Maximize Bandwidth (SLA).

Round Robin

Why it fails: Lowest Cost (SLA) selects the member with the lowest configured cost value among those meeting SLA targets, not round robin. Round robin is tempting because it is a genuine SD-WAN load-balancing strategy, and it would be correct when the rule uses a load-balance algorithm rather than cost-based selection.

The interface with the highest bandwidth.

Why it fails: Lowest Cost (SLA) ranks members by their configured cost metric, not by measured bandwidth. Highest bandwidth is tempting because bandwidth influences SD-WAN health checks and SLA targets, and it would be correct under a Maximize Bandwidth (SLA) strategy rather than Lowest Cost.

The interface that was most recently added to the zone.

Why it fails: Member selection under Lowest Cost (SLA) depends on configured cost values, not on the order interfaces joined the zone. Recency is tempting because zone membership order can matter for some failover behaviours, and it would be relevant when no cost or SLA differentiation exists between members.

It increases the throughput of individual physical links.

Why it fails: A zone aggregates member links for path selection and failover; each physical interface retains its own bandwidth ceiling, so aggregate capacity rises but per-link throughput does not. Zones are chosen when several WAN circuits must be treated as one logical egress path.

It prevents the need for performance SLAs.

Why it fails: SLA measurement and enforcement still apply to each member link; zones exist to steer traffic across those links according to health and quality metrics. Zones are the correct design when multiple circuits must satisfy contractual performance targets, not when those targets are removed.

It automatically enables load balancing between interfaces.

Why it fails: Load balancing requires an explicit SD-WAN rule with a load-balance strategy; grouping interfaces alone only makes them members of one logical zone. Zones are the right construct when you want a single policy target for several links before defining how traffic is distributed.

Configure a performance SLA for that specific interface.

Why it fails: A performance SLA is optional and applied per SD-WAN rule or policy to probe link quality, not a prerequisite for zone membership. It is tempting because SLA probes drive dynamic path selection, and they would be configured later for the same interface once it belongs to a zone.

Assign a VLAN ID to the interface.

Why it fails: VLAN tagging is a Layer 2 attribute set on the physical or VLAN sub-interface itself; SD-WAN zone membership requires no VLAN ID. It is tempting because sub-interfaces are common SD-WAN members, but the tag belongs to the interface definition, not the zone-assignment step.

Enable SD-WAN on the global system settings.

Why it fails: SD-WAN is enabled implicitly by creating the zone and adding members; there is no global system setting to toggle. It is tempting because other FortiGate features do require a global enable, but SD-WAN zone configuration itself activates the feature without any prerequisite system-wide switch.

Traffic is dropped.

Why it fails: Priority strategy fails over to the next-highest member when the top member breaches its SLA, so traffic continues rather than being discarded. Dropping is tempting because a member marked dead is removed from selection, but that removal triggers failover, not a blackhole; dropping would only occur with no viable member left.

The FortiGate enters an error state.

Why it fails: SLA failure on the highest-priority member simply marks it ineligible and promotes the next member; the FortiGate keeps forwarding and logs the event. An error state is tempting because SLA health checks can raise alerts, but those are monitoring notifications, not a device fault that halts SD-WAN processing.

Traffic is load balanced across all remaining members.

Why it fails: Priority strategy selects one member at a time, so it fails over to the single next-highest member rather than spreading sessions across all survivors. Load balancing is tempting because it is exactly what the Lowest Cost (SLA) and Maximise Bandwidth strategies do, but Priority deliberately avoids per-session distribution.

TCP Echo

Why it fails: TCP Echo is a valid Performance SLA probe type, so it cannot be the protocol that is not valid. It is tempting because TCP Echo genuinely measures round-trip connectivity to a target port, and would be the right probe when you need to verify basic TCP reachability rather than application-layer response.

HTTP

Why it fails: HTTP is a valid Performance SLA probe protocol, so it cannot be the exception the question seeks. Its tempting familiarity as a monitoring method obscures that the stem asks for the invalid protocol; HTTP probes correctly measure web-service latency and availability in SLA definitions.

ICMP

Why it fails: ICMP is a valid Performance SLA probe type in FortiGate SD-WAN, alongside HTTP, TCP echo and UDP echo, so it cannot be the excluded protocol. It would be correct when the SLA must measure reachability and latency to a target address.

It changes the frequency of the probes.

Why it fails: Hold-down sets how long a member stays out of service after an SLA failure before being reused, not probe frequency. It is tempting because both timers live in the Performance SLA configuration, and hold-down would be the correct answer if the question asked about probe interval instead.

It sets the maximum number of failed probes allowed.

Why it fails: Hold-down sets how long an SLA member stays down after a probe failure before being marked up again; it does not cap failed probes. The failed-probe threshold is configured separately as the SLA's failure count. It is tempting because both parameters govern SLA member state transitions, so they are easily confused.

It determines the timeout duration for a single probe.

Why it fails: Probe timeout is configured per-probe (the interval and timeout values), whereas hold-down governs how long the member remains down after failures before recovery. It is tempting because both timers affect SLA state, but hold-down acts on member status, not on individual probe response waiting.