NSE4 Security Profiles Practice Question
A large enterprise uses a FortiGate 600E in NAT mode to protect its internal network. The security team has implemented an Application Control profile that categorizes applications and allows only 'Business' and 'General-Interest' categories. They have also applied an IPS sensor with default settings and enabled SSL inspection for outbound traffic. Recently, the helpdesk has received reports that some users cannot access a critical cloud-based CRM application, while others can. The CRM uses HTTPS on port 443. The Application Control profile is applied to the firewall policy for outbound traffic. The IPS sensor is also applied. The FortiGate is not configured for load balancing. Which of the following is the most likely cause of the issue?
⚠ Common exam trap
Many exam-takers assume IPS or SSL inspection is the culprit for selective access issues, but the key clue is that the problem affects only some users, pointing to a categorization mismatch in Application Control rather than a global block.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The CRM application is not categorized in the Application Control database.
The Application Control profile is configured to allow only 'Business' and 'General-Interest' categories. If the CRM application is not categorized in FortiGuard's Application Control database, or if it falls under a different category (e.g., 'Uncategorized' or 'Unknown'), the FortiGate will block the traffic by default. This explains why some users can access the CRM (if they are using a different path or the application is categorized differently) while others cannot, as the FortiGate enforces the profile based on the application signature match.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The IPS sensor is detecting and blocking the CRM traffic as an attack.
Why it's wrong here
The FortiGate's IPS engine inspects traffic for known vulnerability signatures and exploit attempts, and its actions are enforced uniformly across all sessions that match a given policy. If the CRM traffic had triggered an IPS signature, the FortiGate would drop every connection exhibiting that same pattern, not just a random subset of users. Furthermore, a legitimate CRM application generally does not produce exploit-like signatures, and without SSL inspection the IPS cannot even evaluate the encrypted payload. Therefore, IPS blocking fails to explain why only some users are affected.
- ✓
The CRM application is not categorized in the Application Control database.
Why this is correct
Application Control in FortiGate matches traffic against a constantly updated signature database, and each signature is associated with a category. If the CRM application uses a proprietary protocol or a less-common of a known service, it may remain 'Uncategorized,' and any security policy whose Application Control profile sets the uncategorized action to 'deny' will block that traffic. This blocking is policy-specific, so if some users have a policy that omits or allows uncategorized traffic while others have a policy that denies it, only the latter group will experience the outage. This aligns perfectly with the reported symptom of only some users being unable to reach the CRM.
- ✗
The FortiGate is performing load balancing and some users are directed to a different path.
Why it's wrong here
FortiGate in NAT mode operates as a stateful firewall and does not perform per-request load balancing unless a specific feature such as virtual server load balancing or SLBC clustering is explicitly configured—neither of which is mentioned here. In the default NAT mode, each connection is processed through the same ordered security policy and profile chain regardless of source IP, so there is no 'different path' that could selectively block users. Even if load balancing were active, it would only distribute traffic to backend servers, not alter the security inspection outcome, so this option is not a plausible cause.
- ✗
SSL inspection is blocking the CRM traffic due to certificate validation failure.
Why it's wrong here
SSL inspection uses an inspection profile attached to a security policy, and when a certificate validation failure occurs, the FortiGate's behavior (e.g., block, allow, or ignore) is applied to every session to that destination under that policy. Since all users in the same policy and same CRM destination are subject to the same certificate validation logic, it cannot selectively impact only some users unless each user has a separate policy—which would typically be based on source IP or user group. In practice, a certificate failure on the server side would affect all users equally, and the FortiGate might also simply skip inspection if the profile is set to 'certificate-inspection' rather than full SSL proxy. Thus, this option does not explain the user-specific symptom.
Visual reference
Go deeper
Related to this question
About these practice questions
This NSE4 question is part of Courseiva's 773-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.