Reinforce NSE4 concepts with active-recall study cards covering all 5 blueprint domains. Each card shows the question on the front and the correct answer with a full explanation on the back.
Flashcards work through active recall — the process of retrieving information from memory rather than passively re-reading it. Research consistently shows that active recall produces stronger, longer-lasting memory than re-reading study guides. For NSE4 preparation, this means flashcards are one of the highest-return study tools available.
Attempt recall first
Read the NSE4 question on each card, pause, and attempt to formulate the answer in your own words before revealing. This retrieval attempt — even if wrong — dramatically strengthens memory compared to immediately reading the answer.
Review wrong cards again
When you get a card wrong, note it and add it back to your review pile. Spaced repetition — seeing difficult cards more frequently — is the mechanism that makes flashcard study far more efficient than linear reading.
Study by domain
Group your NSE4 flashcard sessions by domain for the first 3–4 weeks. Master one domain before moving to the next. In the final week, shuffle all cards together to test cross-domain recall — which is what the real NSE4 exam requires.
Short sessions beat marathon reviews
20–30 flashcard cards per session, done daily, produces better retention than a single 200-card marathon session. Five short daily sessions per week over 4 weeks gives you over 400 total card reviews — enough to reliably pass NSE4.
Sample cards from the NSE4 flashcard bank. Read the question, think of the answer, then read the explanation below.
A FortiGate is configured with two ISPs (WAN1 and WAN2) and uses SD-WAN for load balancing. The administrator notices that traffic to a critical SaaS application is being sent over the slower link. What should the administrator do to ensure this traffic uses the faster link?
Create an SD-WAN rule to match the SaaS application's destination and set preferred member to the faster link.
SD-WAN rules allow you to define traffic steering policies based on application or destination, and setting a preferred member explicitly directs matching traffic to the faster link. This overrides the default load-balancing algorithm, ensuring critical SaaS traffic uses the optimal path without affecting other traffic.
A company is deploying a FortiGate HA cluster in active-passive mode across two data centers. The network team reports that after a failover, some existing TCP sessions are dropped. Which configuration change should be applied to maintain session persistence during failover?
Enable session synchronization between cluster members
In an active-passive HA cluster, session synchronization (config.sys ha session-sync) ensures that TCP session state information is replicated from the active unit to the passive unit. Without this, the passive unit has no knowledge of existing sessions after a failover, causing them to be dropped. Enabling session synchronization allows the new active unit to continue forwarding traffic for established sessions seamlessly.
A FortiGate administrator is troubleshooting a problem where users cannot access the Internet. The FortiGate has a default route pointing to the ISP gateway. The administrator runs 'execute ping 8.8.8.8' from the FortiGate CLI and it succeeds. However, internal users behind NAT are unable to reach external servers. Which is the most likely cause?
No NAT policy is configured for internal users
The administrator confirmed that the FortiGate itself can reach the Internet (ping 8.8.8.8 succeeds), so the default route and basic connectivity are working. However, internal users behind NAT cannot reach external servers, which indicates that traffic from internal users is either not being translated or is being blocked. The most likely cause is that no NAT policy (or firewall policy with NAT enabled) exists to perform source NAT for internal users, so their private IP addresses are not translated to the FortiGate's public IP, and the ISP gateway drops the packets because private addresses are not routable on the Internet.
A company uses FSSO (Fortinet Single Sign-On) with a domain controller. Users authenticate to the domain, and the FortiGate retrieves the login events. The firewall policy uses the FSSO group. Some users report that after logging in, they cannot access resources that require authentication. The administrator checks the FSSO status and sees that the FortiGate is receiving login events. What is the most likely cause?
The user's IP address is not in the source address range of the policy
Even though the FortiGate is receiving FSSO login events, the firewall policy also includes a source address restriction. If the user's IP address falls outside the defined source address range, the policy will not match, and the user will be denied access despite being authenticated via FSSO. The FSSO group membership is only one condition; the source IP must also satisfy the policy's source address criteria.
A company uses FortiGate with firewall policies to control access between internal VLANs. Users in VLAN 10 report they can access internet but cannot reach a server in VLAN 20 on port 443. The server is reachable from other VLANs. The administrator checks the firewall policy configuration: there is a policy from VLAN10 to VLAN20 allowing HTTPS, with NAT disabled and logging enabled. The policy has a schedule set to 'Always'. The administrator also checks that there are no overlapping policies. What is the most likely cause?
A security profile applied to the policy is blocking the HTTPS traffic.
Security profiles (such as web filtering, application control, or SSL inspection) applied to a firewall policy can inspect and block HTTPS traffic even when the policy itself allows the service. Since the server is reachable from other VLANs and the policy explicitly permits HTTPS with NAT disabled and logging enabled, the most likely cause is that a security profile is dropping or denying the traffic.
A company has a FortiGate with two ISPs: wan1 (primary) and wan2 (backup). They want all outbound traffic from internal users to use wan1, and if wan1 fails, traffic should automatically fail over to wan2. The administrator configures static routes: default route via wan1 gateway with distance 10 and default route via wan2 gateway with distance 20. They also configure an SD-WAN zone with both interfaces and set a strategy of 'Manual' with 'Best Quality' for wan1. After testing, failover does not occur when wan1 goes down. What is the most likely reason?
The SD-WAN strategy is set to Manual, which does not automatically failover; the administrator should use an automatic strategy or configure link health monitoring.
When the SD-WAN strategy is set to 'Manual', the FortiGate does not automatically perform failover based on interface or link health. Manual mode requires explicit administrator action or must be combined with link health monitoring to trigger a switch. Without an automatic strategy or configured health checks, the SD-WAN zone will continue to use wan1 even if it goes down, preventing failover to wan2.
An administrator is configuring a site-to-site IPsec VPN between two FortiGates. After applying the configuration, the VPN status shows 'down'. Phase 1 parameters are identical on both sides. What is the most likely cause of the failure?
The Phase 2 selectors (local and remote subnets) are mismatched.
When Phase 1 parameters are identical and the VPN is down, the most common cause is a mismatch in Phase 2 selectors (local and remote subnets). Phase 2 uses these selectors to negotiate the IPsec security associations (SAs); if they do not match exactly on both sides, the IKEv1/v2 Quick Mode or Child SA exchange will fail, leaving the tunnel in a 'down' state even though Phase 1 (IKE SA) may be up.
Refer to the exhibit. A network administrator configured an IPsec VPN between the main office and a branch office. Remote users at the branch office report that they cannot access resources in the main office. The tunnel status shows up on both sides. What is the most likely cause of the connectivity issue?
The phase2 configuration does not specify the local and remote subnets to protect.
The phase2 configuration in an IPsec VPN must explicitly define the local and remote subnets (proxy IDs) that the tunnel is meant to protect. Without these subnets, the IPsec security associations (SAs) cannot be established for the actual traffic, even if the tunnel status shows as up (phase1 is complete). The tunnel status only indicates that IKE phase1 negotiation succeeded, but without phase2 proxy IDs, no traffic will be encrypted or routed through the tunnel, causing connectivity failures.
A network administrator is troubleshooting an IPsec VPN tunnel between two FortiGates. Phase 1 is up, but Phase 2 fails to establish. The debug command 'diagnose vpn ike log' shows: 'no suitable proposal found'. What is the most likely cause?
Phase 2 encryption or authentication algorithms do not match on both sides.
The 'no suitable proposal found' error in Phase 2 of an IPsec VPN tunnel indicates that the Phase 2 parameters (encryption algorithm, authentication algorithm, or PFS settings) do not match between the two FortiGate peers. Since Phase 1 is up, the IKE SA is established, meaning pre-shared keys, remote gateway reachability, and basic firewall policies for IKE traffic are correct. The mismatch specifically occurs in the Phase 2 proposal negotiation, where each side sends its supported transforms and the responder cannot find a common set.
An administrator wants to inspect SSL traffic to a specific finance application that uses a custom port (9443) and a self-signed certificate. Which configuration is required?
Use deep inspection and add the application's self-signed certificate to the FortiGate's trusted CA list.
Deep inspection is required to decrypt and inspect SSL traffic using a self-signed certificate on a non-standard port. The FortiGate must trust the application's self-signed certificate by adding it to the trusted CA list; otherwise, the deep inspection proxy will fail to validate the certificate and drop the connection. Certificate inspection (Option A) only checks the certificate metadata without decrypting the payload, so it cannot inspect the actual application traffic.
A company with 500 employees uses FortiGate as their internet gateway. They recently enabled SSL deep inspection using the built-in CA certificate. After deployment, many users report that they cannot access their online banking websites. The error message in the browser says 'The certificate is not trusted'. The administrator has already pushed the FortiGate CA certificate to all domain-joined computers via Group Policy. However, the problem persists for banking sites. The administrator also notices that banking sites load fine on mobile devices that do not have the CA certificate installed. What is the most likely cause and solution?
Banking websites use certificate pinning. Exempt them from deep inspection using an SSL inspection exemption list.
Banking websites often use HTTP Public Key Pinning (HPKP) or certificate pinning, where the browser expects a specific certificate or public key from the server. When FortiGate performs SSL deep inspection, it re-signs the server's certificate with its own CA, breaking the pinning validation. This causes the 'certificate not trusted' error even when the FortiGate CA is trusted, because the browser detects that the presented certificate does not match the pinned certificate. The correct solution is to exempt banking sites from deep inspection using an SSL inspection exemption list, allowing the original server certificate to pass through.
A network administrator notices that an IPS sensor is generating excessive false positives for a specific signature. The administrator wants to exclude traffic from a trusted internal server (IP 10.1.1.100) from inspection for that signature only, while keeping other signatures active. Which configuration change should the administrator apply?
Create an IPS filter that excludes the server's source IP address from the signature.
An IPS filter allows the administrator to define a rule that excludes traffic from a specific source IP address (10.1.1.100) from inspection for a particular signature, while leaving all other signatures active. This granular approach ensures that false positives for that signature are reduced without disabling the signature entirely or affecting other traffic.
A company has two remote sites connected via an SD-WAN overlay. The headquarters uses a FortiGate with two WAN links: Fiber (priority 1) and LTE (priority 2). The SD-WAN rule for business-critical traffic uses the 'best quality' strategy with SLA targets for latency and jitter. The fiber link occasionally experiences high jitter but low latency. The engineer notices that traffic is not failing over to LTE even when jitter exceeds the threshold. What is the most likely reason?
The performance SLA for jitter is not configured, only latency.
The SD-WAN rule uses the 'best quality' strategy, which selects the best link based on configured SLA metrics. If only latency is configured in the performance SLA, jitter exceeding the threshold will not trigger a failover, as the SLA only evaluates the configured metrics. The fiber link may still meet the latency SLA, so traffic remains on it despite high jitter.
An SD-WAN rule is configured with a 'manual' strategy and multiple members. The engineer wants to ensure that voice traffic always uses the MPLS link as long as it meets the SLA, otherwise use the broadband link. Which configuration is required?
Set the manual strategy with MPLS as first member and enable SLA check.
A manual strategy with ordered members and an SLA check allows the SD-WAN rule to first attempt the MPLS link; if the SLA is met, traffic uses MPLS, and if the SLA fails, the rule automatically fails over to the next member (broadband). This directly implements the engineer's requirement of 'MPLS if SLA met, otherwise broadband.'
An administrator runs 'diagnose sys session filter dport 443' and then 'diagnose sys session list'. The output shows many sessions with 'proto_state=01' and 'expire=3599'. What does 'expire=3599' indicate?
The session will timeout in 3599 seconds
In FortiGate diagnostics, the 'expire' field in the session list output indicates the remaining time in seconds before the session times out. A value of 3599 seconds means the session will be removed from the session table after that many seconds of inactivity, assuming no further traffic matches the session. This is a key metric for understanding session lifecycle and timeout behavior.
The NSE4 flashcard bank covers all 5 official blueprint domains published by Fortinet. Cards are distributed proportionally, so domains with higher exam weight have more cards.
Domain Coverage
System and Network Administration
Firewall Policies and NAT
Authentication and VPN
Security Profiles
High Availability and Diagnostics
Both flashcards and practice questions are evidence-based study tools. The difference is in what they train:
Flashcards — concept retention
Best for memorising definitions, acronyms, protocol behaviours, command syntax, and conceptual distinctions. Use flashcards to build the foundational vocabulary that NSE4 questions assume you know.
Best in: weeks 1–3
Practice tests — application
Best for applying concepts to realistic scenarios, eliminating distractors, and building exam stamina.NSE4 questions test scenario reasoning — not just recall — so practice tests are essential.
Best in: weeks 3–6
The most effective NSE4 study plan combines both: use flashcards for the first 2–3 weeks to build conceptual foundations, then shift to practice tests and mock exams in the final 2–3 weeks to apply and benchmark that knowledge. Most candidates who pass on their first attempt use both tools.
Yes. Courseiva provides free NSE4 flashcards across all official exam domains. Every card includes the correct answer and a full explanation of why it is right and why the distractors are wrong. The platform also includes topic-based practice, mock exams, and readiness tracking — no account required.
Courseiva has 282+ original NSE4 flashcards across all 5 exam blueprint domains. New cards are added regularly as the question bank grows. All cards are written by certified engineers against the official Fortinet exam objectives.
Courseiva flashcards are purpose-built for IT certification exams. Unlike generic flashcard platforms where content quality varies, every Courseiva card is mapped to the official NSE4 exam blueprint, written by engineers who hold the certification, and includes a full explanation of the correct answer and why the distractors are wrong. This explanation quality is what separates genuine learning from rote memorisation.
Courseiva is a web platform — an internet connection is required. For offline study, we recommend creating free Courseiva account, using the platform in your browser, and using your device's offline capabilities if your browser supports offline web apps.
Save your results, see which domains need more work, and get spaced repetition recommendations — all free.
Sign Up FreeFree forever · Every certification included