Hard Difficulty Questions

BGP Multipath relaxing with maximum-paths set to 32

Why it fails: Multipath with maximum-paths 32 only permits installing several equal-cost next hops into the routing table; it does not alter which prefixes the hub relays to spokes. The scenario needs route propagation control, such as a route reflector or route-map/community filtering, so spokes do not receive peer subnets via the hub before a shortcut exists.

Static default route redistribution with aggregate-address suppression

Why it fails: Redistributing a static default and suppressing aggregates changes what the hub originates, not how learned spoke prefixes are reflected between iBGP peers. Preventing spoke-to-spoke learning through the hub requires route reflection or outbound route-map filtering on the hub, which static redistribution cannot achieve.

BGP Confederation with each spoke acting as a separate autonomous system

Why it fails: Confederations partition a single autonomous system into sub-ASs to reduce iBGP full-mesh requirements; they do not stop the hub relaying one spoke's prefix to another. The scenario needs route reflection or route-map filtering controlling which prefixes the hub advertises to each spoke, independent of AS structure.

Simple ICMP packets

Why it fails: Simple ICMP packets are exactly the kind of stateless, easily parsed traffic the NP6 offloads in hardware, so they are not excluded. It is tempting to assume anything simple bypasses acceleration, but the NP6 handles basic session types; exceptions are traffic needing CPU-level inspection, such as certain encrypted or proxy-bound flows.

Standard UDP traffic

Why it fails: Standard UDP traffic is stateless and connectionless, so the NP6 can offload it directly without maintaining session state — it is precisely the kind of flow the processor accelerates. Traffic that cannot be offloaded includes protocols requiring deep inspection or stateful proxy handling, such as SMB or certain VoIP signalling, where the CPU must intervene.

The firmware version of the FortiGate

Why it fails: Performance SLA logic evaluates probe results against configured thresholds; FortiOS version affects available options but not the SLA calculation itself. It is tempting because firmware determines feature support, and it would matter when checking whether a given SLA setting can be configured on that device.

The number of active VPN tunnels

Why it fails: SLA logic compares probe latency, jitter and packet loss against thresholds; the count of active VPN tunnels is irrelevant to that evaluation. It is tempting because tunnels carry the probes, but their quantity does not alter how results are measured or whether a member passes.

To eliminate the need for logs

Why it fails: Centralised policy does not affect logging; logs are configured separately per firewall policy or via FortiAnalyzer. It is tempting because centralised management consolidates configuration, but the actual benefit is consistent SD-WAN rule deployment across many FortiGates, not log elimination.

To reduce the CPU load on the FortiGate

Why it fails: Centralised policy does not offload FortiGate CPU; policies are still evaluated locally on each device. It is tempting because FortiManager centralises configuration, but the real gain is uniform SD-WAN rule rollout across many FortiGates, not reduced processing load.

To allow local admins to override global policies

Why it fails: Local admins cannot override global policies through a Centralized Policy; FortiManager pushes it read-only to managed FortiGates, and per-device overrides require separate local policy configuration. It is tempting because delegated administration is a genuine FortiManager feature, but that is achieved through ADOMs and workspace modes, not Centralized Policy, which exists to enforce uniform configuration across many devices.

Traffic is dropped.

Why it fails: Priority strategy fails over to the next-highest member when the top member breaches its SLA, so traffic continues rather than being discarded. Dropping is tempting because a member marked dead is removed from selection, but that removal triggers failover, not a blackhole; dropping would only occur with no viable member left.

The FortiGate enters an error state.

Why it fails: SLA failure on the highest-priority member simply marks it ineligible and promotes the next member; the FortiGate keeps forwarding and logs the event. An error state is tempting because SLA health checks can raise alerts, but those are monitoring notifications, not a device fault that halts SD-WAN processing.

Traffic is load balanced across all remaining members.

Why it fails: Priority strategy selects one member at a time, so it fails over to the single next-highest member rather than spreading sessions across all survivors. Load balancing is tempting because it is exactly what the Lowest Cost (SLA) and Maximise Bandwidth strategies do, but Priority deliberately avoids per-session distribution.

Flow-based inspection

Why it fails: Flow-based inspection is a processing mode that examines packets as they stream through the FortiGate; it does not move SSL decryption work onto dedicated hardware. It is tempting because flow-based mode reduces CPU load generally, and would be the right answer if the question asked how to lower inspection overhead rather than offload SSL processing.

IPS engine offloading

Why it fails: IPS engine offloading shifts intrusion-prevention pattern matching onto CP processors, leaving SSL/TLS decryption and re-encryption on the main CPU. It is tempting because both features use the same acceleration hardware, and would be correct if the requirement were to offload IPS inspection rather than SSL inspection.

NP6 offloading

Why it fails: NP handles network throughput/L3/L4.

Schedule

Why it fails: Changing a schedule alters when the policy is active but does not tear down established sessions; existing connections continue until they idle out or the policy is otherwise changed. Session flush is triggered by edits to the policy's matching or action criteria, such as services or source/destination.

Comments field

Why it fails: Comments are metadata only and are not part of the policy's match or action logic, so editing them leaves the session table untouched. Session flush occurs when fields that determine policy lookup or forwarding change; comments are documentation, useful for auditing but never affecting traffic handling.

Policy Name

Why it fails: The policy name is an administrative label used for identification and logging; it is not evaluated during session lookup, so renaming it does not flush sessions. Flush is caused by changes to matching criteria or actions, not by renaming, which is useful for clarity but functionally inert.

Performing a hard factory reset on the FortiGate

Why it fails: A hard factory reset erases configuration and returns the FortiGate to default settings, which does not provision SD-WAN templates or push policy from FortiManager. It is tempting because resets are used when onboarding devices with conflicting or unknown configurations, but SD-WAN deployment instead requires authorising the device, installing the SD-WAN template, and assigning it to the managed FortiGate.

Deleting all existing firewall policies

Why it fails: Deleting existing firewall policies is unnecessary; SD-WAN deployment requires creating a new policy referencing the SD-WAN zone, not removing current rules. It is tempting because policy cleanup is sometimes advised before major changes, and it would be correct when consolidating redundant or conflicting rules during a broader firewall migration.

Access Control Lists (ACLs)

Why it fails: ACLs filter traffic by source and destination IP addresses, ports and protocols at the network layer; they cannot grant a named administrator read-only visibility of logs and reports inside FortiManager. They are tempting because they genuinely restrict access, but that restriction applies to packets traversing an interface, not to administrative permissions.

ADOM Assignment

Why it fails: An ADOM assignment scopes which managed devices, policies and objects an administrator can work with; it does not limit the administrator to viewing logs and reports. Restricting that read-only access requires a profile with the relevant permissions. ADOMs are tempting because they are the standard way to partition FortiManager management domains.

User Groups

Why it fails: User Groups bundle administrators for policy targeting; they do not define what a member may see. The stem requires read-only scope over logs and reports, which is set through the administrator's profile and its permissions. Groups are tempting because they are the usual way to organise accounts, but they grant no view restriction.

IPsec VPN phase 2 selectors must be set to 0.0.0.0/0 for service-based rules to evaluate

Why it fails: Phase 2 selectors govern which subnets traverse the IPsec tunnel, not whether an SD-WAN rule evaluates service objects. The rule is skipped because the firewall policy lacks the SD-WAN rule's service object in its matching criteria, so traffic falls through to the static route. Narrow selectors are tempting when tunnels drop traffic, but that is a routing issue.

The firewall policy containing the traffic has SSL inspection disabled, preventing service-based identification

Why it fails: SSL inspection decrypts traffic for application control and threat inspection; it is not required for SD-WAN service objects such as HTTPS, which match on port and protocol. The rule is bypassed because the firewall policy does not reference the SD-WAN rule's service object, so the static route wins. SSL inspection would matter for application-based rules.

The FortiGate kernel requires hardware acceleration (NP7) to be disabled for service-based SD-WAN rules to function

Why it fails: NP7 offload is unrelated to SD-WAN rule evaluation; service-based rules function with hardware acceleration enabled. The rule fails because the firewall policy does not include the SD-WAN rule's service object, so matching traffic takes the default static route. Disabling acceleration is tempting when offload interferes with inspection, but not here.

Traffic shaping on routers

Why it fails: Traffic shaping on routers belongs to standard FortiGate interface and shaper configuration, not to the Enterprise Firewall workflow's centralised management scope. That workflow targets policy packages, ADOMs and installation targets. It tempts administrators who conflate router-level QoS with firewall policy orchestration, but the workflow does not manage router shaping.

Web filter database updates

Why it fails: Web filter database updates are handled by FortiGuard services on the FortiGate itself, not by the Enterprise Firewall management workflow. That workflow centres on policy packages, provisioning templates and installation targets. It tempts administrators who associate all security profiles with centralised management, yet database distribution is a FortiGuard function, independent of workflow.

get system hardware status

Why it fails: This shows hardware health, not process CPU.

diagnose sniffer packet

Why it fails: This is for debugging traffic, not system performance.

get router info memory

Why it fails: This is for memory usage, not CPU usage.

get hardware npu np6

Why it fails: This displays NP6 hardware statistics and session counts per processor, not per-session offload flags. It is tempting because it confirms the NP6 subsystem is running, which is useful when checking whether acceleration is enabled globally, but it cannot identify whether one specific session bypassed the NPU.

get system performance status

Why it fails: This provides global CPU/RAM status.

diagnose npu np6 status

Why it fails: This shows general NPU status, not session-specific offload status.

All sessions

Why it fails: Only those without specific policy settings.

Only TCP sessions

Why it fails: It applies to UDP and others as well.

Only existing sessions

Why it fails: Existing sessions use their original TTL.

Weight replaces the need for SD-WAN SLA rules by performing layer 7 packet inspection

Why it fails: Weight is a local BGP path-selection attribute that biases route preference; it performs no layer 7 inspection and does not replace SD-WAN SLA rules, which probe latency, jitter and packet loss. It tempts because weight does influence which path FortiOS prefers, but that is BGP best-path selection, not application-aware SLA steering.

Weight automatically adjusts the SD-WAN health check probe frequency based on route stability

Why it fails: Weight only influences BGP best-path selection on the local router; it has no mechanism to alter SD-WAN health check probe intervals, which are configured under the performance SLA settings. It tempts because both features concern path selection and link quality, so weight appears related to health checking, though they operate independently.

Weight is propagated to all iBGP peers, ensuring cluster-wide path synchronization

Why it fails: Weight is a Cisco-style attribute local to the router and is never carried in BGP updates to iBGP peers, so no cluster-wide synchronisation occurs. It tempts because other attributes such as local preference are propagated within an autonomous system, making weight seem similarly shared, but it is confined to the receiving device.

Automated patch management

Why it fails: FortiManager has no automated patch management feature; firmware is deployed through the Firmware Upgrade task, which stages images and supports per-device rollback. Patch management describes endpoint tools, correct when remediating OS vulnerabilities rather than upgrading FortiOS images.

Manual script pushing

Why it fails: Manual script pushing executes CLI commands but provides no firmware image staging, reboot orchestration or rollback. Scripts suit bulk configuration changes; the Firmware Upgrade task is correct when upgrading FortiOS across many devices with per-device rollback.

Global Policy upgrade task

Why it fails: Global Policy governs firewall policy packages across ADOMs; it does not distribute firmware images. The Firmware Upgrade task performs staged image deployment with rollback, and is correct whenever FortiOS versions must be changed across managed FortiGates.

Configure a distribute-list in the OSPF process

Why it fails: A distribute-list filters routes already present in the OSPF database in inbound or outbound directions; it cannot constrain which connected subnets redistribution injects. It is the right tool for filtering prefixes received from a neighbour or suppressing specific LSAs leaving an area.

Use an IP prefix list under the OSPF area command

Why it fails: Prefix lists attach to redistribution or route-map statements, not to the OSPF area command, which governs area type, authentication and stub settings. A prefix list is correctly used as the match condition inside a route-map applied to the redistribute connected statement.

Use an access list under the interface configuration

Why it fails: Access lists on a FortiGate interface control administrative access protocols such as HTTPS, SSH and ping; they do not filter routing updates. An access list would be the correct mechanism when restricting which management services may reach an interface.

TCP port selection

Why it fails: IKE uses UDP 500/4500.

Firewall policy ID

Why it fails: The firewall policy ID is a local FortiGate configuration value that selects which policy permits the tunnel; it is never carried in IKEv2 payloads or negotiated with the peer. It is tempting because policies reference the tunnel, but Phase 1 negotiates encryption, authentication, and DH group parameters instead.

SLA target name.

Why it fails: An SLA target names a measured performance threshold used to steer or select members, not a traffic origin. SLA targets appear as the health-check condition within an SD-WAN rule, defining which links qualify rather than which sources match.

Interface MAC address.

Why it fails: SD-WAN rules match sources by IP address, user, or geography, not by interface MAC address, which is a Layer 2 attribute invisible to policy matching. MAC-based criteria belong to Layer 2 switching or device-identity features.

Firewall policy ID.

Why it fails: A firewall policy ID identifies the rule performing the match, not the traffic origin, so it cannot serve as a source criterion. Policy IDs are referenced for logging, ordering, and diagnostics rather than SD-WAN rule source selection.

To force the use of a secondary ISP.

Why it fails: The Gateway override sets a next-hop IP for the member, used when the interface cannot resolve one via DHCP or when the ISP gateway differs from the subnet default. Forcing a secondary ISP is tempting, but member selection and failover are governed by SD-WAN rules and SLA health checks, not this field.

To bypass the firewall policy.

Why it fails: The Gateway override only supplies a next-hop address for the SD-WAN member; policy enforcement remains with firewall policies and their inspection profiles. Bypassing the firewall is tempting because next-hop manipulation sounds like routing around controls, yet no SD-WAN member setting can skip policy lookup.

To enable load balancing.

Why it fails: The Gateway override defines the member's next-hop address; load distribution is decided by the SD-WAN rule's strategy and health-check results. Enabling load balancing is tempting because both settings live in SD-WAN configuration, but the override changes only where packets are sent, not how members are chosen.