Scenario practice questions

An administrator needs to configure an SD-WAN rule that load-balances traffic across two WAN links based on the volume of traffic, ensuring that both links are utilized proportionally to their configured weights. Which SD-WAN rule strategy should be selected?

Trap 1: Maximize Bandwidth (SLA)

The 'Maximize Bandwidth (SLA)' strategy distributes traffic across all members that meet the SLA, aiming to use the aggregate bandwidth. However, it does not consider configured weights; it uses a hash-based distribution that may not be proportional to link capacity. While it utilizes multiple links, it does not provide weighted load balancing as required.

Trap 2: Priority

The 'Priority' strategy selects members based on their priority order, using the highest-priority member that meets the SLA. It does not load-balance across multiple links; it only fails over to the next priority when the current one fails. This would not distribute traffic proportionally, so it does not meet the requirement.

Trap 3: Lowest Cost (SLA)

The 'Lowest Cost (SLA)' strategy selects the member with the lowest cost that meets the SLA. It does not distribute traffic based on volume or weights; instead, it prefers a single member until it fails the SLA. This would not achieve proportional load balancing across both links. Therefore, it is not suitable for the described requirement.

A
Maximize Bandwidth (SLA)
Why it fails: The 'Maximize Bandwidth (SLA)' strategy distributes traffic across all members that meet the SLA, aiming to use the aggregate bandwidth. However, it does not consider configured weights; it uses a hash-based distribution that may not be proportional to link capacity. While it utilizes multiple links, it does not provide weighted load balancing as required.
B
Priority
Why it fails: The 'Priority' strategy selects members based on their priority order, using the highest-priority member that meets the SLA. It does not load-balance across multiple links; it only fails over to the next priority when the current one fails. This would not distribute traffic proportionally, so it does not meet the requirement.
C
Lowest Cost (SLA)
Why it fails: The 'Lowest Cost (SLA)' strategy selects the member with the lowest cost that meets the SLA. It does not distribute traffic based on volume or weights; instead, it prefers a single member until it fails the SLA. This would not achieve proportional load balancing across both links. Therefore, it is not suitable for the described requirement.
D
Weighted Load Balance
The 'Weighted Load Balance' strategy distributes traffic across members based on their configured weight values. This allows the administrator to allocate a larger share of traffic to a higher-capacity link and a smaller share to a lower-capacity link, achieving proportional utilization. It is the only strategy that directly uses weights for load balancing, making it the correct choice for this scenario.

Read the full VPN explanation →

Question 2hardmultiple choice

An administrator is troubleshooting an IPsec VPN tunnel that is part of an SD-WAN zone. The tunnel is up, but SD-WAN health checks are failing, causing the tunnel to be marked as down. The administrator verifies that the Phase 2 selectors include the health check server's IP address. What is the next most likely cause to investigate?

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

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.

Trap 2: The SD-WAN health check is configured with the wrong protocol…

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.

Trap 3: The IPsec tunnel's Phase 1 proposal does not match the remote…

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.

A
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.
B
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.
C
The health check server is not reachable via the tunnel due to missing route.
Even if the Phase 2 selectors are correct, the FortiGate must have a route to the health check server pointing to the tunnel interface. If the route is missing or incorrect, the probe packets will not be sent through the tunnel, and health checks will fail. This is a common oversight in SD-WAN deployments, especially when using dynamic routing or multiple paths.
D
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.

Open the full BGP breakdown →

Question 3hardmultiple choice

An enterprise deploys BGP over SD-WAN with multiple MPLS and broadband connections. A route-map is applied to incoming BGP updates on the FortiGate to set a specific weight for routes learned over the MPLS interface. Why is the 'weight' attribute particularly effective in this FortiOS SD-WAN and BGP integration scenario?

Trap 1: Weight replaces the need for SD-WAN SLA rules by performing layer 7…

Weight affects BGP best-path selection only; it performs no layer 7 inspection and cannot replace SD-WAN SLA rules, which monitor link quality via probes. It is tempting because both influence which path traffic takes, but weight acts on routing tables, not application-aware steering or SLA enforcement.

Trap 2: Weight automatically adjusts the SD-WAN health check probe…

Weight is a local, non-transitive BGP attribute that influences best-path selection on the receiving FortiGate; it has no interaction with SD-WAN health check probing. It is tempting because both features concern link selection, but weight operates purely within BGP path decision, not SLA probe scheduling.

Trap 3: Weight is propagated to all iBGP peers, ensuring cluster-wide path…

Weight is significant only on the local router and is never advertised to iBGP or eBGP peers, so it cannot synchronise paths cluster-wide. It is tempting because other attributes such as local preference do propagate, but weight's defining characteristic is local scope, which is precisely why it suits inbound route-map marking here.

A
Weight replaces the need for SD-WAN SLA rules by performing layer 7 packet inspection
Why it fails: Weight affects BGP best-path selection only; it performs no layer 7 inspection and cannot replace SD-WAN SLA rules, which monitor link quality via probes. It is tempting because both influence which path traffic takes, but weight acts on routing tables, not application-aware steering or SLA enforcement.
B
Weight automatically adjusts the SD-WAN health check probe frequency based on route stability
Why it fails: Weight is a local, non-transitive BGP attribute that influences best-path selection on the receiving FortiGate; it has no interaction with SD-WAN health check probing. It is tempting because both features concern link selection, but weight operates purely within BGP path decision, not SLA probe scheduling.
C
Weight is evaluated first in the BGP best-path selection algorithm on FortiOS, allowing local preference override without altering global AS path attributes
Weight is FortiOS-proprietary and evaluated before local preference in the BGP best-path algorithm, so tagging MPLS-learned routes with a higher weight forces their selection locally. This satisfies the stem's constraint: influencing path choice on this FortiGate without altering AS-path or other attributes propagated to peers.
D
Weight is propagated to all iBGP peers, ensuring cluster-wide path synchronization
Why it fails: Weight is significant only on the local router and is never advertised to iBGP or eBGP peers, so it cannot synchronise paths cluster-wide. It is tempting because other attributes such as local preference do propagate, but weight's defining characteristic is local scope, which is precisely why it suits inbound route-map marking here.

Question 4hardmulti select

An administrator is using FortiManager 7.2 to manage SD-WAN templates across 150 FortiGates. They need to ensure that when a template is updated, the changes are propagated efficiently and that the FortiGates maintain high availability. The administrator wants to use the 'Install Wizard' to push the updated template. Which two statements are true about installing an SD-WAN template with the Install Wizard in this scenario? (Choose two.)

Trap 1: The Install Wizard can only install the entire policy package, not…

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.

Trap 2: The Install Wizard can push the updated SD-WAN template to all…

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.

Trap 3: The Install Wizard requires that all FortiGates be offline before…

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.

A
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.
B
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.
C
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.
D
The Install Wizard automatically creates a revision history entry for each FortiGate after a successful template installation, allowing rollback if needed.
FortiManager maintains a revision history for each managed device. When the Install Wizard successfully installs an SD-WAN template, it records the change as a new revision. This enables administrators to view previous configurations and roll back to an earlier revision if issues arise, which is essential for maintaining stability in large deployments.
E
The Install Wizard allows selecting specific FortiGates within an ADOM to receive the updated SD-WAN template, enabling phased rollouts.
The Install Wizard provides the option to select individual devices or device groups within an ADOM for installation. This allows administrators to perform phased rollouts, updating a subset of FortiGates first to validate changes before broad deployment. This is particularly useful in large environments to minimize risk and maintain high availability.

Read the full MPLS explanation →

Question 5hardmulti select

An administrator troubleshoots a scenario where traffic matching an application-based SD-WAN rule is bypassing the preferred high-speed MPLS tunnel and taking the backup broadband tunnel instead. Which THREE factors should the administrator check to resolve this routing discrepancy? (Choose three)

Trap 1: Verify the FortiGate factory default administrator password is…

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.

Trap 2: Check the physical layer OSI Model cable category connected to the…

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.

A
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.
B
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.
C
Inspect the member priorities and weights configured within the specific SD-WAN rule
Member priority and weight determine which tunnel the SD-WAN rule selects among qualified members; a misconfigured weight can rank broadband above MPLS. Checking these satisfies the discrepancy by confirming the rule's own selection logic, not just tunnel health.
D
Verify whether the preferred MPLS member is failing the configured performance SLA thresholds, causing the SD-WAN engine to disqualify it
When the preferred MPLS member breaches its performance SLA thresholds, the SD-WAN engine disqualifies it and traffic fails over to broadband. Verifying this satisfies the scenario by confirming whether measured latency, jitter or packet loss removed MPLS from the eligible member set.
E
Check the sequence order of the SD-WAN rules; an earlier rule might be matching the traffic first
SD-WAN rules are evaluated top-down, so an earlier rule matching the same traffic takes precedence and steers it down the backup broadband path. Verifying sequence order confirms whether a preceding rule is intercepting traffic before the intended MPLS rule applies.

Question 6hardmultiple choice

You are troubleshooting a scenario where an SD-WAN template is not pushing to a FortiGate. Which log file on the FortiManager is most useful to identify the specific CLI command causing the failure?

Trap 1: fmg_event.log

fmg_event.log records daemon and system events, not the per-command template installation output, so it cannot pinpoint the failing CLI line. It is tempting because event logs surface general FortiManager errors, and would be the right choice when diagnosing service restarts or unexpected daemon behaviour rather than template push failures.

Trap 2: fmg_audit.log

fmg_audit.log records configuration changes and administrative actions, showing that a template install was attempted but not the individual CLI command that failed. It is tempting because audit trails track who changed what, and would be the right choice when attributing configuration modifications to an administrator rather than debugging push failures.

Trap 3: fmg_system.log

fmg_system.log captures FortiManager system-level activity such as administrative and background operations, not the CLI-by-CLI result of a template install to a managed FortiGate. It is tempting because system logs reveal platform faults, and would be correct when investigating FortiManager host issues rather than SD-WAN template deployment errors.

A
fmg_event.log
Why it fails: fmg_event.log records daemon and system events, not the per-command template installation output, so it cannot pinpoint the failing CLI line. It is tempting because event logs surface general FortiManager errors, and would be the right choice when diagnosing service restarts or unexpected daemon behaviour rather than template push failures.
B
fmg_debug.log
fmg_debug.log captures FortiManager daemon debugging, including the specific CLI commands pushed to the FortiGate and the exact command that fails. It satisfies the stem's requirement to identify the failing CLI command during SD-WAN template troubleshooting.
C
fmg_audit.log
Why it fails: fmg_audit.log records configuration changes and administrative actions, showing that a template install was attempted but not the individual CLI command that failed. It is tempting because audit trails track who changed what, and would be the right choice when attributing configuration modifications to an administrator rather than debugging push failures.
D
fmg_system.log
Why it fails: fmg_system.log captures FortiManager system-level activity such as administrative and background operations, not the CLI-by-CLI result of a template install to a managed FortiGate. It is tempting because system logs reveal platform faults, and would be correct when investigating FortiManager host issues rather than SD-WAN template deployment errors.

Question 7hardmultiple choice

An engineer is configuring an SD-WAN rule that must load-balance traffic across two members based on the volume of traffic, but also must ensure that if one member's health check fails, traffic is redistributed to the remaining healthy member. Which strategy should be selected in the SD-WAN rule?

Trap 1: SLA

The SLA strategy is not a valid SD-WAN rule strategy in FortiOS. The available strategies include Manual, Best Quality, Lowest Cost (SLA), Maximize Bandwidth (SLA), and Priority. 'SLA' alone is a health-check mechanism, not a load-balancing strategy. This option is a distractor that confuses the SLA object with the rule strategy.

Trap 2: Best Quality

Best Quality selects the member with the best measured quality (lowest latency, jitter, or packet loss) according to the SLA. It does not load-balance across multiple members; it picks the single best path at any given time. While it is resilient to failures, it does not distribute traffic based on volume, so it fails the load-balancing requirement.

Trap 3: Priority

The Priority strategy selects the member with the lowest priority value that meets the SLA. It does not perform load balancing; it is a primary/backup approach. If the highest-priority member fails, traffic moves to the next, but traffic is not distributed across multiple members under normal conditions. This does not meet the requirement for load balancing based on volume.

A
SLA
Why it fails: The SLA strategy is not a valid SD-WAN rule strategy in FortiOS. The available strategies include Manual, Best Quality, Lowest Cost (SLA), Maximize Bandwidth (SLA), and Priority. 'SLA' alone is a health-check mechanism, not a load-balancing strategy. This option is a distractor that confuses the SLA object with the rule strategy.
B
Best Quality
Why it fails: Best Quality selects the member with the best measured quality (lowest latency, jitter, or packet loss) according to the SLA. It does not load-balance across multiple members; it picks the single best path at any given time. While it is resilient to failures, it does not distribute traffic based on volume, so it fails the load-balancing requirement.
C
Maximize Bandwidth (SLA)
The Maximize Bandwidth (SLA) strategy distributes traffic across all members that meet the SLA, proportionally to their available bandwidth. It provides load balancing based on volume and automatically removes failed members from the pool. This matches the requirement to load-balance while maintaining resilience to health-check failures.
D
Priority
Why it fails: The Priority strategy selects the member with the lowest priority value that meets the SLA. It does not perform load balancing; it is a primary/backup approach. If the highest-priority member fails, traffic moves to the next, but traffic is not distributed across multiple members under normal conditions. This does not meet the requirement for load balancing based on volume.