The current Fortinet NSE 7 – Secure Networking 7.6 Architect exam is explicitly applied. Fortinet recommends hands-on labs and describes the exam as including operational scenarios, incident analysis, integration, and troubleshooting. That makes practical preparation more valuable than a long list of screenshots. The best lab environment is a small repeatable enterprise topology that can grow from a few FortiGate devices into SD-WAN, FortiManager orchestration, FortiAnalyzer evidence, advanced IPsec, and failure testing.<\/p>\n
Keep the current Fortinet certifications<\/a> context in mind, but make every exercise traceable to an official objective. A lab should answer a design question or expose a failure mode. If an exercise consists only of clicking through a wizard without predicting the expected route, session, tunnel, or log result, it is not yet training the reasoning this exam measures.<\/p>\n Start with a FortiGate that has multiple VLANs, at least two routing segments, and a simple policy model. Create addressing that forces you to reason about prefixes instead of relying on one flat subnet. If needed, use IPv4 subnetting<\/a> and CIDR<\/a> as a refresher, then document the expected connected and static routes before checking the device.<\/p>\n Add a VDOM use case only if you can explain why stronger separation is required. Test inter-VDOM traffic deliberately. The lab should end with a written path for each test flow: source interface, routing decision, destination, and policy boundary. That path becomes the baseline for every later exercise, so mistakes here should be resolved before adding dynamic routing or encrypted overlays.<\/p>\n Build an FGCP pair and observe failover during link loss, path loss, or node failure. Compare what happens to sessions when state is synchronized and when a dependency outside the cluster fails. If your environment supports it, explore active-active behavior or virtual clustering and record the operational differences. The purpose is not to create every possible HA topology but to understand the state Fortinet is protecting.<\/p>\n Then model FGSP separately so that session synchronization is not confused with cluster failover. Introduce asymmetric traffic and verify which flows survive. A good lab notebook records the trigger, detection mechanism, new active path, route consequence, session outcome, and log evidence. Those fields become a repeatable troubleshooting checklist.<\/p>\n Use a small topology with enough routers or virtual FortiGates to make route propagation visible. Configure OSPF and practice route filtering, redistribution, and ECMP. Then use BGP to explore prefix lists, route maps, loopback sources, neighbor groups, and faster failure detection. Before every change, write down the route you expect to appear or disappear.<\/p>\n Do not stop when the routing table looks correct. Send traffic and inspect session behavior. Change a prefix filter or redistribution rule and watch how downstream reachability changes. The exam’s routing domain is about applied control-plane behavior, so the strongest lab result is a clear explanation of cause and effect.<\/p>\n Configure two WAN members with distinct characteristics and build health checks, service rules, and direct-internet-access behavior. The SD-WAN Engineer<\/a> material can reinforce terminology, but the lab should focus on the current architect objectives. Introduce latency, loss, or a failed next hop and verify whether the preferred member changes as expected.<\/p>\n Use widgets, event logs, and session information to prove the decision. Then change routing without changing the SD-WAN rule and observe whether the result differs. Reverse the experiment by changing the SD-WAN strategy while keeping routes stable. Separating those variables makes it much easier to diagnose a real deployment where routing, health, and service rules can all influence the same session.<\/p>\n Create IKEv2 site-to-site tunnels and validate negotiation, routes, and protected traffic. Once the baseline works, experiment with DPD behavior, tunnel addressing, NAT conditions, and redundant paths. Then lower MTU or create a path where fragmentation becomes visible. Compare the effect of adjusting MSS with simply allowing fragmentation.<\/p>\n This lab turns several abstract objectives into observable symptoms. A tunnel can be up while an application stalls because large packets fail. Another tunnel can fail after NAT changes even though the policy remains correct. Record the commands, logs, and packet evidence that separate negotiation, routing, and transport-size problems. That diagnostic separation is more useful than memorizing one \u201cVPN troubleshooting\u201d recipe.<\/p>\n Use the working IPsec foundation to build a hub-and-spoke overlay, then enable ADVPN behavior so spokes can form more direct paths where appropriate. Observe shortcut negotiation and fallback. Add a second hub and verify how routing and SD-WAN react when the preferred hub becomes unavailable. If the lab platform permits it, explore multiregion or VRF-aware ideas at reduced scale.<\/p>\n Keep a control-plane diagram beside the data-plane diagram. When a shortcut appears, note which routing information made it usable. When it disappears, record what changes first and where traffic goes next. This lab should make the relationship among BGP, IPsec, ADVPN, and SD-WAN concrete enough that you can reason through a scenario without the GUI in front of you.<\/p>\n Bring the lab under FortiManager management. Create reusable templates, metadata variables, and a small branch deployment model. Use zero-touch provisioning or a simulated onboarding process where possible, and verify how site-specific values are applied. The important skill is understanding which configuration is generated centrally and how that intent reaches the managed device.<\/p>\n Deliberately create a variable mismatch, a wrong template assignment, or an overlay error. Diagnose it from the management layer before touching the branch. Then correct the source and redeploy. This exercise develops the discipline to avoid local fixes that are later overwritten and prepares candidates for the central-management objectives around SD-WAN Manager, VPN Manager, and overlay templates.<\/p>\n Add web filtering, application control, IPS, and SSL inspection to a controlled traffic path. Review SSL\/TLS fundamentals<\/a> first if necessary, then compare certificate inspection with full inspection. Use a test client that does not trust the inspection authority and observe the failure. Correct trust deliberately instead of bypassing inspection wholesale.<\/p>\n Next, create a false-positive or performance investigation by changing one profile at a time. Record CPU or session effects if your lab exposes them. The objective is to learn a precise troubleshooting sequence: establish the path, identify the policy, identify the active profile, inspect the event, reproduce the issue, then change the minimum necessary control.<\/p>\nLab one: build a segmented branch and prove every route<\/h3>\n
Lab two: make high availability fail in controlled ways<\/h3>\n
Lab three: create OSPF and BGP changes that you can predict<\/h3>\n
Lab four: turn two WAN links into a measurable SD-WAN decision<\/h3>\n
Lab five: build IKEv2 tunnels, then create packet-size problems<\/h3>\n
Lab six: move from a static hub to ADVPN and dual-hub recovery<\/h3>\n
Lab seven: centralize branch creation in FortiManager<\/h3>\n
Lab eight: apply inspection and reproduce a certificate failure<\/h3>\n
Lab nine: turn FortiAnalyzer and automation into an incident timeline<\/h3>\n