FCSS SD-WAN 7.4 Architect common mistakes
FCSS SD-WAN 7.4 Architect · Understand the traps and how to avoid them.
Treating FortiGate SD-WAN as a feature that lives only inside the SD-WAN section, so candidates configure SD-WAN members and health checks but never adjust the underlying interface routes, policy routes, or static routes that actually steer traffic.
The exam's routing and WAN-optimization domain deliberately blends SD-WAN rules with legacy routing constructs. Candidates who learned SD-WAN from GUI walkthroughs memorize the SD-WAN menu and miss that SD-WAN is evaluated after normal routing and policy routing, so a leftover default route or policy route overrides the intended SD-WAN member selection.
What to do instead
Before answering any steering question, draw the full packet path: incoming interface, policy route lookup, routing table lookup, SD-WAN rule evaluation, then egress. Practise predicting which member a flow uses when both a static default route and an SD-WAN rule exist, and verify against FortiGate route and SD-WAN debug output in a lab.
Confusing SD-WAN health-check behavior with link-state detection, assuming a member is removed from selection as soon as a probe fails, rather than accounting for failure thresholds, recovery thresholds, and the check interval.
Candidates read 'health check detects link quality' and stop there. Exam questions probe the difference between a single missed probe and a member marked dead, and between SLA targets evaluated per-rule versus health-check status. Without knowing the threshold mechanics, candidates pick answers that remove a link too early or keep a dead link in rotation.
What to do instead
Learn the exact relationship: probe interval, failure threshold, recovery threshold, and how SLA targets (latency, jitter, packet loss) are evaluated per SD-WAN rule. Lab a scenario where one member degrades slowly and observe when traffic actually moves, then explain the timing in your own words.
Building SD-WAN rules that match on the wrong criterion order, for example expecting application control to match before the rule's source/destination and service criteria, or expecting implicit load balancing when no strategy is set.
SD-WAN rules are evaluated top-down with specific match fields, and the default strategy when unspecified is not what candidates assume. Candidates who never built rules with overlapping criteria misjudge which rule fires, and they miss that application-based matching depends on application control being enabled and inspected.
What to do instead
Memorize the rule evaluation order and the available strategies (manual, best quality, lowest cost, maximize bandwidth, and so on). Build three overlapping rules in a lab and confirm which one wins with debug flow output. Always ask whether application identification is actually available on the path before choosing an app-based rule.
Configuring ADVPN or IPsec overlays without matching the phase 1/phase 2 selectors, routing, and hub-and-spoke role assumptions, then selecting answers that ignore how shortcut tunnels are triggered.
Overlay design questions mix IKE, static versus dynamic routing, and SD-WAN member configuration. Candidates often forget that the spoke-to-spoke shortcut depends on the hub advertising routes and on the SD-WAN rule or routing pushing traffic into the overlay, so they choose answers that describe the shortcut as automatic regardless of routing.
What to do instead
Draw the control plane and data plane separately: IKE to the hub, routing exchange, then shortcut negotiation. Practise a two-spoke lab where you verify the shortcut forms only after the correct route and SD-WAN rule exist, and be able to explain what breaks if the hub stops advertising the spoke subnet.
Treating SD-WAN security and traffic steering as a single firewall policy problem, so candidates write one broad policy and assume SD-WAN steering, security profiles, and internet breakout all apply uniformly to every member.
The security and traffic steering domain tests how policy, SD-WAN rules, and security profiles interact. Candidates who only studied policy creation miss that steering decisions can be made by SD-WAN rules while security inspection depends on the policy that matches the flow, and that per-member behavior (for example local breakout versus backhaul) changes what gets inspected.
What to do instead
Map each traffic class to three things: which policy matches, which SD-WAN rule steers, and which security profile inspects. Lab a scenario with local internet breakout on one member and backhaul on another, then trace where inspection happens in each case.
Assuming all traffic is inspected by default when steering to multiple WAN links, ignoring that some designs require explicit configuration for traffic leaving via a different interface, and ignoring asymmetric routing effects on stateful inspection.
Candidates generalize from single-WAN experience where one policy handles everything. With multiple members and return paths that differ, sessions can arrive on one interface and leave on another, and candidates answer as if the firewall state table and inspection behave identically in all cases.
What to do instead
Study how session setup, return traffic, and inspection behave when forward and return paths differ. In a lab, force asymmetric return traffic and observe session state and any drops. Know which design choices (per-member policies, SD-WAN zone policies, or routing symmetry) prevent the problem.
Skipping the centralized management model distinctions, answering as if all FortiGate configuration is pushed identically whether managed by FortiManager, by a fabric/overlay controller, or locally, and ignoring the role of templates and metadata variables.
The centralized management domain tests provisioning at scale. Candidates who only used standalone devices assume every setting can be edited locally after central provisioning, or they forget that template-driven configuration can overwrite local changes on the next install.
What to do instead
Learn the provisioning chain: model device, metadata variables, policy package and templates, then install. Practise changing a variable-driven setting and reinstalling to see what survives. Be able to say which objects are centrally owned versus device-local.
Diagnosing SD-WAN problems with only GUI status pages, picking answers that rely on the SD-WAN monitor alone rather than on health-check debug, route lookup, session listing, and packet capture.
Troubleshooting questions describe a symptom and expect the candidate to choose the next diagnostic step. Candidates who never used CLI diagnostics default to the dashboard view, which shows member status but not why a specific flow chose a member or why a probe failed at the IKE or ICMP level.
What to do instead
Build a diagnostic checklist per symptom: health-check debug for probe failures, route and policy-route lookup for wrong egress, session list for state issues, and sniffer for actual packet path. Rehearse the order and know what each command proves and does not prove.
Misreading performance SLA targets as absolute guarantees, so candidates select answers that say traffic fails or the link is disabled when an SLA is missed, instead of describing rule-level member preference changes.
SLA targets are evaluated per SD-WAN rule and influence member selection for that rule; they do not take the interface down. Candidates conflate SLA violation with interface failure and choose answers describing link shutdown or policy disablement.
What to do instead
State the distinction explicitly in your notes: interface down is a link event, SLA violation is a rule-level quality signal. Lab a rule with a strict SLA and watch member preference shift while the interface stays up. Verify with the SD-WAN monitor and health-check debug.
Approaching deployment design questions by listing features instead of producing a sequenced design: no decision on underlay versus overlay, no hub sizing, no failover order, and no plan for how branches join.
The deployment domain rewards structured design reasoning. Candidates who memorized feature names answer with a feature list, missing that the question asks for topology, redundancy, and onboarding sequence. This produces plausible but incomplete answers.
What to do instead
Practise writing a one-page deployment plan for a branch scenario: underlay links, overlay topology, hub redundancy, SD-WAN rule strategy per traffic class, security inspection point, and onboarding method. Compare against the exam's stated constraints and remove anything the constraints do not require.