Security Profiles practice questions

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

Why wrong: 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 wrong: The stem says SSL inspection is enabled, so this option is false.

The DNS server is not resolving the domain names.

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

Antivirus

Why wrong: Antivirus (AV) scanning inspects files and traffic for known malware signatures, heuristics, and sandboxing behavior, but it does not categorize or deny individual URLs or domains. While a blocked URL might coincidentally hide malware, AV is a security control against malicious payloads, not an access control mechanism for web navigation. Its placement in a policy protects against threats, yet it cannot enforce URL-policy decisions.

Intrusion Prevention System (IPS)

Why wrong: IPS detects and blocks network-layer threats by matching packet payloads against vulnerability signatures and behavioral anomalies, such as exploit attempts against web servers. It does not maintain a URL category database nor evaluate the web address a user requests; its focus is on the attack packet content, not the site origin. Thus, an IPS rule cannot be used to deny access to a specific website by name or category.

Application Control

Why wrong: Application Control identifies network traffic by application signatures (e.g., Facebook, Skype) and can allow, deny, or shape bandwidth for those applications, regardless of the underlying URL or domain. It does not parse or classify web addresses into content categories, so it cannot block a specific website like www.example.com unless that site is uniquely tied to a recognized application. Its scope is application identity, not URL classification.

The CA certificate has expired.

Why wrong: An expired CA certificate on the FortiGate would cause every HTTPS site to present an untrusted or expired certificate warning, because the FortiGate signs all inspected certificates with that CA. This scenario is site-specific (the user can access other HTTPS sites), so a global CA expiration cannot be the cause. Moreover, the error described is a handshake/cipher failure, not a certificate validity failure, which would appear as a different browser warning.

The user's browser is outdated.

Why wrong: An outdated browser can cause a variety of TLS compatibility problems, but it would not create a failure specific to the FortiGate's re-encryption to the server. The FortiGate presents its own certificate to the browser, and if the browser is too old to trust the CA, the user would see an untrusted CA error, not a cipher mismatch. Moreover, the issue is likely tied to the server's cipher selection, which the browser has no influence over; the browser is only a passive recipient of the FortiGate's certificate.

The firewall needs a policy to allow DNS traffic.

Why wrong: A missing or restrictive DNS policy would prevent the user's device from resolving the web server's hostname to an IP address, resulting in a 'server not found' or DNS resolution failure before any TCP connection is attempted. Because the user is reaching the server and receiving a certificate/handshake error, DNS resolution has already succeeded. DNS and TLS certificate validation operate at different layers, so a DNS policy cannot cause a cipher-based re-encryption failure.

SSL Offloading

Why wrong: SSL offloading is a load balancer / ADC feature that decrypts inbound HTTPS traffic to offload cryptographic processing from backend servers, then often re-encrypts it before forwarding. It is used primarily for performance and to enable HTTP-based load balancing, not for security inspection. On FortiGate, SSL inspection focuses on inspecting decrypted content for threats, which SSL offloading does not do.

Certificate Inspection

Why wrong: Certificate inspection only validates the server's SSL/TLS certificate (chain, expiry, and trust), and does not decrypt or read the session payload. It can block sessions presenting invalid certificates, but it provides no visibility into encrypted content. Consequently, it cannot detect malware, intrusion attempts, or data leakage inside the encrypted stream.

Flow-based Inspection

Why wrong: Flow-based inspection is a traffic processing mode in FortiOS that uses an asynchronous, single-pass engine to maximize throughput with lower latency, leveraging specialized hardware acceleration. It is not a distinct type of SSL inspection; both flow-based and proxy-based modes can perform certificate or full SSL inspection. Calling it an SSL inspection type conflates the processing architecture with the decryption/inspection function.

Application Control and Antivirus

Why wrong: 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 wrong: 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 wrong: 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.

The firewall policy denies the traffic.

Why wrong: If the firewall policy denied the traffic, the client's connection request would never reach the FortiGate's SSL inspection proxy. Instead, the browser would receive a TCP reset, a 'connection refused' error, or a timeout — not a certificate trust warning. A certificate warning can only appear after the traffic has been permitted by policy and the deep inspection proxy has intercepted the TLS handshake, so a deny action (even implicitly) cannot produce the symptom described.

The FortiGate is not decrypting the traffic.

Why wrong: If the FortiGate were not decrypting the traffic, it would simply pass the encrypted TLS stream through to the destination server. The browser would receive the original server certificate and validate it against its existing trust store, so no FortiGate-related certificate warning would appear. A warning mentioning the FortiGate's CA can only be generated after decryption and re-encryption have occurred, meaning this option describes a state that would prevent the symptom rather than cause it.

The web server's certificate has expired.

Why wrong: With SSL inspection active, the FortiGate presents its own locally generated certificate to the browser, not the original web server certificate. Consequently, the browser checks the validity period of the FortiGate-generated certificate, which typically has a validity of only a few days or weeks, rather than the actual server certificate's expiration date. An expired server certificate would yield a 'certificate expired' error if inspection were disabled, but in this inspected session it is not the direct trigger for the user's trust warning.

A dedicated HTTPS firewall policy.

Why wrong: A dedicated HTTPS firewall policy is not required because SSL deep inspection is simply an action applied to a firewall policy that matches HTTPS traffic. The same policy that allows web access can inspect HTTPS without needing a separate, HTTPS-only rule; the key is that the policy's SSL inspection profile is enabled, not that it exclusively handles HTTPS.

The FortiGate must be operating in proxy mode.

Why wrong: SSL deep inspection does not require the FortiGate to operate in proxy mode; it functions in both flow-based and proxy-based inspection modes. Flow mode uses optimized processing with hardware offloading while still decrypting and inspecting the TLS payload, whereas proxy mode performs full buffering and advanced content analysis. Therefore, the mode is a design choice affecting performance and feature depth, not a prerequisite.

An active FortiCare license.

Why wrong: An active FortiCare license is not needed for SSL deep inspection because it is a core firewall security feature available on all FortiOS models. FortiCare licenses provide support contracts and subscription services like updated threat intelligence for NGFW features, but the decryption and inspection logic itself is built into the FortiOS platform. You can enable SSL inspection on a local policy with no license, though some UTM profiles attached after decryption may require subscriptions.

The DNS server is not resolving the domain.

Why wrong: A DNS resolution failure prevents the browser from ever reaching the server: there is no HTTP request for FortiGate to inspect, so FortiGuard web filtering cannot trigger a block. Instead, the user would see a browser-level 'server not found' or 'DNS cannot resolve' error, which is a connectivity failure, not an HTTP-level content-blocking event. FortiGuard's URL filtering operates after successful DNS resolution and connection establishment, so this option explains a different symptom and is not the cause of a web-filtering block.

The web filter is configured to block all unrated sites.

Why wrong: This is a valid administrative condition that could cause a block, but it is only a contributing factor, not the root cause. The question asks why a legitimate site is blocked, and the fundamental reason is the site's categorization state, not the web-filter policy. A FortiGate policy that blocks all Unrated sites is simply applying the default action for unknown URLs; without the absence of a FortiGuard category, that policy setting would not produce a block. This answer mistakes the policy behavior for the underlying reason, so it fails to explain why the site is unrated in the first place.

The website is in the 'Blocked' category.

Why wrong: FortiGuard uses category names such as 'Malicious Websites', 'Pornography', or 'Gambling' rather than a generic 'Blocked' category; blocking is the action applied to a category, not a category itself. If the site were categorized in a blocked category, the FortiGate's URL filter log and block page would show that specific category name, proving a known, negative classification. Here, the issue is that the site has no category at all and is being treated as 'Unrated', which is a fundamentally different situation from a site that has been reviewed and formally categorized as dangerous.

The firewall policy allows the traffic.

Why wrong: A firewall policy that permits traffic is the fundamental prerequisite for enabling SSL inspection—not a failure condition. Without a permit action, the session would be dropped or rejected outright, so simply allowing traffic cannot introduce a certificate error. Inspection errors arise from cryptographic and trust issues, not from the policy's action field.

The web server's certificate is signed by a public CA.

Why wrong: The remote web server's certificate being issued by a well-known public CA is the expected, standard scenario for HTTPS traffic. During full SSL inspection, the FortiGate terminates the TLS session from the server, validates the public CA signature itself, and then presents a new certificate signed by its own local CA to the client. Thus, a public CA on the server side poses no inherent problem; failures only occur if the FortiGate's own CA is not trusted by the client.

The client browser has the FortiGate CA certificate installed.

Why wrong: Having the FortiGate's CA certificate installed in the client browser is precisely the remediation step that prevents SSL inspection failures. It establishes the FortiGate as a trusted root, so the dynamically generated server certificates chain up to a trusted anchor. This action cannot cause certificate errors; on the contrary, its absence is the leading source of 'untrusted connection' warnings.

Add a static route to the internet.

Why wrong: For SSL deep inspection to work, you don't add a static route as a configuration step; routing is a separate prerequisite for reaching external destinations. Deep inspection occurs after the routing decision, so a route to the internet may be needed for general connectivity but it's not part of the inspection configuration process itself.

Configure a forward proxy server.

Why wrong: A FortiGate performing full SSL inspection already functions as a forward proxy in the data path, intercepting and decrypting client requests on behalf of the client. There is no need to separately configure a forward proxy server, nor does FortiGate need to point to an external proxy for deep inspection to work. This option confuses the built-in proxy capability with a separate component, so it is not a required step.

The deep inspection profile is misconfigured.

Why wrong: No evidence of misconfiguration.

The antivirus profile is blocking the traffic.

Why wrong: Antivirus would not block all HTTPS.

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

Why wrong: The profile would block some, not all.

The SSL VPN certificate has expired.

Why wrong: An expired SSL VPN certificate does produce an SSL/TLS handshake failure, but the client alerts specifically with a 'certificate expired' (or 'not yet valid') error after checking the certificate's validity period, not with an 'unknown CA' or 'untrusted' error. Expiration also appears in FortiGate's dashboard as a certificate state, and the failure occurs during the validity period check within the TLS exchange. Since the reported scenario is an untrusted CA (not an expiration date) problem, a valid but untrusted certificate fails before any expiration concern is even relevant. Thus, an expired certificate cannot be the cause when the observed error is a trust failure.

The user's password is incorrect.

Why wrong: Incorrect user credentials are only verified at the HTTP application layer, after the TLS tunnel is successfully established and the client has accepted the server certificate. With an untrusted CA error, the client never completes the handshake, so it never sends the login form or password, and the user never reaches the authentication page. Password failures typically produce a clear 'Authentication failed' message on the FortiGate login form, not a certificate-trust alert. Therefore, although a wrong password would block user access, it would occur after the certificate validation step and cannot explain a pre-authentication 'untrusted CA' symptom.

The firewall policy is blocking the SSL VPN port.

Why wrong: A firewall policy denying the SSL VPN port would prevent the TCP connection or drop packets, causing a timeout or 'connection refused' error at the network layer before any TLS exchange begins. If the client is able to receive the server's certificate and issue an 'unknown CA' error, then the three-way TCP handshake and initial TLS ServerHello/Certificate messages have already passed through the firewall successfully. Thus, a blocking policy would not produce a certificate trust error; it would simply hang until timeout or return an ICMP unreachable message. The presence of a certificate error actually proves that packet filtering allows the SSL VPN traffic to reach the FortiGate.

The web filter profile is applied globally.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Web Filter

Why wrong: A Web Filter evaluates HTTP and HTTPS requests against URL lists and content categories, such as 'Peer-to-Peer File Sharing' websites. However, P2P applications generate traffic over their own protocols—often on arbitrary ports or with peer-to-peer communication—that never goes through a web proxy. Even if the web filter blocks the download page for the P2P client, the actual file-sharing traffic continues unimpeded, making it ineffective for blocking the application itself.

DNS Filter

Why wrong: DNS Filtering intercepts DNS queries to block resolution of specific domains, but P2P clients are designed to be resilient and often use hard-coded IP addresses, trackers, or a list of peers instead of a single fixed domain. The application can function after a single DNS resolution, or bypass DNS entirely, so blocking the domain name does not stop the P2P data stream. It also cannot inspect payloads or identify application signatures, so it is unsuitable for application-aware blocking.

Intrusion Prevention System (IPS)

Why wrong: An Intrusion Prevention System is purpose-built to detect and prevent network attacks, such as exploit attempts, malware propagation, and vulnerability attacks, not to enforce policy on legitimate application usage. Although some IPS signatures may alert on P2P payloads to stop malicious content, this is incidental and leads to false positives or missed coverage when traffic is encrypted or uses legitimate protocols. Application Control is the correct feature for selectively blocking an entire application category, as it is designed for policy enforcement rather than threat prevention.

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

Why wrong: 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 wrong: 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 wrong: 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.

Use web filtering to block the URL of personal Google Drive.

Why wrong: Web filtering categorizes URLs and domains, but Google Drive Personal and Business share many of the same URLs and infrastructure. This technique cannot inspect application-layer metadata or session tokens to distinguish a personal account from a business account. As a result, a URL-based block would either be circumvented by direct IP access or inadvertently block legitimate business use, so it is not an application-aware control.

Configure IPS to block personal Google Drive traffic.

Why wrong: IPS is designed to detect and prevent known vulnerability exploits and attack patterns, not to identify or control applications. While IPS may inspect payloads for malicious content, it lacks the granular signatures and protocol decoders needed to recognize 'Google Drive Personal' as a distinct application instance. Relying on IPS to block this traffic would fail to provide the required allow/block policy granularity and could generate false positives.

Create a rule to block all Google Drive applications.

Why wrong: Creating a rule to block all Google Drive applications would treat both business and personal usage identically, removing any ability to permit legitimate corporate use of Google Drive Business. This approach is technically valid as a broad blocking measure, but it is not the best answer because it lacks the granularity needed to enforce a policy that distinguishes between work and personal access. Applying signatures individually allows more precise matching, making this catch-all rule an overreaction.

The IPS engine is upgraded to the latest version.

Why wrong: The IPS engine is the runtime code that performs packet inspection and pattern matching, but it is a separate software component from the signature database. Upgrading the engine only improves detection logic or parsing capabilities; it does not install or refresh the actual signatures, which are a distinct feed of threat indicators. Therefore, while keeping the engine current is good practice, this alone does not ensure IPS signatures are updated.

The intrusion prevention profile is applied to the firewall policy.

Why wrong: Applying an intrusion prevention profile to a firewall policy enables the FortiGate to compare traffic against the signatures currently installed on the device, but it triggers no download or fetch of new signature content. The profile references the local signature database, and any updates must occur through a separate administrative process such as a scheduled FortiGuard update. Hence, profile application affects how signatures are used, not how they are updated.

The application control profile is set to 'monitor' for all applications.

Why wrong: Application control is a distinct FortiGate feature that classifies applications using protocol decoders and heuristics, and its 'monitor' action merely logs or allows identified application traffic without blocking it. Neither application control nor its 'monitor' mode has any connection to the IPS vulnerability signature database, which is maintained and distributed through FortiGuard. Thus, configuring an application control profile as 'monitor' does not influence or perform IPS signature updates.

Web filter profile is not applied to the firewall policy.

Why wrong: Web filter profiles in FortiOS control URL access by categorizing domain names and paths, not by identifying the application generating the traffic. Application control is a separate security profile that uses protocol decoders and FortiGuard signatures on the session payload, independent of the web filter. Not applying a web filter profile would only leave URL categorization unmanaged; it would not prevent the firewall from recognizing applications. Therefore, the missing web filter profile is unrelated to the inability to identify certain web-based apps.

Deep packet inspection is not enabled on the firewall policy.

Why wrong: On FortiOS there is no single 'deep packet inspection' toggle; inspection depth is determined by which security profiles are attached to the policy, such as application control, IPS, web filter, and SSL inspection. While application control and IPS both inspect packet payloads, HTTPS traffic cannot be evaluated beyond the initial handshake unless an SSL/SSH inspection profile decrypts it. Saying 'deep packet inspection is not enabled' is imprecise, and even if it were enabled, applications would still be invisible inside TLS without decryption. The real prerequisite for seeing inside HTTPS sessions is SSL inspection, not a generic DPI switch.

IPS is not enabled on the firewall policy.

Why wrong: IPS is designed to detect known attack signatures, protocol anomalies, and exploit attempts by inspecting network, transport, and application payloads. In contrast, application control uses the FortiGuard application identification database and protocol logic to classify which application is in use, and it works independently of the IPS engine. Disabling IPS would only remove intrusion-prevention coverage—it would not prevent the firewall from identifying applications. Consequently, this option misdiagnoses the absence of application classification as an IPS misconfiguration, when the true root cause is missing SSL inspection.

An IPS sensor can only be applied to one firewall policy.

Why wrong: IPS sensors in FortiOS are configuration objects that can be shared across multiple firewall policies simultaneously, so a single sensor is by no means limited to one policy. This object-based reuse is a deliberate design choice to avoid redundant configuration and ensure consistent inspection across traffic flows. An administrator would typically create a few sensors (e.g., 'severity-high' or 'strict-protection') and attach them to numerous policies that need the same level of IPS coverage.

IPS is not supported in transparent mode.

Why wrong: FortiGate IPS does not depend on routing or NAT, so it operates identically in transparent (Layer 2) mode where the device is effectively a bump in the wire. In transparent mode, IPS still inspects every packet forwarded through the interface pair, applying the same sensors, filters, and signature actions as in routed mode. The only practical difference is that some IPS debug commands or network-layer features might be limited, but the inspection engine itself is fully supported.

IPS only works in flow-based inspection mode.

Why wrong: FortiOS supports IPS in both flow-based and proxy-based inspection modes, so the claim that it only works in flow mode is incorrect. Flow mode processes packets as they arrive, offering lower latency and better scalability, while proxy mode reassembles the full stream, enabling deeper application-level inspection and integration with other proxy-based security features like DLP. An IPS sensor can be referenced by policies running either mode, and signature matching is performed by the same underlying engine.