NSE7 Part 13: A Full Design Walkthrough, and Exam Day

Twelve parts, five domains, one exam. This closing part does two things: builds a single topology dense enough to touch every domain at once, the way an actual NSE 7 scenario question tends to, and covers the practical logistics of sitting the exam itself.

The Design Brief

An MSSP runs managed SD-WAN for two customers, each with sites across two regions. The brief, stated the way a scenario question would state it: each customer’s traffic must stay fully isolated from the other’s, including routing information. Each region has a resilient dual-hub pair. Spoke-to-spoke traffic within a region should use direct paths where it’s frequent enough to justify one, without a human provisioning that path by hand. Branch rollout needs to work without a network engineer visiting each site. Full content inspection is required for a defined set of high-risk applications, and everything else should not pay full inspection’s performance cost. And the whole thing needs to survive a single hub going down in either region without customer-visible disruption.

Nothing about this brief is exotic. It’s an ordinary composite of decisions this series has already covered individually. What makes it a Part 13 exercise is holding all of them in one design at once.

Layer by Layer

Tenant isolation (Part 4). Two customers, full routing and administrative separation required: VDOMs, not VRF-aware overlays alone, since the brief specifies isolation stronger than routing-table separation. A management VDOM keeps the MSSP’s own admin plane separate from both customer VDOMs.

HA at each hub (Part 3). Each regional hub is a two-unit FGCP cluster. Given the brief’s UTM-heavy inspection requirement below, active-active load balancing is worth considering here specifically because content-inspection-heavy traffic is exactly the profile active-active benefits, not a default reached for without reason.

Dual-hub, per-region (Parts 6, 11). Each region’s two hubs are provisioned via FortiManager’s SD-WAN overlay template with dual-hub options, generating both hub relationships for every spoke in that region from one template rather than by hand.

ZTP branch rollout (Part 6). Every spoke ships pre-staged against a device blueprint, CSV-imported in bulk ahead of shipping, discovering its assigned FortiManager and pulling full configuration with no console access required on site.

Routing (Parts 8, 9, 12). BGP throughout, not OSPF, given ADVPN is in scope below and OSPF’s neighbor model doesn’t handle dynamically-forming shortcut tunnels gracefully. Within each region: iBGP hub-to-spoke, hub acting as route reflector, both hubs’ loopbacks as BGP sources so a shortcut renegotiating doesn’t force a BGP session restart. Between the two hubs in a region: eBGP. Between regions: the two regional hub-pairs peer to each other, propagating reachability across regions without every spoke needing a cross-region relationship of its own.

ADVPN within each region (Part 12). Auto-discovery enabled hub-side and spoke-side, dynamic BGP via neighbor-range so newly-ZTP’d spokes don’t need individual hub-side BGP configuration, shortcut timeout and failback delay tuned to avoid flapping on marginal paths. Spoke-to-spoke traffic within a region gets direct shortcuts once it’s frequent enough to trigger negotiation; the two regional hub pairs remain the path for cross-region and hub-relayed traffic.

Security profiles (Part 7). Full inspection scoped specifically to the brief’s defined high-risk application set via policy targeting, not applied blanket. Everything else runs certificate inspection, keeping category/reputation filtering in place without paying full inspection’s decrypt/re-encrypt cost on traffic the brief never asked to have its content inspected.

Self-healing (Part 11). BFD bound to every BGP session, both hub relationships and any established shortcuts, for fast failure detection; SD-WAN rules using Lowest Cost (SLA) strategy across both hub-facing zones so a hub failure drops that hub’s member out of SLA-passing consideration and traffic shifts to the surviving hub automatically, satisfying the brief’s single-hub-failure requirement without any manual intervention.

Security Fabric automation (Part 2), layered on top rather than load-bearing to the topology itself: an Automation Stitch on high CPU across every hub, an IoC-triggered quarantine stitch, and scheduled configuration backups, all inherited from Part 2’s patterns applied at MSSP scale, one FortiManager-templated stitch rather than one per hub.

Confirming Each Layer Actually Works

A design on paper and a design confirmed live are different things, and the exam’s scenario questions are built around exactly that gap. The diagnostic sequence, roughly in the order an actual investigation would run it:

get system status
diagnose sys ha status
diagnose vpn ipsec status
get router info bgp summary
diagnose sys sdwan health-check status <sla-name>
diagnose sys sdwan service
diagnose sys session list filter ...
diagnose vpn ipsec tunnel list

get system status and diagnose sys ha status confirm the hub cluster itself is healthy before looking at anything downstream of it, since a design question that looks like a BGP problem is sometimes actually an HA problem wearing a BGP-shaped symptom. diagnose vpn ipsec status and diagnose vpn ipsec tunnel list confirm the underlying tunnels, both statically-provisioned hub tunnels and any active ADVPN shortcuts, are actually up before reasoning about routing across them. get router info bgp summary confirms sessions are Established and shows the address-family-level route counts, the direct check for “is this spoke actually learning what I expect it to learn.” The SD-WAN commands from Parts 5 and 10 confirm the rule and member selection layer on top of a routing table that’s already been independently confirmed correct, rather than trying to diagnose routing and SD-WAN steering as one undifferentiated problem.

The discipline worth taking into the exam itself: a scenario question describing a symptom (“branch traffic to the DC is slow”) is almost never actually asking about the layer where the symptom is observed. Slow branch-to-DC traffic could be a degraded WAN member SD-WAN hasn’t failed away from yet, a BGP path that’s technically up but suboptimal, a shortcut that formed but shouldn’t have, or full inspection running against traffic it wasn’t meant to. The design in this post exists specifically to give you five plausible answers to hold in mind at once and the diagnostic sequence to actually distinguish between them, rather than guessing from the symptom description alone.

Exam Day

The exam itself: 40 to 50 questions, 60 to 70 minutes, multiple choice and drag-and-drop, pass or fail with no partial credit, sat at a Pearson VUE test center or via OnVUE remote proctoring. There’s no official minimum passing score published the way some other Fortinet exams state one explicitly; treat every question as needing to be right, since there’s no partial credit to fall back on regardless.

A few practical notes worth carrying in specifically because of how this exam is weighted, not generic test-taking advice:

Expect the question to be longer than the answer choices suggest it needs to be. Given that routing and advanced IPsec together account for 50-70% of the exam by the blueprint’s own ranges, a meaningful share of questions will describe a topology in a full paragraph rather than a single sentence, the way the design brief at the top of this post does. Read the whole scenario before evaluating any answer choice; a detail in the third sentence (dual-hub, not single-hub; ADVPN in scope; a specific redistribution requirement) can eliminate two of the four choices before you’ve even reached the actual question being asked.

Security profiles being lightly weighted doesn’t mean skippable. At 5-15%, it’s the smallest domain, but a handful of questions at that weight is still several real marks, and the SSL inspection strategy content in Part 7 is exactly the kind of “sounds like NSE4 material” content that’s easy to under-prepare for because it feels familiar, right up until the question is about a design tradeoff NSE4 never actually covered.

If a question offers a technically-correct-but-overcomplicated answer alongside a simpler one that also satisfies the stated requirement, the exam has consistently rewarded matching the design to what was actually asked for. Part 10’s closing point about not defaulting to “just run BGP everywhere” applies at exam-question scale too: a described requirement that doesn’t need ADVPN, dual-hub, or full inspection shouldn’t have those things reached for reflexively just because this series covered them in depth.

That’s the series. Thirteen parts against a five-domain blueprint that turned out to be, once actually read closely, an SD-WAN and VPN architecture exam more than a general “secure networking” one, which is worth knowing going in rather than discovering on exam day. If you’ve worked through NSE4, NSE5 or NSE6, and this series in sequence, the prerequisites and the content are both already behind you.