Fortinet FCX common mistakes
Fortinet FCX · Understand the traps and how to avoid them.
Treating the FortiGate as a flat set of independent features and answering architecture questions feature-by-feature, instead of describing how FortiOS policy, routing, and the Security Fabric telemetry layer interact in one flow.
Most candidates study from feature-level configuration guides and lab exercises, so they memorize where a setting lives but never build a mental model of the packet path and how Fabric telemetry (FortiTelemetry, Fabric Connectors, root/leaf roles) ties devices together. Exam items that ask about design consequences of a choice expose the missing model.
What to do instead
Before the exam, draw the full path for one traffic flow: ingress interface, policy lookup, UTM profile order, routing decision, egress, and what telemetry is generated and consumed by the Fabric root. Re-draw it for an inter-VDOM and a Fabric-leaf scenario. Practice explaining in one sentence why a given Fabric connector must terminate on the root versus a downstream device.
Assuming the FortiGate forwards traffic between any two interfaces by default, then mis-predicting the result of a policy or routing question.
Candidates coming from router or switch backgrounds assume connected routes imply forwarding. FortiOS denies inter-interface traffic unless an explicit firewall policy permits it, and implicit deny plus policy ordering drive many exam scenarios.
What to do instead
Rehearse the FortiOS evaluation order explicitly: policy route, then firewall policy top-down match, then implicit deny, with NAT and UTM applied per matched policy. Work through three short scenarios where a permissive-looking design still drops traffic because no policy matches or because a policy above it shadows it.
Designing SD-WAN answers around link selection only, ignoring the health-check, SLA-probe, and rule-ordering mechanics that actually decide path selection.
SD-WAN marketing material emphasizes 'steer traffic over the best link', so candidates learn the concept but not that performance SLA objects, health-check intervals, and SD-WAN rule priority determine behavior, and that a rule with no matching SLA target falls through.
What to do instead
Build a small table of SD-WAN rule inputs (source, destination, service, health-check/SLA target, priority, strategy) and trace which rule matches for two sample flows. Confirm you can state what happens when all SLA targets fail versus when no rule matches.
Answering switching and wireless questions by analogy to other vendors' spanning-tree, VLAN, or roaming behavior rather than FortiSwitch/FortiAP specifics such as FortiLink management and MCLAG.
Candidates often have Cisco or Aruba experience and assume convergence, VLAN assignment, or roaming logic works the same. FortiLink changes how the FortiGate manages the switch, and MCLAG and integrated wireless controller behavior have their own rules.
What to do instead
Review FortiLink topology options (single FortiGate, MCLAG pair), how VLANs are pushed from the FortiGate to managed switches, and how the integrated wireless controller handles AP authorization and roaming. Write a one-page comparison of what is managed centrally versus locally for each.
Conflating ZTNA, SSL VPN, and IPsec dial-up as interchangeable 'remote access' answers, and choosing the wrong one for a given requirement.
All three appear under secure access, and candidates who learned remote access before ZTNA existed default to VPN answers. Exam scenarios that mention per-application access, posture, or proxy-based control are testing ZTNA specifically.
What to do instead
Create a decision table: SSL VPN (full or tunnel mode, network-level access), IPsec dial-up (site or client with native client), ZTNA with FortiClient EMS and access proxy (application-level, posture-driven, no full network exposure). For each, note what the user can reach and where policy is enforced.
Treating SASE as 'VPN plus cloud firewall' and missing the SSE components (SWG, CASB, ZTNA, DLP) and how they combine with SD-WAN for a unified architecture.
SASE terminology is vendor-heavy and candidates latch onto the two components they know. Questions about which control applies to SaaS traffic versus branch internet breakout then go wrong.
What to do instead
Map each SSE function to the traffic type it governs: secure web gateway for web egress, CASB for sanctioned and unsanctioned SaaS, ZTNA for private apps, DLP for data in motion. Then map where enforcement sits for branch breakout versus remote user versus data center.
Answering cloud security questions as if the same appliance model applies everywhere, ignoring the difference between FortiGate VM in a cloud VPC, cloud-native security constructs, and centralized management via FortiManager.
Candidates with on-premises experience assume routing, HA, and inspection behave identically in public clouds. Cloud networking (route tables, security groups, load balancers, availability-zone HA design) changes the correct answer.
What to do instead
For one major cloud, sketch a reference deployment: VPC/VNet segmentation, FortiGate VM insertion point, HA across zones, and how FortiManager manages policy. Note which functions the cloud provider performs versus the FortiGate.
Memorizing SOC product names and abbreviations without being able to place each one in the detect-investigate-respond pipeline or say what data it consumes.
The SOC domain spans SIEM, SOAR, EDR, and NDR, and candidates learn the acronyms from datasheets. Exam items ask which tool produces which signal or which component automates which step, which requires functional understanding.
What to do instead
Build a pipeline diagram with columns for data source, detection, enrichment, and response action. Place FortiAnalyzer, FortiSIEM, FortiSOAR, FortiEDR, and FortiNDR in it, and write one sentence per product on the signal it uniquely provides.
Applying IT security assumptions to OT environments, such as recommending inline active scanning or frequent signature updates without regard for operational continuity.
Candidates transfer IT best practices directly. OT networks prioritize availability, use proprietary protocols, and often cannot tolerate active probing or unexpected device restarts, so passive monitoring and segmentation come first.
What to do instead
Learn the OT-specific approach: passive discovery and asset visibility, network segmentation and zoning, then controlled enforcement. Be ready to explain why a passive sensor or span-based NDR is preferred over active scanning on a production control network.
Ignoring the operational and licensing context of a design answer, proposing a full Fabric or SOC stack without regard to FortiManager/FortiAnalyzer sizing, licensing tiers, or support constraints.
Candidates focus on technical correctness and forget that exam scenarios often include constraints like device counts, log retention, or existing contracts. An otherwise correct design can be wrong for the stated environment.
What to do instead
Before answering any design item, extract the stated constraints (device count, retention period, existing products, cloud or on-premises) and eliminate options that violate them. Practice stating the constraint that drives your choice in one sentence.