Fortinet FCF common mistakes
Fortinet FCF · Understand the traps and how to avoid them.
Treating the FortiGate as a stateful firewall only and forgetting that UTM/NGFW features (AV, IPS, web filter, application control) are separate security profiles that must be attached to a policy before they do anything.
Candidates study firewall policy concepts from generic networking material and assume enabling a feature globally turns it on everywhere; in FortiOS, profiles are inert until referenced by a firewall policy, so exam scenarios describing traffic that 'should have been blocked' are misread.
What to do instead
Rehearse the chain explicitly: create the profile, attach it to the policy, confirm the profile is applied in the correct direction (incoming vs outgoing interface), and verify inspection mode (flow vs proxy). For any question asking why malicious traffic passed, check profile-to-policy binding first, before routing or NAT.
Confusing the order of operations in a FortiGate packet's life: ingress, routing/doS policy, firewall policy, NAT, then egress, and misplacing where DoS policies, local-in policies, and central SNAT apply.
The exam tests troubleshooting by asking which object is evaluated at which stage; candidates who memorised feature lists rather than the pipeline pick plausible but wrong answers about why a VIP or policy route did not take effect.
What to do instead
Draw the pipeline from memory repeatedly and map each object onto a stage: DoS policy before the firewall policy, local-in policies for management traffic to the device, central SNAT and IP pools at the NAT stage, policy routes before the routing table lookup. Practise with 'traffic arrives on port2 destined for a VIP' style scenarios.
Assuming NAT is automatic or symmetric - expecting a policy with NAT enabled to handle both directions, or forgetting that a VIP needs a matching policy and that source NAT for outbound traffic needs an IP pool or 'use outgoing interface address'.
NAT behaviour is direction-specific and object-dependent, and candidates who only configured outbound NAT in labs cannot reason about inbound port forwarding or hairpin scenarios on exam questions.
What to do instead
Learn three patterns separately: outbound source NAT, inbound destination NAT via VIP plus policy, and VIP with port forwarding. For each, know which policy and which direction the NAT object applies to, and what the source address looks like on the server side after translation.
Reading log and event output superficially - picking the first event that looks related instead of correlating the log type (traffic, event, UTM, anomaly) with the time window and the specific field that answers the question.
Security Operations questions present a described incident and ask for the root cause; candidates who have not practised filtering by log type, policy ID, or threat name default to guessing from narrative cues in the question stem.
What to do instead
Practise a fixed triage order: identify which log type would record the event, state the field you would filter on, then interpret. Build fluency with traffic logs (action, policy ID, NAT fields), UTM logs (threat name, profile), and event logs (admin logins, config changes, HA events).
Treating FortiAnalyzer and FortiManager as interchangeable, or assuming logs are always available on the FortiGate for long-term investigation.
Candidates who have only used a standalone FortiGate assume local disk logging is universal; exam items about centralised logging, log retention, and multi-device management then get answered with the wrong product role.
What to do instead
Memorise the division of labour: FortiGate does local logging and real-time inspection, FortiAnalyzer aggregates, correlates, and reports on logs, FortiManager handles configuration and policy deployment across devices. For any question about 'where would you look', decide first whether it is a log/analysis task or a config/management task.
Confusing prevention with detection when choosing between IPS, antivirus, and sandboxing, and expecting a sandbox verdict to block the first instance of a file in real time.
Vendors describe these features in marketing terms and candidates collapse them; the exam distinguishes inline blocking from detonation and from post-hoc analysis, so 'which control stopped the file' questions are answered with the wrong component.
What to do instead
For each control, be able to state whether it blocks inline, what it inspects, and what happens on first encounter. Know that sandboxing typically submits files for analysis and blocks based on verdicts or subsequent intelligence, while IPS signatures match known patterns inline. Practise classifying a described attack into the control that would catch it and the point in the path where it sits.
Memorising cloud shared-responsibility slogans without being able to say which specific controls the customer still owns in IaaS, PaaS, and SaaS for a given asset (network controls, OS patching, identity, data).
The exam asks scenario-based questions about who configures what; candidates who learned only the phrase 'the provider secures the cloud, you secure what's in it' cannot map it to a concrete layer.
What to do instead
Build a three-column table for IaaS, PaaS, SaaS covering: physical, hypervisor, OS, runtime, application, identity/access, data, and network configuration. For each exam scenario, name the service model first, then the layer the asset belongs to, then the owner.
Assuming a security group or network ACL in the cloud behaves like a FortiGate policy - ignoring that security groups are typically allow-only, stateful, and attached to interfaces, while NACLs are stateless and subnet-level.
Candidates transfer on-premises firewall intuition to cloud constructs; questions about why traffic is unexpectedly permitted or denied hinge on these semantic differences.
What to do instead
Learn the contrast explicitly: security groups allow-only and stateful, NACLs allow and deny and stateless with rule ordering, and neither performs deep inspection. When a question describes unexpected cloud traffic, check both layers and the direction of the rule before concluding the FortiGate policy is at fault.
Mixing up authentication, authorisation, and accounting, or treating MFA as a substitute for least privilege when reasoning about an access-control failure.
Fundamentals questions describe an incident and ask which control failed; candidates who have not separated the three A's from the principle of least privilege pick the most familiar term rather than the correct layer.
What to do instead
For each scenario, ask three questions in order: was identity proven (authentication), was the action permitted for that identity (authorisation), was it recorded (accounting)? Then check least privilege and separation of duties separately. Practise labelling described failures with exactly one of these categories.
Describing encryption and PKI in vague terms - not distinguishing symmetric from asymmetric use cases, or not knowing what a certificate actually binds and who signs it.
The exam tests whether you can choose the right mechanism for a stated goal (confidentiality in transit, integrity, non-repudiation, key exchange); candidates who only know 'encryption protects data' cannot discriminate between options.
What to do instead
Learn the pairs precisely: symmetric for bulk confidentiality, asymmetric for key exchange and signatures, hashing for integrity, certificates binding a public key to an identity and signed by a CA. For each question, name the security goal first, then select the mechanism that provides it, and note which mechanisms provide integrity but not confidentiality.