Hard Difficulty Questions

The member is considered in SLA because latency is within threshold, so it remains eligible for rules.

Why it fails: SLA evaluation requires all configured thresholds to be satisfied, not just one. Although latency is within the 200 ms limit, the 8% packet loss exceeds the 5% limit, so the member cannot be considered healthy. Treating it as in-SLA would allow degraded traffic onto a lossy link and violate the SLA definition.

The member is in SLA but is flagged with a warning that only affects logging, not rule selection.

Why it fails: There is no warning-only state in Performance SLA evaluation; a threshold breach changes the member's health status and directly affects rule eligibility. Logging is a side effect of the state change, not a separate tier. The member would be excluded from SLA-aware rules, so this option misstates the behaviour.

The member is out of SLA only if latency and packet loss both exceed their thresholds simultaneously.

Why it fails: Thresholds are evaluated independently and combined with an AND condition for success, meaning any single breach causes failure. Requiring both to exceed simultaneously would be an OR-style logic that FortiGate does not use for SLA health. Under this incorrect interpretation, a severely lossy link could still be selected, which is unsafe.

The FortiGate requires a reboot after installing a new SD-WAN rule.

Why it fails: FortiGates do not require a reboot to apply new SD-WAN rules. Configuration changes from FortiManager are applied dynamically. A reboot would be unnecessary and disruptive. The issue is more likely related to the interface not being properly configured in the SD-WAN zone.

The SD-WAN template was not saved before installation.

Why it fails: If the template was not saved, the installation would not include the changes, but the administrator explicitly modified the template and then installed the policy package. Assuming the save was performed, this is not the likely cause. The more probable issue is the overlay interface not being part of the SD-WAN zone.

The SD-WAN rule priority is lower than the default route.

Why it fails: SD-WAN rules are evaluated based on their order and criteria, not by comparison with the default route. The default route is used when no SD-WAN rule matches. If the rule is not taking effect, it is more likely due to interface membership or mapping issues rather than route priority.

psksecret

Why it fails: psksecret is the pre-shared key used for authentication. It has no role in binding the tunnel to an interface or controlling when the tunnel is established based on interface status. It is purely a security parameter and does not affect SD-WAN integration or interface binding.

remote-gw

Why it fails: remote-gw defines the public IP address of the remote peer. While necessary for tunnel establishment, it does not bind the tunnel to a local outgoing interface. The FortiGate will use the routing table to determine the outgoing interface based on the remote-gw, which may not be the desired interface if multiple paths exist.

local-gw

Why it fails: local-gw specifies the local gateway IP address to be used for the IPsec tunnel, which is useful when the FortiGate has multiple public IPs on the same interface. However, it does not bind the tunnel to a specific outgoing interface; the tunnel can still use any interface that routes to the remote gateway. Binding to a specific interface requires a different setting.

SD-WAN rule with strategy set to 'lowest cost (SLA)' and the latency SLA referenced.

Why it fails: The 'lowest cost (SLA)' strategy selects the member with the lowest cost among those that meet the SLA, not necessarily the lowest latency. Cost is based on the interface's configured cost, not the measured latency. To select based on latency, a different strategy or metric must be used. This option would not guarantee the lowest latency member is chosen.

SD-WAN rule with strategy set to 'maximize bandwidth (SLA)' and the latency SLA referenced.

Why it fails: The 'maximize bandwidth (SLA)' strategy selects the member with the highest available bandwidth that meets the SLA. It does not consider latency as the primary selection criterion. While the SLA ensures latency is within bounds, the chosen member may not have the lowest latency. This strategy is suitable for bandwidth-intensive applications, not latency-sensitive ones.

SD-WAN rule with strategy set to 'load balance' and the latency SLA referenced.

Why it fails: The 'load balance' strategy distributes traffic across multiple members that meet the SLA, without prioritizing the lowest latency. It is used for aggregate throughput, not for selecting the single best member by latency. The rule would not consistently choose the member with the lowest latency, making it unsuitable for the requirement.

Meta fields

Why it fails: Meta fields are used to store custom metadata about devices, but they do not directly control the application of SD-WAN rules. They can be used in scripts or dynamic mapping, but they are not the feature that conditionally applies rules based on tags. The question asks for a feature that applies a rule based on a tag, which is not meta fields.

Provisioning templates

Why it fails: Provisioning templates are used to configure system settings, not SD-WAN rules. They do not support conditional application based on tags. While they can be assigned to devices, they lack the dynamic mapping capability needed to apply specific SD-WAN rules based on device tags.

Policy packages

Why it fails: Policy packages are used for firewall policies and NAT, not SD-WAN rules. They are assigned to devices but do not provide a mechanism to conditionally apply SD-WAN rules based on tags. The question specifically asks about SD-WAN rules, so policy packages are not the correct feature.

IPS and Application Control cannot be applied to SD-WAN zones; the profiles are silently ignored, and the resets are caused by the missing inspection.

Why it fails: FortiOS allows IPS and Application Control on policies referencing SD-WAN zones. The profiles are not ignored. If they were ignored, sessions would not be reset by profile re-evaluation; the resets are caused by SD-WAN session re-evaluation when an SLA member fails, which is a documented behavior.

The 'maximize bandwidth (SLA)' strategy ignores SLA health checks and only uses link capacity, so when a member saturates, IPS drops packets and resets the session.

Why it fails: The maximize bandwidth (SLA) strategy does consider SLA targets and will exclude members that fail the SLA. It is not purely capacity-based. Saturation alone would cause packet loss, but the described resets correlate with health-check failure and session re-evaluation, not with the strategy ignoring SLA.

The security profile group is applied to the SD-WAN zone, but FortiOS requires profiles to be bound to each member interface individually; the zone-level binding causes mid-stream resets.

Why it fails: FortiOS supports applying security profiles to policies that reference an SD-WAN zone; the profile is enforced on the zone, not per member. Binding profiles per member is not required and would be operationally impractical. The resets stem from session re-evaluation during SLA failure, not from zone-level profile binding.

Increase the cost value configured on wan2 above the cost on wan1

Why it fails: Cost values are consumed by the lowest-cost strategy, where a lower cost is preferred. Raising wan2's cost above wan1's makes wan1 even more strongly preferred, which is the opposite of the goal. If the strategy is not changed, cost is the deciding factor, so this edit reinforces the current behavior instead of reversing it.

Add a Performance SLA probe on wan2 with a shorter probe interval than wan1

Why it fails: Probe interval controls how frequently health is sampled and how quickly a member is marked up or down; it does not change which member is selected when both are healthy. Shortening wan2's interval only makes its state changes more responsive. It cannot override the lowest-cost ranking, so traffic would still follow the lower-cost member.

Lower the cost value configured on wan1 below the cost on wan2

Why it fails: This again manipulates cost under the lowest-cost strategy and makes wan1 the cheaper, preferred member. It deepens the existing preference rather than moving traffic to wan2. Cost-based selection has no notion of a manual preferred member, so no cost edit alone can make wan2 the first choice while keeping wan1 as failover.

The changes take effect immediately without a push

Why it fails: Edits to an SD-WAN template sit in FortiManager until installed; they do not reach the FortiGate immediately without a push. It is tempting because some central management tools propagate changes live, but FortiManager requires the administrator to install the template to the device.

The FortiGate automatically pulls the new config

Why it fails: Template changes are not auto-pulled by the FortiGate; the administrator must push the updated template, or the device keeps its previously installed configuration. It is tempting because many management platforms sync automatically, but FortiManager SD-WAN templates require an explicit install action.

The FortiGate configuration is reverted

Why it fails: Modifying a template does not revert the FortiGate configuration; the device retains its last installed template until a new install occurs. It is tempting as a rollback assumption, but reverting requires explicitly installing a previous revision or restoring a backup.

Configure a static route with equal distance for both WAN links.

Why it fails: Equal-distance static routes would cause ECMP, not SLA-based selection. SD-WAN rules operate independently of static route metrics. While routes are needed for underlay reachability, they do not control SD-WAN rule behavior. This option confuses routing with SD-WAN policy and would not achieve the desired SLA-driven failover.

Set the rule's strategy to 'Lowest Cost' and assign costs to each member.

Why it fails: The 'Lowest Cost' strategy selects members based on configured costs, not performance SLAs. It does not consider SLA violations for failover. While useful for cost optimization, it does not meet the requirement of SLA-based selection and failover. This option would not provide the dynamic performance-based behavior needed.

Enable 'Link Health Monitor' on the SD-WAN zone.

Why it fails: Link Health Monitor is not a separate feature; it is part of Performance SLA configuration. Enabling it on a zone is not a valid step. The SLA must be configured on the members, not the zone. This option misrepresents the configuration model and would not provide the required SLA-based selection.

Loopback interfaces

Why it fails: Loopbacks don't have egress paths.

Aggregate interfaces

Why it fails: Aggregate is not a direct member type.

The system selects the one with the highest bandwidth capacity.

Why it fails: Bandwidth is not the primary driver for SLA Target strategy.

The system selects the member with the best performance (e.g., lowest latency).

Why it fails: It dynamically selects the best performer.

Traffic is sent through all of them simultaneously.

Why it fails: This would require load balancing.

BGP Multipath relaxing with maximum-paths set to 32

Why it fails: Multipath is used for load balancing across multiple parallel paths to the same destination, not hub-and-spoke ADVPN route reflection.

Static default route redistribution with aggregate-address suppression

Why it fails: Aggregate suppression does not solve dynamic spoke-to-spoke route advertisement.

BGP Confederation with each spoke acting as a separate autonomous system

Why it fails: ADVPN uses iBGP or eBGP; confederations add unnecessary complexity and are not standard for simple spoke-hub ADVPN scaling.

The FortiGate automatically creates a dummy interface

Why it fails: FortiGate does not fabricate interfaces; template installation aborts because the referenced interface is absent from the target device. It is tempting because some management platforms auto-provision missing objects, and dummy interface creation would be correct if the platform supported dynamic interface synthesis during template deployment.

The installation proceeds and ignores the missing interface

Why it fails: Installation does not silently skip the missing interface; the template push fails because the referenced object cannot be resolved on the target FortiGate. It is tempting because templates often tolerate optional fields, and ignoring missing references would be correct if the interface were marked optional rather than required.

The FortiGate enters an 'Emergency' state

Why it fails: A missing interface reference causes the template installation to fail with an error; the FortiGate does not drop into Emergency mode, which occurs on boot failure or corrupted firmware. It is tempting because failed configuration pushes can leave a device unreachable, and Emergency mode would be the correct outcome for a failed firmware boot.

SD-WAN health check probes are overwhelming the IPsec tunnel bandwidth

Why it fails: SD-WAN health check probes consume minimal bandwidth and do not cause application connection drops.

The Antivirus proxy buffer is overflowing due to UDP streaming packets

Why it fails: Antivirus inspection handles TCP streams primarily; UDP traffic goes through flow-based or proxy-based inspection differently and does not typically overflow buffers based on MTU mismatch.

The SSL inspection profile is attempting to decrypt UDP traffic, causing kernel panic and packet drops

Why it fails: SSL/TLS inspection applies to TCP traffic, not raw UDP streams.

AS-PATH prepend

Why it fails: AS-PATH prepending is used to influence inbound traffic selection from external ASes, not primarily for internal SD-WAN tunnel path preference.

Cluster ID

Why it fails: Cluster ID is used in BGP route reflection loops prevention, not path selection.

Origin code

Why it fails: Origin code indicates how the BGP route was learned (IGP, EGP, Incomplete) and is not used for path preference tuning.

WAN2, because it has lower packet loss than WAN1, which is the most important metric.

Why it fails: Best Quality does not prioritize packet loss over other metrics; it requires all thresholds to be met. WAN2 fails the jitter threshold, so it is ineligible regardless of its lower packet loss. The strategy would not select a member that violates any SLA threshold.

WAN2, because it has the lowest latency among the members that meet the packet loss threshold.

Why it fails: WAN2 has higher latency than WAN1 (90 ms vs 80 ms) and also fails the jitter threshold. Best Quality considers all SLA metrics and requires all thresholds to be satisfied. Since WAN2 fails jitter, it cannot be chosen even if it had the lowest latency.

Neither member will be selected because both must meet all SLA thresholds for any to be chosen.

Why it fails: Best Quality evaluates each member independently. WAN1 meets all thresholds, so it is eligible. The rule does not require all members to meet the SLA; it selects the best among those that do. Since WAN1 is eligible, it will be selected.

The tunnel interface is not added to the SD-WAN zone.

Why it fails: If the tunnel were not in the SD-WAN zone, it would not be monitored by the health check at all. The scenario implies the tunnel is part of the SD-WAN zone because health checks are failing and marking it down. Therefore, this is not the cause.

The SD-WAN health check is configured with the wrong protocol (e.g., HTTP instead of ping).

Why it fails: The protocol mismatch could cause health check failures if the server does not respond to that protocol. However, the administrator has not indicated that the protocol is wrong; it is a possibility but less likely than a routing issue. The scenario states the administrator verifies selectors, implying other basic checks are done. Routing is a more fundamental and common cause.

The IPsec tunnel's Phase 1 proposal does not match the remote gateway.

Why it fails: If the Phase 1 proposal did not match, the tunnel would not come up at all. The scenario states the tunnel is up, so Phase 1 is correctly negotiated. Therefore, this is not the cause of health check failures.

Install the SD-WAN template on each FortiGate individually.

Why it fails: Installing individually would be extremely time-consuming for 200 devices and is not the intended workflow. FortiManager provides bulk installation options. While individual installation would technically work, it is inefficient and not required; the administrator can use a single install action to push changes to all devices at once.

Manually edit the SD-WAN configuration on each FortiGate via CLI.

Why it fails: Manually editing each FortiGate via CLI defeats the purpose of centralized management and is prone to errors. It would also cause configuration drift, as FortiManager would eventually overwrite manual changes during the next install. The correct approach is to use FortiManager's installation workflow to propagate the approved changes.

Reboot each FortiGate to apply the new health check settings.

Why it fails: Rebooting FortiGates does not apply configuration changes from FortiManager. Configuration changes are applied through an install operation, not a reboot. Rebooting would cause unnecessary downtime and would not update the SD-WAN health check settings; the changes would remain pending in FortiManager.

SLA target name.

Why it fails: An SLA target defines the performance probe used to select a member link, so it belongs on the destination or link-selection side, not as a source. It is tempting because SLA targets are central to SD-WAN rules, and would be correct if the question asked which criterion determines outbound link selection.

Interface MAC address.

Why it fails: SD-WAN rules match sources by subnet, IP address, user group or geography; a MAC address is a layer-2 attribute not exposed as a rule source. It is tempting because MAC addresses identify interfaces at layer 2, and would be correct if the question concerned interface-level or layer-2 matching.

Firewall policy ID.

Why it fails: A firewall policy ID is a security construct applied after SD-WAN path selection, so it cannot identify traffic entering an SD-WAN rule. It is tempting because firewall policies do classify and steer traffic, and would be correct if the question asked about security policy matching rather than SD-WAN rule source criteria.

Enable per-device mapping in FortiManager to manually assign each interface for every FortiGate.

Why it fails: Per-device mapping requires manual assignment of interfaces for each FortiGate, which is labor-intensive and error-prone in large deployments. While it can handle different interface names, it does not scale and does not ensure consistency automatically. The goal is to avoid manual per-device configuration, so this is not the correct action.

Configure a separate SD-WAN template for each device model to accommodate interface differences.

Why it fails: Creating separate templates for each device model defeats the purpose of centralized management and increases administrative overhead. It does not address interface name variations within the same model and leads to template sprawl. The correct approach is to use dynamic mapping or zones to make a single template adaptable to different interfaces.

Use the same interface names on all FortiGates by renaming interfaces to match the template.

Why it fails: Renaming interfaces on all FortiGates to match the template is impractical and may not be possible in all environments. It also requires manual changes on each device and could disrupt existing configurations. This approach does not leverage FortiManager's automation features and is not a recommended method for handling interface name differences.