Select Two (Multi-Select) Questions

Set the IPsec Phase 1 encryption algorithm to DES to speed up decryptions

Why it fails: DES is a weak 56-bit cipher that FortiGate offloads no faster than AES-NI-accelerated AES, so decryption speed does not improve while confidentiality collapses. It tempts administrators who remember legacy CPU-bound encryption, where lighter ciphers helped; DES would only be defensible in a lab or interoperability scenario with obsolete peers.

Disable all SSL inspection globally across the entire FortiGate device

Why it fails: Disabling SSL inspection globally removes visibility into encrypted traffic, so antivirus, IPS and web filtering cannot inspect most sessions — effectively disabling security rather than optimising it. Exempting specific trusted destinations from inspection is the targeted alternative.

Remove the SD-WAN virtual interface from all firewall zones

Why it fails: Removing the SD-WAN virtual interface from all firewall zones strips zone-based policy enforcement, so the security profiles no longer apply to that traffic at all — inspection is bypassed rather than optimised. It appeals when troubleshooting raw throughput, since zone removal eliminates policy lookups, but that is a diagnostic step, not a method of retaining inspection.

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.

Built-in physical layer cabling.

Why it fails: SD-WAN is a software overlay operating at Layer 3 and above; it neither provides nor replaces physical cabling, which remains the underlay's concern. It tempts because SD-WAN does abstract transport links, but cabling is a prerequisite of any WAN, not a benefit it delivers.

Automatic hardware replacement.

Why it fails: SD-WAN virtualises WAN edges in software; it cannot detect failed hardware or dispatch replacements, which remain vendor support and logistics functions. It tempts because SD-WAN simplifies branch provisioning, but automatic hardware replacement is a maintenance contract feature, not an SD-WAN capability.

Editing the individual FortiGate policy

Why it fails: Editing one FortiGate's policy modifies only that device's local configuration, not the shared SD-WAN policy across all managed devices. Per-device edits suit troubleshooting a single firewall's deviation, whereas the scenario demands centralised propagation from FortiManager to every managed FortiGate.

Creating a new ADOM

Why it fails: Creating a new ADOM provisions a separate administrative domain for grouping devices and objects; it neither edits nor installs SD-WAN policy on existing managed FortiGates. ADOMs suit segmenting management by region, tenant or firmware, not pushing policy updates to devices already assigned elsewhere.

Rebooting the FortiManager

Why it fails: Rebooting FortiManager restarts services but pushes no policy changes; installation is triggered from the policy package or via the Install Wizard. A reboot is tempting as a generic "apply everything" fix, yet it is used for clearing stuck processes or applying firmware, not distributing SD-WAN policy to managed FortiGates.

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.

The Install Wizard can only install the entire policy package, not just the SD-WAN template, when multiple FortiGates are selected.

Why it fails: The Install Wizard offers granular installation options. Even when multiple FortiGates are selected, the administrator can choose to install only specific templates or objects, such as an SD-WAN template, rather than the entire policy package. This flexibility is a key feature. The statement that it can only install the entire package is incorrect.

The Install Wizard can push the updated SD-WAN template to all managed FortiGates simultaneously, regardless of their ADOM membership.

Why it fails: The Install Wizard operates within the scope of an ADOM. It cannot push configurations across different ADOMs in a single operation. Each ADOM is a separate management domain, and installations are performed per ADOM. To update devices in multiple ADOMs, the administrator must run separate installations for each ADOM. Therefore, this statement is false.

The Install Wizard requires that all FortiGates be offline before installing an SD-WAN template to prevent configuration conflicts.

Why it fails: The Install Wizard does not require FortiGates to be offline. It can install configurations to online devices. In fact, offline devices cannot receive installations until they come online. The wizard communicates with the FortiGate to apply changes. Requiring offline status would be impractical and is not a requirement. The statement is false.

Dead peer detection enabled on each IPsec tunnel member.

Why it fails: Dead peer detection reports whether an IKE peer is reachable, not whether the path is degraded in terms of latency, jitter, or loss. It can complement SD-WAN health monitoring, but on its own it cannot detect a slow or lossy link that is still passing traffic, so it does not meet the stated design goal.

Interface role set to WAN on every member interface.

Why it fails: Interface role is a labeling feature used for GUI organization and does not influence SD-WAN health evaluation or path selection. Setting the role to WAN may make the configuration easier to read, but it provides no quality measurement and no failover logic, so it is not a required element for this design.

A static route for each member pointing to its gateway, with equal distance values.

Why it fails: Static routes can coexist with SD-WAN but are not the mechanism that delivers quality-based failover. Equal-distance static routes would simply create ECMP behavior or route conflicts, and they carry no awareness of latency, jitter, or packet loss. They do not satisfy the requirement to fail over based on measured path quality.

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

Why it fails: 'Link Health Monitor' is not a feature within an SD-WAN rule; it is a separate configuration (now called Performance SLA) that is applied to interfaces or members. Enabling it within the rule is not possible. The correct approach is to configure a Performance SLA and assign it to members, then reference it in the rule via the strategy. This option is a distractor based on outdated terminology.

Configure the Performance SLA to use HTTP probes to measure jitter.

Why it fails: HTTP probes are not designed to measure jitter; they measure availability and response time for HTTP services. Jitter is typically measured using ICMP or UDP probes that can detect variation in packet delay. Using HTTP probes would not provide accurate jitter metrics for VoIP traffic, and it is not a required action for the scenario. The SLA should use appropriate probe types like ICMP or UDP.

Set the SD-WAN rule strategy to 'Lowest Latency'.

Why it fails: 'Lowest Latency' only considers latency, not jitter. While latency is important for VoIP, jitter is also critical. The 'Best Quality' strategy considers multiple metrics including jitter, making it more suitable. Therefore, setting the strategy to 'Lowest Latency' would not fully address the requirement to consider both latency and jitter.

Create a firewall policy that includes the SD-WAN zone as the outgoing interface and enable NAT.

Why it fails: A firewall policy is needed to allow traffic, but it is not specific to enabling application-based steering with SLA. NAT is often required for internet-bound traffic, but it is not a prerequisite for SD-WAN functionality. The policy itself does not enforce SLA or application steering; those are handled by SD-WAN rules and Performance SLAs. This step is part of general firewall configuration, not the core SD-WAN setup.

Configure a static route for each WAN interface with the same distance.

Why it fails: Static routes are used for basic routing and do not provide SD-WAN steering or SLA enforcement. In an SD-WAN setup, routes are typically handled by the SD-WAN zone itself or by SD-WAN rules. Adding static routes with equal distance could cause ECMP, which is not desired for application-based steering. This step is unnecessary and could interfere with SD-WAN behavior.

Enable application control on the firewall policy that references the SD-WAN zone.

Why it fails: Application control is used to identify and control applications, but it is not a requirement for SD-WAN application-based steering. SD-WAN rules can match traffic based on application signatures or internet service database entries without enabling application control in the firewall policy. While application control can complement SD-WAN, it is not a mandatory step for the described functionality.

Enable 'Gateway' override on all three members to ensure they are prioritized equally.

Why it fails: The 'Gateway' override is used to specify a next-hop IP address that differs from the interface's default gateway. It does not influence path selection based on latency or jitter, nor does it affect failover. Enabling it on all members would not help achieve the requirement and could introduce routing issues if misconfigured. It is unrelated to quality-based selection.

Set the SD-WAN rule strategy to 'Lowest Cost (SLA)' and assign costs based on link quality.

Why it fails: While 'Lowest Cost (SLA)' uses costs and SLA, it selects the lowest-cost member that meets the SLA, not necessarily the one with the best latency and jitter. Costs are static and do not reflect real-time quality. For dynamic selection based on measured latency and jitter, a different strategy such as 'Best Quality' is more appropriate. Therefore, this action alone would not achieve the requirement.

Assign the same cost value to all three members to allow the rule to choose based on quality.

Why it fails: Cost values are used by cost-based strategies, not by the 'Best Quality' strategy. The 'Best Quality' strategy ignores cost and instead uses the Performance SLA measurements. Assigning the same cost to all members would not enable quality-based selection; it would only ensure equal cost if a cost-based strategy were used. Therefore, this action is unnecessary and does not contribute to the requirement.

Enable 'update-static-route' to automatically adjust routing based on SLA.

Why it fails: The 'update-static-route' setting controls whether the SD-WAN rule dynamically updates static routes when SLA status changes. It does not affect the probe protocol or thresholds. While it can be useful for failover, it is not required to meet the specific monitoring requirements of using HTTP and setting latency and packet loss thresholds. Thus, it is not one of the two parameters.

Configure the SLA to use 'jitter' as the primary metric.

Why it fails: Jitter is a different metric that measures variation in latency. The scenario specifies round-trip time (latency) and packet loss, not jitter. While jitter thresholds can be configured, they are not required here. Using jitter as the primary metric would not satisfy the requirement to monitor latency below 100 ms and packet loss below 2%.

Set the probe interval to 100 ms to match the latency threshold.

Why it fails: The probe interval determines how often the SLA probe is sent. Setting it to 100 ms would be extremely aggressive and is not related to the latency threshold. The latency threshold is a separate value that defines the maximum acceptable round-trip time. The probe interval does not need to match the threshold and is not required to meet the scenario's conditions.

Performing a hard factory reset on the FortiGate

Why it fails: A factory reset erases the FortiGate's configuration and management connectivity, so FortiManager cannot push the SD-WAN template to it. It is tempting as a clean-slate measure, and would be valid when a device is corrupted or repurposed and must be re-onboarded from scratch.

Deleting all existing firewall policies

Why it fails: Removing existing firewall policies is unnecessary; FortiManager installs SD-WAN templates alongside current policy, and deletion breaks production traffic. It is tempting when consolidating stale rule sets, and would be correct during a deliberate migration where legacy policies must be replaced rather than retained.

Verify the FortiGate factory default administrator password is changed

Why it fails: Administrator password hygiene has no bearing on SD-WAN path selection; the rule's SLA targets, priority, and link health determine which tunnel is chosen. It is tempting because password checks appear in general hardening audits, but they never influence routing decisions.

Check the physical layer OSI Model cable category connected to the FortiGate port

Why it fails: Cable category affects physical link negotiation, not SD-WAN rule path selection; an application-based rule chooses tunnels by SLA and priority, not by cabling. It is tempting because physical faults cause link-down events, but a working backup tunnel proves layer 1 is fine.

The firmware version of the FortiGate

Why it fails: Firmware version does not feed the SLA probe engine; link health is measured by configured probes (ping, HTTP, UDP echo) against SLA targets, independent of the FortiOS build. It is tempting because firmware governs feature availability, and upgrading would be the right step when a Performance SLA option is missing from the GUI entirely.

The number of active VPN tunnels

Why it fails: Tunnel count is not a direct SLA factor.

Automatic firmware upgrades

Why it fails: SD-WAN templates provision SD-WAN configuration, not device firmware; upgrades are handled by FortiManager firmware management policies or manual upload. It is tempting because FortiManager does centralise firmware deployment across managed devices, but that capability is separate from SD-WAN templates and unrelated to their benefits.

Automated log analysis

Why it fails: SD-WAN templates push configuration objects such as overlay rules and performance SLAs to managed FortiGates; log analysis is performed by FortiAnalyzer, not templates. It is tempting because centralised visibility across the SD-WAN estate is a genuine benefit, but that comes from log forwarding to FortiAnalyzer, not from templates.

Direct access to the FortiGate CLI

Why it fails: SD-WAN templates deliver configuration and provisioning, not interactive CLI sessions; CLI access is provided by the FortiGate console or SSH, not templates. It is tempting because administrators do use CLI for troubleshooting, but templates exist to standardise and push SD-WAN settings, not to open command-line access.

Changes to the log settings on the FortiGate local GUI

Why it fails: Log settings altered through the FortiGate's local GUI are written straight to the device's own configuration, bypassing FortiManager entirely, so no push occurs. It is tempting because FortiManager can centrally manage logging, and it would require a push only when the change originates in a FortiManager policy package or provisioning template.

Adding a new user to the FortiGate local database

Why it fails: Local database users are device-level objects stored on the FortiGate itself, so adding one is made directly on the device and is not provisioned from FortiManager policy packages. It is tempting because FortiManager does manage many FortiGate objects, and it would require a push if the user were defined in a centralised policy package.

Changing the FortiManager admin password

Why it fails: The FortiManager admin password is an attribute of the management server's own administrator accounts, not of the managed FortiGate configuration, so no install operation is triggered. It is tempting because it is an administrative credential change, but it would only matter for FortiManager access, never for FortiGate device configuration.

The system clock is updated.

Why it fails: A clock update shifts timestamps but does not change the SLA probe measurements of latency, jitter or packet loss that determine member health. It tempts because clock drift can disrupt logging and certificate validation, but FortiGate SD-WAN SLA state depends on probe results, not system time.

The firewall policy is disabled.

Why it fails: Disabling a firewall policy stops traffic inspection but does not alter SLA probe results, so the member's link quality measurements remain unaffected. It tempts because policy changes can break connectivity, yet SLA state is driven by probe latency, jitter and packet loss thresholds, not security policy status.

The interface IP address is changed.

Why it fails: Changing an interface IP address does not by itself mark a member down in an SLA; the SLA probes measure latency, jitter and packet loss against configured thresholds. It is tempting because IP reconfiguration disrupts connectivity, but an SD-WAN member is declared down only when probe results breach those SLA criteria.

execute ipsec tunnel list

Why it fails: Enumerates IPsec tunnel names, gateways and status, confirming Phase 1/Phase 2 state but not BGP neighbour relationships or prefix advertisements. It is tempting because BGP over IPsec depends on the tunnel being up, making it the right first check when tunnels are flapping, yet here the tunnel is presumably established and routes are missing.

diagnose sys sdwan member

Why it fails: Displays SD-WAN member link status, SLA and path selection, not BGP peering state or advertised prefixes. It is tempting because SD-WAN tunnel health directly affects whether IPsec overlays carry traffic, making it the right tool when members are down or SLA probes fail, but here the BGP session itself needs inspection.

get system interface physical

Why it fails: Lists physical interface link state, speed and duplex, offering nothing about BGP neighbour adjacency or route advertisement. It is tempting because a down underlay interface would break the IPsec tunnel and hence BGP, making it correct when you suspect a physical-layer fault, but the stem already presumes tunnels are established.

System temperature of the FortiGate

Why it fails: The SD-WAN Monitor surfaces overlay topology, SLA metrics and member link performance, not hardware telemetry such as FortiGate temperature, which appears in system sensors or SNMP monitoring. It is tempting because device health affects SD-WAN, but temperature is not part of this monitor's scope.

The current username of the logged-in admin

Why it fails: The SD-WAN Monitor reports overlay health, SLA performance and link status, not administrator identity, which belongs to audit or admin session logs. It is tempting because admin tracking matters for compliance, but that data sits in event logs rather than the SD-WAN monitoring view.

Interface speed

Why it fails: Interface speed is a link attribute reported by the health check, not a match field evaluated against packets entering an SD-WAN rule; rules match on criteria such as source, destination, application and DSCP. It is tempting because speed feeds SLA comparisons and load-balancing weight calculations, which is a different function.

VLAN priority

Why it fails: SD-WAN rules match on VLAN membership (the VLAN ID), not the 802.1p priority bits carried inside the tag, so priority values are never evaluated during rule lookup. It is tempting because VLAN priority does drive QoS queuing decisions elsewhere in FortiGate, which is a separate mechanism from SD-WAN traffic matching.