What the real exam feels like

I treated this exam as a troubleshooting and design-reading test, not a memorization test. The questions I saw were mostly scenario based, with screenshots, snippets of CLI/config, routing tables, SD-WAN rule outputs, health-check details, and hub-and-spoke topologies. If your prep was just reading feature descriptions, that will not be enough. Fortinet likes to ask what the device will do next, which member gets selected, why a route is preferred, or why a spoke does not build a shortcut.

Time pressure is real because the stems are dense. Even when the number of questions varies by delivery, the practical rhythm is still roughly a little over a minute per item. That matters because many questions include enough detail to distract you from the one decisive clue. On this exam, the decisive clue is usually one of these:

the SD-WAN rule mode: manual, SLA, priority, or load-balancing behavior
whether a route is in the routing table versus just learned in BGP
whether the question is about service strategy selection or routing selection
whether ADVPN is operating with shortcut capability and the right routing design
whether health-check state actually causes a member to be removed from selection

The exam interface itself is straightforward, but the bigger issue is that Fortinet questions often present two answers that are both technically true in isolation. The correct one is the one that matches FortiOS 6.4 behavior in the exact scenario. I passed by reading every exhibit like a change ticket. I would identify: interface role, zone membership, SD-WAN rule order, health-check target, routing protocol, and whether the question is asking about control plane or forwarding plane. If you do not force yourself into that sequence, the distractors work.

Where to spend most of your study time

If your time is limited, do not split it evenly across the blueprint. The exam leans heavily toward the pieces that make SD-WAN actually work in production: member selection, performance SLAs, rule matching, overlays, routing interaction, and centralized management. I would weight my own study like this:

SD-WAN rules and member selection logic: highest priority
Performance SLA / health-check behavior: highest priority
ADVPN overlays and shortcut behavior: very high priority
BGP with SD-WAN, route tagging, communities, and path control: very high priority
FortiManager workflow for SD-WAN templates and provisioning: medium to high priority
Basic IPsec, basic firewall policy, basic GUI navigation: low priority unless you are shaky on fundamentals

A lot of people over-study generic FortiGate administration and under-study how SD-WAN decisions are made. That is backwards for this exam. You need to be fluent in questions like these:

A packet matches multiple SD-WAN rules. Which one is evaluated?
A member is alive from an interface perspective but fails SLA thresholds. Is it still selected?
BGP has multiple paths. Which one ends up active when SD-WAN and routing both influence forwarding?
A spoke learns routes through a hub. Under what conditions does ADVPN build a shortcut and actually use it?
A rule uses application steering or internet-service matching. What wins if several criteria overlap?

The topics that look easy but hide gotchas are default route behavior, zone versus interface references, implicit rule outcomes, and the difference between steering traffic into a tunnel and actually having a usable route through that tunnel. Fortinet loves that distinction.

The SD-WAN rule traps Fortinet keeps using

The single most testable area is how FortiGate chooses an SD-WAN member. You need to know not just the names of the strategies, but the exact consequences. Many wrong answers are built around mixing up the rule match stage with the member selection stage.

Here is the mindset that helped me:

First decide which SD-WAN service rule the traffic matches.
Then decide which members are eligible inside that rule.
Then apply health-check/SLA status and the selected strategy.
Only after that think about routing and whether the next hop is actually reachable.

The exam often gives a policy route feel to the question, but it is really testing SD-WAN service logic. Watch for these common traps:

Rule order matters. If a broad rule is above a specific one, the broad rule wins first. Fortinet will hide this in a long exhibit.
Manual mode is not the same as best quality. If a preferred member is still considered usable under the rule conditions, it may be chosen even if another path is objectively better.
Priority members can confuse people because the wording sounds like load balancing. It is not. Understand when FortiGate moves down the preference list.
SLA mode depends on the health-check tied to the rule. If a member has no matching health-check context for the rule, the answer may not be what you expect.
Load balancing questions often include session behavior details. If the question hints at existing sessions, do not assume per-packet behavior.

I saw several items where the only way to get the right answer was to understand that a member can be physically up, part of the SD-WAN zone, and still not be selected because the SLA target failed latency/jitter/loss thresholds. If you have only practiced interface-up/interface-down failover, you will miss those.

Another frequent pattern is the hidden mismatch between source/destination criteria and application/internet service criteria. Fortinet likes to show a rule that looks like the obvious match because of subnet definitions, but the actual packet gets caught by another service rule because of application steering or a more specific destination object. Practice reading service rules in full, not just the first two columns.

Health checks, SLA math, and why 'alive' is not enough

This exam goes deeper on performance SLA than many candidates expect. You need to understand not just what health checks are, but how they influence path selection and failover. Questions commonly describe brownout conditions rather than hard-down failures.

The key thing to remember is that Fortinet tests decision quality under degraded links. That means you should be comfortable with:

what metrics are being measured: latency, jitter, packet loss
how a member becomes dead, alive, or out-of-SLA for a given target
how multiple health-check targets can affect interpretation
the operational difference between a path being available and a path being acceptable for a specific service

The gotcha is that candidates often assume a failed SLA means the route disappears. That is not always the point being tested. Often the route is still there, but the SD-WAN rule will stop preferring that member for traffic governed by the SLA. Those are different layers of behavior.

If you see a question with multiple probes and one target failing while another is healthy, slow down and identify whether the rule references that health-check and how the fail criteria are defined. Fortinet likes to exploit the fact that people remember the concept but not the actual dependency chain.

I also recommend drilling CLI outputs related to health checks and SD-WAN status. On the real exam, exhibits may show command output that makes the answer obvious if you already know what a healthy versus degraded member looks like. If you have only studied GUI screenshots, you are giving up easy points.

ADVPN and BGP: the part most people answer by instinct and get wrong

If there is one area where smart network engineers still get trapped, it is the interaction of ADVPN, BGP, route reflection-style designs, shortcut tunnels, and recursive next-hop resolution. Fortinet questions here are rarely basic. They usually describe a hub-and-spoke topology and ask why traffic still hairpins through the hub, why a shortcut is not formed, or why a route is learned but not used as expected.

You should be able to explain these without guessing:

what conditions allow ADVPN shortcuts to form between spokes
how BGP next-hop handling affects whether a shortcut can actually carry traffic
why a route can be present in BGP but not preferred in the RIB/FIB
how SD-WAN zones interact with overlay members and routing decisions
what happens when multiple hubs or multiple overlays exist

A classic trap is this: the topology is valid, the IPsec tunnels are up, BGP neighbors are established, but traffic still goes through the hub. The exam wants you to notice one of the following:

the routing design does not support shortcut use
next-hop resolution points to the hub path instead of the spoke shortcut
the SD-WAN rule prefers another member based on SLA or priority
the required ADVPN capability is not enabled consistently
route advertisement or community/tagging behavior is steering traffic differently than the candidate assumes

Do not treat BGP questions here as generic BGP questions. Fortinet asks BGP in the context of SD-WAN policy and overlays. That means local preference, MED, communities, and route maps matter, but only as they affect the overlay forwarding decision in the design shown. I spent extra time correlating BGP path selection with SD-WAN member usage, and that paid off.

One more thing: if the answer choices include one explanation about firewall policy and another about routing/overlay behavior, the routing/overlay explanation is often the right one unless the exhibit explicitly shows a policy omission. This exam is much more interested in why the control plane or SD-WAN logic produced a path than in basic policy mistakes.

FortiManager is not optional background knowledge here

A lot of candidates think this is mainly a FortiGate routing exam. It is not. FortiManager shows up enough that you should know how SD-WAN is deployed and managed centrally in 6.4. You do not need to become a FortiManager specialist, but you do need to understand the workflow and object relationships.

What I would specifically review:

SD-WAN templates and how they are applied across devices
the difference between device-specific values and reusable policy/template components
provisioning of overlay VPNs and how that integrates with SD-WAN deployment
policy package versus device manager context for making changes
common reasons a pushed config does not produce the expected SD-WAN behavior on the FortiGate

Fortinet likes asking questions where the wrong answer sounds operationally plausible but ignores how FortiManager actually pushes settings. If a question mentions a change not appearing on the managed device, think in terms of install workflow, variable mapping, and whether the setting belongs to the right management layer.

I also saw that people underestimate version-specific behavior. Since this exam is explicitly 6.4, do not rely on habits from 7.x documentation or videos. Some menu locations, capabilities, and workflows are similar, but the exam expects 6.4 logic and terminology.

Question styles that deserve their own prep

The Fortinet style I ran into most often was the multi-exhibit scenario. You get a topology, then snippets from routing, SD-WAN rules, and health-check status, and the answer depends on combining them. The mistake is trying to solve it from memory alone. Instead, translate the exhibits into a quick mental checklist:

What is the destination traffic in the question?
Which SD-WAN rule matches first?
Which members are candidates under that rule?
What does the health-check say about those members?
What route exists for that traffic, and through which overlay/member?
Is the question asking expected path, root cause, or best fix?

There are also “choose two” style questions where one option describes the symptom and another describes the mechanism. Only pick the mechanism if the wording asks for cause. Fortinet is picky there.

For screenshot questions, train on recognizing these quickly:

SD-WAN monitor views
performance SLA status indicators
routing table and BGP neighbor/route outputs
IPsec and ADVPN-related status screens
FortiManager template or provisioning views

The exam does not usually require obscure CLI syntax recall, but it absolutely rewards recognizing what a given output implies. If you can look at a route entry or health-check status line and immediately infer path eligibility, you save a lot of time.

What I would fix in the last 7 days

My final week would be almost entirely scenario drilling. Not more reading. I would focus on the handful of areas that repeatedly produce near-miss answers.

Use this checklist:

Build or review at least a few hub-and-spoke ADVPN scenarios with BGP and be able to explain shortcut formation step by step.
Rehearse SD-WAN rule evaluation order with overlapping rules: by source, destination, application, internet service, and default behavior.
Practice reading performance SLA results and deciding whether a member is selectable, not just reachable.
Review FortiManager SD-WAN deployment flow: templates, variables, install, and overlay provisioning.
Compare routing choice versus SD-WAN steering choice until the distinction feels automatic.
Refresh 6.4-specific terminology and screens so you do not answer from newer-version memory.

I would also use the 81 practice questions on Truekia selectively, not passively. Group misses into these buckets:

I chose the wrong SD-WAN rule
I ignored SLA state
I confused BGP route learning with active forwarding path
I misunderstood ADVPN shortcut requirements
I mixed up FortiManager management workflow

If most of your misses fall into one or two buckets, stay there until you can explain each answer out loud. On this exam, explanation quality predicts score better than raw question volume.

The final blunt warning: do not walk in thinking SD-WAN is just 'send traffic down the best tunnel.' Fortinet tests the exact logic chain that decides what 'best' means in 6.4, and the wrong answers are designed for people who understand networking broadly but do not understand FortiGate SD-WAN precisely.