Security Profiles practice questions

The CA certificate used for SSL inspection is not trusted by the clients.

Why it fails: While an untrusted CA certificate is a common cause of SSL inspection failures, the stem explicitly states that the certificate is trusted on the clients. Therefore, this is not the issue.

The firewall policy has SSL inspection disabled.

Why it fails: The stem says SSL inspection is enabled, so this option is false.

The DNS server is not resolving the domain names.

Why it fails: DNS resolution issues would affect all web traffic (HTTP and HTTPS), not specifically HTTPS, making it an unlikely cause.

Application Control and Antivirus

Why it fails: Application Control and Antivirus is wrong because Application Control identifies and categorizes traffic by application signatures (e.g., Facebook, Spotify) rather than by the file type being transferred; it has no native capability to intercept and block a download simply because it’s an .exe file. Antivirus only scans files for malware after they are allowed through, so it cannot prevent the download of executables in the first place. Thus this combination fails the requirement to block executable file downloads.

Web Filtering and IPS

Why it fails: Web Filtering and IPS is wrong because Web Filtering can block file types (as in the correct answer), but IPS (Intrusion Prevention System) is focused on detecting and blocking network-level exploits and attack patterns, not on filtering downloads by file extension. IPS does not inspect the MIME type or filename of a downloaded file to decide whether to permit or deny it; it operates on vulnerability signatures. Therefore, adding IPS to Web Filtering does not provide the file-type download blocking required.

DNS Filtering and Web Filtering

Why it fails: DNS Filtering and Web Filtering is wrong because DNS Filtering only controls which domain names can be resolved and accessed, typically blocking malware or adult domains based on threat intelligence; it cannot examine individual file downloads within a permitted domain. Web Filtering alone can block file types, but when paired with DNS Filtering, the combination still lacks the ability to block executable downloads from allowed domains because DNS filtering does not perform file-level inspection. The correct mechanism for file-type blocking is the file filter in Web Filtering, not DNS filtering.

Configure certificate inspection on the policy.

Why it fails: Certificate inspection only reads certificate metadata such as CN and issuer; it cannot decrypt the SSL payload on port 9443, so content inspection fails. It is tempting because it handles self-signed certificates without a trusted CA, but full inspection requires deep inspection with the certificate imported as a trusted CA.

Disable SSL inspection for that application.

Why it fails: Disabling SSL inspection bypasses decryption entirely, so the finance application's traffic is never examined, defeating the stated requirement. It is tempting as a workaround for the self-signed certificate trust error, but the correct approach is importing that certificate as a trusted CA for deep inspection.

Use flow-based inspection with certificate inspection.

Why it fails: Flow-based inspection is a processing mode, not an inspection type; pairing it with certificate inspection still only reads certificate metadata and never decrypts port 9443 traffic. It is tempting because flow-based mode is commonly used, but deep inspection is the mechanism that decrypts SSL.

Static URL filtering

Why it fails: Static URL filtering matches fixed URLs or patterns in a local list; it cannot consult reputation databases, so newly registered malicious sites are missed. It is tempting because it blocks known bad URLs, but dynamic URL filtering and botnet/security categories provide the live threat intelligence.

Application control

Why it fails: Application control identifies and blocks traffic by application signature, not by URL category or reputation, so it cannot classify a site as malicious. It is tempting because it genuinely restricts which applications run or reach the network, and would be correct when the requirement is to block peer-to-peer tools or unauthorised apps rather than malicious web destinations.

DNS filter

Why it fails: DNS filter resolves or blocks queries by domain reputation, but it cannot inspect the full URL path or content, so it fails where malicious pages sit on otherwise legitimate domains. It is tempting because it genuinely blocks known-bad domains cheaply, and would be correct when the requirement is to stop resolution of malicious hostnames network-wide.

The deep inspection profile is misconfigured.

Why it fails: No evidence of misconfiguration.

The antivirus profile is blocking the traffic.

Why it fails: Antivirus would not block all HTTPS.

The web filter profile 'strict' is blocking all sites.

Why it fails: The profile would block some, not all.

The web filter profile is applied globally.

Why it fails: Web filtering on a FortiGate is applied per firewall policy, not as a global setting. While a global web filter profile can be configured, it only affects traffic that hits policies with that profile; it does not automatically differentiate between student and teacher traffic. Because the scenario shows different outcomes for two user groups, a global application cannot explain the selective blocking, so this option is incorrect.

The teacher policy has a schedule that restricts access.

Why it fails: A schedule in a FortiGate policy restricts when the policy is active, not which users it affects. Even if the teacher policy had a schedule, that only gates the entire policy's availability by time of day; it does not explain why the same time period would block students yet allow teachers. Since no schedule is mentioned in the scenario, this cannot account for the observed filtering difference, so the statement is incorrect.

The student policy is placed after the teacher policy.

Why it fails: If the student policy is below the teacher policy in the list, then traffic is evaluated against the teacher rule first. Since teacher traffic would match that earlier rule, the teacher's permissive profile would be applied before the student's restrictive profile is ever considered, allowing students to bypass the web filter. This ordering would prevent the school from blocking students, so it contradicts the desired outcome and is therefore wrong.

Application control profiles can only have one rule.

Why it fails: In FortiOS, application control profiles are rule sets that can contain multiple rules, each matching specific application categories or individual applications, with actions such as allow, monitor, or block. Rules are evaluated in order, so an administrator can create granular policies (e.g., block Zoom but monitor Teams) within the same profile. Thus, the profile structure is not limited to a single rule, and the issue is not profile capacity but rule precedence and matching logic.

The 'monitor' rule for Teams overrides the 'block' rule for Zoom.

Why it fails: In FortiOS, each application control rule has an action (allow, monitor, block) and rules are evaluated sequentially. A 'monitor' rule logs traffic but allows it; it does not affect other applications. The presence of a monitor rule for Teams has no bearing on the block rule for Zoom unless the rules overlap and the monitor rule is evaluated first. If the block rule for Zoom is defined earlier in the profile, Zoom is blocked regardless of any later Teams monitor rule. Therefore, the override claim is false; rule order and matching logic dictate the outcome.

Application control uses port-based inspection and Zoom uses a non-standard port.

Why it fails: FortiOS application control uses deep packet inspection (DPI) and application signatures to identify traffic regardless of port. Unlike traditional port-based filtering, it examines packet payloads, flows, and behavioral characteristics. Since Zoom can use various ports and protocols (e.g., UDP/TCP dynamic ports), port-based inspection would be unreliable. Even if Zoom used a non-standard port, application control can still identify it via its signature, so the block rule should have matched if evaluated. Thus, port is not the reason the block failed.

The IPS engine is bypassed because the traffic matches a fast-path rule.

Why it fails: Fast-path is a hardware acceleration feature that forwards packets for existing sessions without some software processing, but it does not disable IPS inspection. In FortiOS, a fast-path rule merely speeds up packet forwarding; any traffic still goes through the IPS engine via flow-based inspection before being permitted. Therefore, matching a fast-path rule cannot explain why an IPS block action was not enforced, as IPS remains active on all traversing sessions.

The IPS sensor is not enabled in the firewall policy.

Why it fails: If the IPS sensor were not enabled in the firewall policy, the sensor's block action would never have been invoked, meaning there would be no original block for the administrator to observe being overridden. The scenario explicitly states that an IPS block action exists, implying that the IPS sensor is indeed attached to the policy and active. Thus, the cause of an unenforced block cannot be a missing sensor, because no block would have occurred in the first place.

The IPS sensor is configured with 'monitor' action instead of 'block'.

Why it fails: A monitor action in an IPS sensor only generates a log entry and allows the traffic to pass, so if the sensor were configured with 'monitor' instead of 'block', no enforcement would be expected. However, the question's premise specifies that the sensor is configured to block, and the issue is that the block is not happening. Since the configuration is explicitly a block action, a misconfigured monitor action cannot be the underlying reason for the observed behavior.

quarantine

Why it fails: Incorrect. 'Quarantine' is not a valid action for an application control rule; it is used in other security features like IPS or antivirus.

redirect

Why it fails: Incorrect. 'Redirect' is not a valid action for an application control rule.

monitor

Why it fails: Incorrect. 'Monitor' is not a valid action for an application control rule; it is used in application control profiles.

The users are accessing the phishing sites via IP address, not URL.

Why it fails: The explanation that users are accessing phishing sites via IP address is incorrect because FortiGate web filtering operates by inspecting the requested URL, including the hostname and path, not the destination IP. Phishing campaigns embed URLs in emails to direct victims to specific domains; using a raw IP address would be atypical and would also bypass the URL database, but the FortiGate would still see the IP in the HTTP request and attempt to categorize it, likely resulting in a 'Unrated' category, not a phishing block. Since the scenario indicates a web filter profile configured to block phishing, the failure to block is not due to IP-based access.

The email traffic is not subject to SSL inspection, so URLs in encrypted emails are not filtered.

Why it fails: The correct explanation is that FortiGate web filtering cannot inspect URLs contained within encrypted email traffic unless SSL deep inspection is enabled. When a user accesses webmail over HTTPS (e.g., Gmail, Outlook Web Access), the FortiGate without SSL inspection can only see the destination hostname (e.g., mail.gmail.com) and cannot decrypt the content of the email to extract embedded links. Because the phishing URLs are inside the encrypted email body, the web filter profile never sees those URLs and therefore cannot block them, leaving the users vulnerable.

The FortiGate's URL database is outdated.

Why it fails: An outdated FortiGuard URL database could allow new phishing sites to go uncategorized, but it would not prevent the blocking of known phishing domains that are already in the database. Web filter profiles block entire categories (such as 'Phishing'), and as long as the site is categorized, even an outdated database would match the category and trigger the block. Since the users are accessing phishing sites via URLs embedded in encrypted emails, the FortiGate is not even seeing those URLs to query the database, making an outdated database irrelevant to this specific failure.

Setting the firewall policy action to 'accept' with no inspection.

Why it fails: This would apply to all traffic in the policy, not as a selective exemption.

Using a web filter category exemption.

Why it fails: Web filter categories do not exempt from SSL inspection.

The FortiGate is operating in Transparent mode.

Why it fails: Application Control works in both NAT and Transparent modes.

The application control profile is applied to the outgoing policy, but BitTorrent traffic is incoming.

Why it fails: Application Control is bidirectional; it can inspect traffic in both directions.

The default application signatures do not include BitTorrent.

Why it fails: BitTorrent is included in the default application signatures.

The ssl-ssh-profile is set to 'deep-inspection' but the policy is using flow-based inspection.

Why it fails: While the ssl-ssh-profile is set to deep-inspection, the policy's default inspection mode is flow-based (since 'set inspection-mode proxy' is missing). Flow-based inspection cannot decrypt SSL traffic, so this combination does prevent SSL inspection. However, the question asks for the most likely reason, which is the missing inspection-mode command, not just the mode mismatch.

The source interface is 'wan1' but the traffic is coming from 'internal'.

Why it fails: If the source interface were 'wan1' but traffic came from 'internal', the policy would not match that traffic. The scenario states the shown policy is the only one matching, so a source interface mismatch does not apply here.

The policy has 'set action deny' instead of 'set action accept'.

Why it fails: If the policy had 'set action deny', traffic would be blocked, and SSL inspection would be irrelevant. Since the policy is matching and allowing traffic (SSL inspection is failing but traffic is passing), this option is incorrect.

Set pre-shared key, then remote gateway, then IKE version, then encryption algorithm.

Why it fails: Placing the pre-shared key before the remote gateway is invalid because FortiGate cannot associate a PSK with a destination that has not yet been defined; the key must belong to a specific peer IP/FQDN. Attempting to set the PSK first leaves the authentication material orphaned, and the subsequent gateway entry would overwrite or reject the key as there is no matching tunnel context. The correct workflow requires the peer identity first, then the shared secret, before moving on to IKE version and encryption.

Set remote gateway, then IKE version, then pre-shared key, then encryption algorithm.

Why it fails: Inserting IKE version before the pre-shared key is out of order because the PSK is the actual credential that authenticates the IKE negotiation, and the version chosen does not change that requirement. Without the PSK already in place, the FortiGate has no authenticated basis on which to propose the IKE version, so the Phase 1 settings are incomplete and cannot be used to establish the tunnel. The version should be selected only after the peer and its shared secret are defined; both IKEv1 and IKEv2 use pre-shared keys, so selecting the version first is premature.

Set IKE version, then remote gateway, then pre-shared key, then encryption algorithm.

Why it fails: Starting with IKE version is premature because the choice between IKEv1 and IKEv2 depends on what the remote gateway supports; with no peer defined, there is no way to make a valid version selection. After choosing the version without a remote gateway, adding the gateway later could reveal a mismatch in supported IKE versions, forcing the administrator to redo the configuration. The remote gateway must come first, then the PSK and version can be set in a meaningful order; otherwise the version selection has no context and may cause negotiation failures.

get system status: Enables debugging for a specific application.

Why it fails: This pairing is incorrect because 'get system status' never enables debugging; it only displays static and dynamic system information such as uptime, firmware, and serial number. Enabling debug output for an application is the exclusive role of the 'diagnose debug application' command (followed by 'diagnose debug enable'), which this option mislabels. The error lies in confusing a status query with a debugging function, leading to unexecuted diagnostics if attempted this way.

execute ping: Displays the entire running configuration.

Why it fails: This pairing is incorrect because 'execute ping' sends ICMP traffic to test remote reachability and does not touch configuration data. The command whose function is to display the entire running configuration is 'show full-configuration', not 'execute ping'. Misassigning these would cause an administrator to run a connectivity tool while expecting a config dump, leaving the actual configuration view unfetched.

The application control profile is applied to the wrong firewall policy

Why it fails: If the application control profile were mistakenly bound to a different firewall policy, the policy that actually governs employee traffic would not enforce any application constraints, leaving the application accessible. However, the administrator has already confirmed the correct policy is in use, so the issue is not a binding mismatch. The symptom arises from the profile's internal action setting, not from which policy references it.

The firewall policy has SSL inspection disabled

Why it fails: Disabling SSL inspection would prevent the firewall from decrypting HTTPS sessions, so application control could not inspect payloads inside encrypted tunnels, potentially allowing the application to bypass control. But the application in question is still identified by the FortiGate through other means such as SNI or IP reputation, and the signature matching is functioning. The core problem is that even when the application is recognized, the profile only logs the traffic because of the 'Monitor All' action, so SSL inspection is not the reason for the lack of enforcement.

The application signatures are outdated

Why it fails: Outdated application signatures could cause the FortiGate to miss newer or modified application patterns, meaning the application would not be recognized and thus not blocked. In this scenario, however, the application is indeed detected by the firewall; the logs show it being matched and permitted. The failure is not one of recognition but of action—the profile tells the firewall to monitor the matched traffic rather than drop it.