Refer to the Exhibit Practice Questions

The IPS sensor is blocking the login page due to a false positive.

Why it fails: An IPS sensor inspects for known attack patterns such as SQL injection or cross-site scripting; a standard HTTPS login page is not malicious traffic. Even if a false positive occurred, the exhibit would show the session denied by the IPS sensor log, not an application control banner; the policy configuration references an application control profile, which is what performs deep inspection on application signatures. The issue specifically lies with application control classification, not intrusion prevention.

The firewall policy action is set to 'deny' but the exhibit shows 'accept'.

Why it fails: The exhibit displays an explicit 'Action: ACCEPT' setting in the policy; therefore, the deny hypothesis contradicts the shown configuration. If the action were deny, all matching traffic would be dropped before reaching any profile, but the actual problem is that traffic is allowed yet the web application is being blocked by a security profile. Thus, the issue is not the base policy action.

The HTTPS service is not correctly defined and blocking the traffic.

Why it fails: HTTPS is a built-in predefined service in FortiOS, mapped to TCP port 443, and the policy references it correctly. A misdefined service would cause a port mismatch or the policy not matching at all, but here the session matches the policy and reaches the application control profile. The traffic is being permitted and then classified, so the service definition is not the cause.

The packet will be logged and a session will be created.

Why it fails: A session is not created merely by allowing a packet through an IPS sensor; session establishment is a firewall function, and the IPS sensor is not a firewall. Additionally, no logging action has been configured for this sensor, so the packet will not be logged. The default pass action simply forwards the packet without event generation, session-specific logging, or any security entry in the log.

The packet will be blocked if the signature severity is 'low' or 'high'.

Why it fails: Blocking is never determined solely by a signature's severity classification; the sensor's behavior depends on whether the signature is included in the sensor and has an explicit action such as 'block' or 'reset'. Here, the sensor has entries for only certain signatures, and 'low' severity signatures are not among them, so they are ignored entirely. A 'high' severity signature could also be passed if it is not in the sensor's filter, so severity alone cannot imply blocking.

The packet will be blocked because the sensor is enabled.

Why it fails: Enabling an IPS sensor puts it in the traffic path, but it does not automatically block packets that do not match a signature with an explicit action. The sensor's default operation when no signature matches is to pass the packet, and the mere fact that the sensor is enabled does not change that. Blocking only occurs for traffic that hits a signature with a configured drop or reset action; otherwise, the sensor operates as a pass-through device.

The firewall policies on the hub do not allow traffic between the spoke networks

Why it fails: If the firewall policies on the hub were the root cause, the inter-spoke traffic would be denied consistently, regardless of reboot state, and the hub would log denials. However, the issue here is that the hub cannot route the traffic to the next spoke, which is a forwarding problem, not a policy problem. Firewall policies are a necessary condition for any traffic to be allowed, but without routes, the packet is never even looked up against a policy because it fails the routing lookup.

The spokes have mismatched IKE versions

Why it fails: Mismatched IKE versions between the spokes and the hub would prevent the Phase 1 negotiation from completing, so none of the IPsec tunnels would come up at all. This would cause a total loss of connectivity, including spoke-to-hub traffic, not merely an inter-spoke communication failure after reboot. Since the spokes can still communicate with the hub, the IKE parameters, including version, must be correctly negotiated.

The hub's IPsec Phase1 is not configured for DPD

Why it fails: DPD (Dead Peer Detection) is used to detect whether the remote VPN peer is still reachable, typically by sending liveness probes. Not enabling DPD on the hub does not affect the forwarding plane or the routing table; it only means that dead peers are not detected quickly. A reboot would re-establish the tunnels, and DPD settings are not involved in the routing decision between spokes, so this cannot be the cause of the inter-spoke failure.

The port is set to 443, but HTTPS also uses port 8443.

Why it fails: While HTTPS commonly runs on ports other than 443, such as 8443 in application-specific deployments, the SSL inspection profile's port setting only defines which destination ports are intercepted for TLS inspection. Port 443 is the default and most widely used HTTPS port, and its presence in the profile is correct; the absence of an alternate port does not break inspection or indicate a misconfiguration. The profile can be extended to include additional ports if the environment requires it, but omitting a nonstandard port is not an error and is unrelated to the core issue of untrusted certificate handling.

The 'caname' is set to 'Fortinet_CA_SSL', which is not a valid certificate name.

Why it fails: 'Fortinet_CA_SSL' is the default, valid name of the FortiGate's built-in certificate authority that is automatically generated during initial setup. In the 'caname' field, this reference is legitimate and correctly identifies the CA used to sign certificates for trusted server connections. It is not a typographical error or an invalid certificate name; rather, the problem lies in the separate 'untrusted-caname' field, which governs untrusted server certificates and is the actual root cause of the client-side warnings.

The 'whitelist-mode' is disabled, which prevents inspection.

Why it fails: The 'whitelist-mode' feature in FortiGate SSL inspection profiles is designed to exclude a predefined set of trusted, high-security websites from deep inspection, typically to avoid breaking sensitive services like banking or healthcare portals. Disabling this mode simply means the FortiGate will inspect all HTTPS sessions without those exemptions, which is a common and intended configuration for full visibility and does not prevent inspection at all. In fact, enabling whitelist mode would cause the FortiGate to skip inspection for whitelisted domains, so a disabled whitelist mode is not a fault and is irrelevant to the certificate-trust issue described.

The second route is overwriting the first route

Why it fails: FortiGate does not replace a lower-distance route with a higher-distance route when the destination prefix is identical. The routing table (RIB) can hold multiple static routes to 0.0.0.0/0 as long as their administrative distances differ, and the router selects the one with the lowest distance as the active route. The distance-20 route remains in the RIB as a backup candidate, so it is not overwriting or deleting the distance-10 route.

Both routes are equal-cost and load-balancing is not working

Why it fails: Equal-cost multipath (ECMP) load balancing requires routes to have the same administrative distance and same metric (cost) to the same destination. Here the distances are 10 and 20, so the routes are not equal-cost; only the distance-10 route is installed as the preferred route, and the distance-20 route is a floating static backup. Therefore, failing to see load balancing is not a misconfiguration—it is expected behavior when distances differ.

The configuration is invalid because duplicate default routes are not allowed

Why it fails: FortiGate explicitly allows multiple default routes (0.0.0.0/0) in the configuration, provided they are distinguishable by metrics or administrative distances. Having two default static routes with distances 10 and 20 is a valid design for link redundancy, and the configuration will be accepted by the CLI or GUI. Duplicate default routes are only invalid if they have the exact same distance and metric and the platform does not support ECMP, but FortiGate does support it; thus, this is not the reason traffic is failing.

Site-to-site VPN between each spoke pair manually

Why it fails: Manually configuring site-to-site VPN tunnels between every spoke pair is technically possible, but it is a static, full-mesh approach that requires N*(N-1)/2 separate tunnels for N spokes. This not only fails to adapt to network changes or new spokes, but also multiplies configuration complexity and troubleshooting overhead, making it impractical for any hub-and-spoke topology beyond the smallest deployments. It does not employ any auto-discovery mechanism, so it cannot scale or respond dynamically.

Policy-based VPN with multiple Phase 2 selectors

Why it fails: A policy-based VPN with multiple Phase 2 selectors defines multiple interesting traffic pairs between a fixed set of endpoints, typically a hub and a spoke. It is a static, centrally configured approach that cannot trigger dynamic direct tunnels between spokes; the hub must always relay inter-spoke traffic, and each Phase 2 selector merely specifies which source/destination subnets are protected over an already-established tunnel. This lacks the IKE-based shortcut negotiation that ADVPN uses to create on-demand spoke-to-spoke paths.

SSL VPN tunnel mode

Why it fails: SSL VPN tunnel mode is designed for remote end-user clients (e.g., FortiClient) to securely access internal resources through a single VPN gateway, not for site-to-site connectivity between network appliances. It would require each spoke to act as a VPN client to the hub or to other spokes, which is architecturally incorrect and inefficient, and it does not support dynamic route exchange or automatic tunnel establishment between spokes. Thus, it cannot solve the problem of enabling dynamic direct spoke-to-spoke traffic in a hub-and-spoke VPN.

Monitor

Why it fails: Monitor is a valid anomaly action in FortiGate DoS policies, but it is not the default for flood-type anomalies like ICMP flood. When set to Monitor, the FortiGate logs the anomaly event while still allowing the traffic through, making it suitable for baselining or verifying thresholds before enforcing action. However, because a flood by definition consumes resources, the default action for ICMP flood is Block, not Monitor; Monitor would only record the attack and permit continued resource exhaustion.

Pass

Why it fails: Pass is the opposite of a protective action and is not the default for ICMP flood. Setting the anomaly action to Pass disables any enforcement, so the FortiGate forwards all ICMP traffic without inspecting rate limits, effectively turning off the anomaly detection. While Pass can be used deliberately to exempt certain traffic from DoS checks, it is never the default for flood anomalies because it would leave the network vulnerable to volume-based attacks.

Quarantine

Why it fails: Quarantine is a more advanced anomaly response that can be configured in FortiGate DoS policies, but it is not the default. When Quarantine is set, the FortiGate not only blocks the source but also dynamically adds it to a quarantine list, often coordinated with the Quarantine Controller for extended or automated responses. However, for a basic ICMP flood anomaly, the default action is Block, which provides immediate packet dropping without requiring the additional setup that quarantine involves.

The Allow-HTTP policy uses service HTTP but the traffic uses HTTPS

Why it fails: The Allow-HTTP policy specifying service HTTP is actually correct for this scenario because the traffic in question is HTTP, not HTTPS. FortiOS service objects define both protocol and port, so HTTP (TCP 80) matches the HTTP traffic. If the traffic were HTTPS, this would cause a mismatch, but that contradicts the given premise. Therefore, the service configuration is not the issue.

The Allow-HTTP policy has the wrong source interface

Why it fails: The source interface is the FortiGate ingress interface for the traffic, and the exhibit shows the HTTP traffic arrives on the correct internal interface that is configured as the source of the Allow-HTTP policy. If the source interface were wrong, the policy would not even be considered for matching, but here the traffic does match the source requirement. The actual problem is that an earlier policy denies the traffic before this match can occur.

The Allow-HTTP policy is disabled

Why it fails: A disabled policy in FortiOS appears greyed out and is skipped entirely during policy matching. The exhibit shows the Allow-HTTP policy is enabled with no disabled icon, so it is active and capable of matching traffic. Even if it were disabled, simply enabling it would not resolve the issue because the Deny-All policy still sits above it and would continue to drop the traffic. Hence, the disabled state is not the cause.

Change the interface type to 'management' to allow SNMP.

Why it fails: The interface type in FortiGate is a structural classification (e.g., physical, vlan, loopback, tunnel) and does not act as an access-control switch for SNMP or other management protocols. There is no supported 'management' interface type; even a dedicated management interface still uses the same allowaccess setting to control which services it accepts. Changing the interface type would not add snmp to the allowaccess list, so SNMP requests would remain unanswered on that interface.

Execute 'config system interface' and edit wan1, then set snmp-index 1.

Why it fails: The snmp-index parameter under 'config system interface' defines an arbitrary integer used as the ifIndex in SNMP MIB walks, ensuring a stable identifier for that interface regardless of its order in the system. It is an identification attribute, not an authorization attribute, and it has no bearing on whether SNMP is reachable. Moreover, a snmp-index is typically generated automatically for each interface, so manually setting it adds no functional value for enabling SNMP service.

Configure an SNMP community under 'config system snmp community'.

Why it fails: Creating an SNMP community under 'config system snmp community' defines the authentication credentials, read/write permissions, and allowed manager IPs for SNMPv1/v2c queries, which is a necessary prerequisite for any SNMP communication. However, it is not sufficient: the FortiGate also requires each interface to explicitly include snmp in its allowaccess statement before it will respond on that interface. Without that per-interface permission, the community is configured but silently ignored for wan1 traffic, so SNMP requests will time out.