General Exam Tips
- 1.Read ALL answer options before selecting — Fortinet distractors are intentionally close to the correct answer
- 2.When a scenario describes a connectivity failure, ask yourself: is this a control-plane (FortiLink/CAPWAP management) problem or a data-plane (security policy/routing) problem? The fix is different for each
- 3.With approximately 40 questions in 75 minutes, you have under 2 minutes per question — do not overthink. Mark uncertain questions and come back
- 4.Always answer every question — there is no penalty for wrong answers on Fortinet exams
- 5.Multi-select questions require ALL correct answers. A partially correct selection scores zero
- 6.Scenario questions often contain one red-herring detail. Identify what the question is actually asking before evaluating the options
- 7.When the question describes something that 'should work but doesn't,' look for a single missing prerequisite rather than a complex misconfiguration
- 8.Aim for 75%+ on practice exams before sitting the real exam — the actual exam skews harder than most free practice banks
- 9.Authentication (25% weight) is the highest-stakes domain — if you are short on study time, prioritize RSSO vs FSSO and 2FA token assignment
- 10.Do not confuse what you know from real-world Fortinet deployments with what the exam expects — the exam tests textbook behavior, not production workarounds
Quick Navigation
FortiSwitch Deployment and Management
Must-Know Facts
- FortiLink requires DHCP server enabled on the FortiLink interface — this is how FortiSwitch gets its management IP during discovery
- Newly connected FortiSwitch units appear as 'Unauthorized' until an administrator explicitly authorizes them, or auto-authorization is enabled on the FortiLink interface
- Security policies NEVER fix a FortiSwitch management problem — the exam frequently offers 'create a security policy' as a distractor when a switch is not being discovered or managed. FortiLink management traffic is not subject to security policies; any FortiSwitch connectivity issue must be solved in the switch controller configuration or FortiLink interface settings
- VLAN optimization restricts auto-generated ISL trunk ports to carry only user-defined VLANs instead of all VLANs 1–4093
- Quarantine VLAN is 4093 by default — it is automatically allowed on all FortiSwitch ports; quarantined devices are isolated but still connected
- FortiSwitch firmware must be compatible with the FortiGate FortiOS version — version mismatch can silently prevent FortiLink from establishing
- ISL (inter-switch link) trunks between managed FortiSwitch units are auto-generated by FortiGate — you do not need to manually create them
- VLAN pruning manually removes specific VLANs from a trunk; VLAN optimization globally restricts auto-generated trunks — they are not the same feature
- Port security features (DHCP snooping, dynamic ARP inspection, IP source guard, storm control) are configured on managed switch ports from the FortiGate GUI, not from the switch CLI
- In a multi-tier FortiSwitch topology (daisy-chained), all switches are still managed by the single FortiGate — there is no secondary controller
Common Traps
Confusing Pairs
Scenario Tips
FortiSwitch physical link is up, switch is discovered, but shows 'Unauthorized' — admin cannot manage the switch
Authorize the switch in the FortiGate switch controller (Security Fabric > Switch Controller > Managed FortiSwitch). If you want future switches to auto-authorize, enable 'auto-auth-extension-device' on the FortiLink interface
Adding a security policy to allow traffic from the FortiSwitch IP — security policies do not govern FortiLink management traffic; this will not fix the authorization issue
FortiSwitch is not discovered at all — physical link is confirmed up, FortiLink interface is configured
Check that DHCP server is enabled on the FortiLink interface. Without DHCP, the FortiSwitch cannot get an IP and cannot establish the FortiLink session
Checking FortiGuard subscription status — FortiGuard has no bearing on FortiLink operation
Auto-generated ISL trunk between two managed FortiSwitches is carrying all VLANs 1–4093, causing excessive traffic
Enable VLAN optimization on the FortiSwitch controller — this restricts auto-generated ISL trunks to carry only user-defined VLANs
Selecting VLAN pooling — VLAN pooling distributes authenticated users across multiple VLANs for broadcast domain reduction, which is unrelated to ISL trunk traffic volume
Last-Minute Facts
FortiAP and Wireless Infrastructure
Must-Know Facts
- CAPWAP requires BOTH UDP 5246 (control) and UDP 5247 (data) — exam troubleshooting questions that describe an AP discovering its controller but clients failing to pass traffic point to port 5247 being blocked; questions where the AP never appears in the controller at all point to port 5246 being blocked
- Tunnel mode: all wireless traffic encapsulated in CAPWAP tunnel to FortiGate for inspection — required when security policies must inspect wireless traffic
- Bridge mode: wireless traffic forwarded locally at the AP — lower latency but bypasses FortiGate inspection; use for performance-sensitive local SSIDs or remote branch traffic
- Security Fabric Connection is a per-interface setting — the exam tests this by presenting a scenario where an AP has an IP, a physical link, and even a working CAPWAP session, but is invisible in the fabric topology. The diagnosis is always the same: check whether Security Fabric Connection is enabled on the interface the AP connects through. No amount of AP-side configuration fixes a missing Security Fabric Connection setting on FortiGate
- Wireless NAC requires a minimum of 2 VLANs with L3 (including DHCP): one onboarding VLAN and at least one target VLAN — without both, NAC cannot dynamically reassign clients
- AP authorization: newly connected FortiAPs appear as 'Unauthorized' just like FortiSwitches — they must be authorized before they can serve clients
- Rogue AP suppression can interfere with legitimate neighboring wireless networks — only enable after confirming the AP is truly unauthorized
- FortiAIOps is a monitoring and recommendation tool — it identifies wireless anomalies and suggests optimizations but does NOT automatically apply any changes
- CAPWAP discovery sequence: static IP → DHCP option 138 (provides controller IP directly) → DNS (AP appends domain suffix from DHCP option 15 to the default hostname 'fortinet-capwap-controller' to form the FQDN) → FortiEdge Cloud → multicast → broadcast — if an AP cannot be discovered, check option 138 first, then DNS resolution of the controller FQDN
Common Traps
Confusing Pairs
Scenario Tips
FortiAP is connected to a managed FortiSwitch port, has an IP address, physical link is up, but does not appear in the wireless controller or Security Fabric topology
The VLAN/interface the FortiAP is connected to does not have Security Fabric Connection enabled. Enable it on that interface in FortiGate — this is required for CAPWAP discovery to result in fabric onboarding
Checking if the FortiAP is in bridge mode vs tunnel mode — traffic forwarding mode does not affect AP discovery or Security Fabric onboarding
Remote branch office needs FortiAPs to serve users who primarily access local file servers on the same LAN. Minimal latency is required
Configure the SSID in bridge mode — traffic goes directly from the AP to the local network without tunneling to FortiGate over the WAN, minimizing latency
Tunnel mode — while it provides FortiGate security inspection, it routes all wireless traffic through the WAN link to the central FortiGate, adding significant latency and using WAN bandwidth
Wireless NAC is configured, clients connect, but they are never moved out of the onboarding VLAN regardless of their device type
Verify that the target VLANs are configured with L3 settings and DHCP. Also verify that the NAC policy matching criteria correctly identifies the device types and that policies are ordered correctly (top-to-bottom evaluation)
Enabling FortiAIOps — FortiAIOps is for wireless performance monitoring, not NAC policy enforcement
Last-Minute Facts
Authentication and Single Sign-On
Must-Know Facts
- RADIUS ports: UDP 1812 (authentication), UDP 1813 (accounting) — legacy 1645/1646 exist but 1812/1813 are standard and what the exam expects
- LDAP standard port = TCP 389 (cleartext); LDAPS encrypted port = TCP 636 — to enforce encrypted LDAP you change to port 636 AND set 'secure' mode to ldaps
- LDAP bind types: simple (credentials sent in cleartext), regular (uses bind DN/password), anonymous (no credentials) — the exam tests which is appropriate for given security requirements
- RSSO (RADIUS Single Sign-On): FortiAuthenticator receives RADIUS accounting messages from network devices (WLC, switches, VPN) and forwards user-IP mappings to FortiGate
- FSSO (Fortinet Single Sign-On): monitors Windows Active Directory domain controller logon events via DC Agent, polling, or FortiAuthenticator — forwards user-IP mappings to FortiGate
- FortiAuthenticator dual role: acts as RADIUS SERVER (authenticating users against LDAP/AD) AND as RADIUS CLIENT (receiving accounting messages for RSSO) — these are two different functions
- Two-factor authentication requires per-user FortiToken assignment — enabling 2FA globally or having tokens activated is NOT sufficient without associating a token to each specific user account
- FortiAuthenticator can act as a Certificate Authority (CA) for issuing certificates used in certificate-based authentication
- Syslog integration with FortiAuthenticator: external network devices send syslog authentication events to FortiAuthenticator, which parses them and generates RSSO user session records
- Authentication flow order: 802.1X attempted first, MAB fallback if no supplicant responds, captive portal as final fallback for web-based authentication
- RADIUS shared secret must match exactly on both FortiGate and the RADIUS server — a mismatch silently fails authentication with no obvious error message
- LDAP cnid (Common Name Identifier): use 'sAMAccountName' for Active Directory, 'cn' for standard LDAP
Common Traps
Confusing Pairs
Scenario Tips
A company uses a wireless LAN controller that sends RADIUS accounting messages on user connect/disconnect. The team wants FortiGate to apply user-based policies without re-authentication
Configure RSSO on FortiAuthenticator — it receives the RADIUS accounting messages from the WLC and forwards user-IP mappings to FortiGate for transparent policy enforcement
FSSO with DC Agent — FSSO monitors Windows AD logon events, not RADIUS accounting messages from a WLC. This would not capture WLC-based authentication events
Users authenticating to Windows domain computers are not being identified by FortiGate for identity-based policies, even though FSSO is configured
Verify the FSSO agent or FortiAuthenticator collector is monitoring the correct domain controllers — if the DC authenticating users in that subnet is not being monitored, those logons are invisible to FSSO
Checking if RADIUS accounting is enabled on the switches — RADIUS accounting is for RSSO, not FSSO. FSSO relies on DC logon events, not RADIUS
VPN users can log in with only their password even though two-factor authentication has been configured globally on FortiGate
The FortiToken has not been associated with the individual user accounts. Go to each user account and assign a FortiToken — global 2FA configuration alone does not enforce 2FA for users without a token linked
FortiToken Mobile incompatibility — FortiToken Mobile is fully supported by FortiGate for 2FA
Security requirements mandate encrypted LDAP communication to Active Directory. Currently using standard LDAP
Change the LDAP server configuration: set secure mode to 'ldaps' and change the port from 389 to 636. This enables LDAP over TLS
Changing bind type from simple to anonymous — anonymous bind removes credentials entirely, reducing security rather than encrypting communication
FortiAuthenticator is receiving RADIUS accounting from a wireless controller but FortiGate is not enforcing user-based policies for those wireless users
Check two things: (1) the RADIUS accounting interface on FortiAuthenticator is enabled to receive accounting messages, and (2) the RADIUS client (the wireless controller) is defined in FortiAuthenticator with matching shared secret. Also verify the RSSO attribute configuration on FortiAuthenticator correctly maps the RADIUS accounting fields to user session records that FortiGate can consume
Reconfiguring FortiGate to directly receive RADIUS accounting — the proper architecture is FortiAuthenticator as the intermediary that converts RADIUS accounting to RSSO user session records forwarded to FortiGate
Last-Minute Facts
Network Access Control and Security
Must-Know Facts
- 802.1X authentication roles: Supplicant (endpoint software), Authenticator (FortiSwitch port), Authentication Server (RADIUS) — 802.1X requires supplicant software on the endpoint
- Devices without 802.1X supplicant capability (printers, IP cameras, IoT) cannot use 802.1X and must fall back to MAC Authentication Bypass (MAB)
- MAB sends the device MAC address as both username AND password to RADIUS — the format (lowercase, no separators by default) must match what the RADIUS server expects
- Authentication order: 802.1X is attempted first → if no supplicant response, MAB is tried → captive portal as the final web-based fallback
- Dynamic VLAN assignment requires THREE specific RADIUS attributes returned during authentication: Tunnel-Type (value=VLAN/13), Tunnel-Medium-Type (value=802/6), Tunnel-Private-Group-ID (VLAN ID or name) — missing ANY one causes fallback to the default VLAN
- VLAN pooling: distributes users across multiple VLANs in a pool (round-robin or hash-based) to prevent single broadcast domain overcrowding — different from dynamic VLAN which puts users into ONE specific VLAN
- NAC policies on FortiGate are evaluated TOP-TO-BOTTOM — the first matching policy is applied; order matters and is a common misconfiguration cause
- NAC policy matching criteria: device type, OS, MAC address, EMS tag, user group, VLAN, FortiClient compliance status
- Guest portals: captive portal redirect, guest user provisioning, isolated guest VLANs, sponsor-based approval — guest users get temporary access with limited permissions
- FortiGate NAC policies are built into FortiOS and work with FortiSwitch/FortiAP — FortiNAC is a separate product for multi-vendor environments and should not be confused with built-in NAC
Common Traps
Confusing Pairs
Scenario Tips
IP security cameras that do not support 802.1X need to be placed in a dedicated IoT VLAN automatically
Configure MAB (MAC Authentication Bypass) on the FortiSwitch ports with dynamic VLAN assignment. The RADIUS server returns the IoT VLAN attributes when the camera MAC authenticates, placing cameras in the correct VLAN automatically
FSSO with device-based policies — FSSO monitors Windows AD logon events, which cameras do not generate. This will not work for non-802.1X IoT devices
Printers authenticate successfully via MAB but land in the default VLAN instead of the printer VLAN
The RADIUS server is not returning the correct Tunnel attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID). Verify all three are present and correctly configured in the RADIUS policy for printer MACs. MAB fully supports dynamic VLAN — this is a RADIUS configuration issue
Upgrading printers to support 802.1X — this is unnecessary if MAB is authenticating successfully; the problem is VLAN assignment (RADIUS attributes), not authentication itself
A Security Fabric automation detects a compromised endpoint and the automation stitch moves it to VLAN 4093
VLAN 4093 is the default quarantine VLAN. The endpoint has been automatically quarantined by Security Fabric automation — it is isolated in the quarantine VLAN but still connected to the network
VLAN 4093 being a dynamic VLAN assignment from RADIUS — quarantine VLAN 4093 is a Fortinet-specific reserved VLAN for quarantine, not a RADIUS-assigned VLAN
NAC policies are configured but some devices are being assigned to the wrong VLAN despite matching the intended policy criteria
Check NAC policy order — policies are evaluated top-to-bottom and the first match wins. A more general policy above the intended specific policy may be matching first. Reorder so specific policies are above broad ones
The FortiSwitch port is configured wrong — NAC policy ordering is the most common cause of wrong VLAN assignment when authentication itself succeeds
Last-Minute Facts
Security Fabric and FortiManager Integration
Must-Know Facts
- Security Fabric requires a root FortiGate — without a root device designated, downstream FortiSwitch and FortiAP will not appear in the fabric topology
- FortiManager pushes configurations TO devices but does NOT lock them — configuration drift occurs when local administrators modify settings directly on devices after FortiManager deployment
- Zero-touch provisioning (ZTP) requires the new device to reach FortiManager. DNS resolution and connectivity (TCP 541) must be available, often via DHCP option 240 or 241 providing the FortiManager FQDN/IP
- FortiManager model devices: pre-staged configuration entries for devices not yet deployed — when the real device connects, it matches the model device entry and receives the pre-staged config automatically
- ADOM (Administrative Domain) in FortiManager provides multi-tenant isolation — each ADOM has separate administrators, policies, and devices with no cross-ADOM visibility
- FortiAIOps is monitoring and recommendations only — it identifies wireless anomalies but requires an administrator to manually implement any suggested configuration changes
- Firmware management via FortiManager: centralized upgrades for FortiGate, FortiSwitch, and FortiAP with scheduling, compliance checking, and rollback capability
- Security Fabric Connection must be enabled on interfaces connecting to FortiSwitch and FortiAP for those devices to appear in the fabric topology
Common Traps
Confusing Pairs
Scenario Tips
50 new FortiSwitch units need to be deployed at remote branch offices and receive their full configuration automatically on first boot without any on-site engineer
Use FortiManager zero-touch provisioning with model devices — pre-stage the switch configurations in FortiManager as model device entries. When switches power on and connect, they receive their configs automatically. Ensure DNS and TCP 541 connectivity to FortiManager is available
CLI script execution — CLI scripts require someone to manually run them on each device or at least trigger execution, which is not 'zero-touch'
After FortiManager pushes a VLAN template to all managed FortiGate devices, one site shows a different VLAN configuration than what was pushed
A local administrator modified the FortiGate at that site directly after the template was pushed. FortiManager does not enforce configuration locking. The fix is to re-push the template and potentially restrict local admin access
The FortiGate firmware is incompatible with the template — firmware incompatibility would cause a push failure, not a silent configuration difference after a successful push
FortiAIOps shows multiple wireless optimization recommendations, but none of the suggested changes are being applied
This is expected behavior — FortiAIOps only provides recommendations, it does not automatically implement changes. An administrator must manually review and apply each suggestion
FortiAIOps requires FortiManager to apply changes — FortiAIOps and FortiManager are independent; FortiAIOps does not push through FortiManager for change execution