Select Two (Multi-Select) Questions

A firewall policy with IPS enabled

Why it fails: An IPS-enabled firewall policy is where inspection occurs, but it only detects and logs the high-severity event; it does not itself add the source to a blocklist. The automatic blocking requires a separate automation stitch or action. A policy with IPS is the right answer when the goal is merely detection and logging.

A FortiGuard category subscription

Why it fails: A FortiGuard category subscription provides web-filtering and IPS signature updates; it plays no role in dynamically banning a source address. Automatic blocking depends on an automation stitch triggered by the IPS log, not on subscription licensing. The subscription would be the correct component if the requirement were keeping signature databases current.

A static route to the source IP

Why it fails: A static route merely dictates the path packets take toward the source IP; it cannot deny traffic. Automatic blocking needs an automation stitch that adds the address to a quarantine or blocklist. A static route would be the right configuration when the requirement is reachability to a specific network, not enforcement.

Shortcut tunnels are always established between all spokes at initial VPN bring-up, regardless of traffic patterns.

Why it fails: ADVPN shortcut tunnels are established on demand, not at initial bring-up. The hub and spokes first form a hub-and-spoke topology. Shortcut tunnels are only created when the hub detects traffic that could benefit from a direct path and sends a shortcut offer. Establishing all possible spoke-to-spoke tunnels at bring-up would not scale and would waste resources, which is contrary to the ADVPN design.

Shortcut tunnels can only be established between spokes that are in the same IP subnet.

Why it fails: ADVPN shortcut tunnels can be established between spokes regardless of their IP subnets. The spokes typically use different protected subnets, and the shortcut tunnel carries traffic between those subnets. The requirement is that the spokes can reach each other's public IP addresses and that routing and firewall policies permit the traffic. Subnet sameness is not a requirement for shortcut establishment.

Shortcut tunnels require the hub to be removed from the routing path permanently once established.

Why it fails: The hub remains part of the topology even after shortcut tunnels are established. The hub is still used for control plane functions, such as sending shortcut offers and maintaining the hub-and-spoke overlay. If a shortcut is torn down, traffic reverts to the hub path. The hub is not permanently removed from the routing path; it continues to serve as a fallback and for management.

The IPS sensor is configured in 'Inline' mode

Why it fails: Inline mode allows blocking, not a reason for no detection.

The IPS sensor has 'Logging' disabled

Why it fails: Logging disabled still allows detection, just no logs.

The FortiGate is operating in 'Transparent' mode

Why it fails: Transparent mode still performs IPS inspection.

A dedicated VDOM

Why it fails: A VDOM is a separate virtual firewall instance, not a per-VRF requirement; VRFs are Layer 3 routing table separation within one VDOM. Each VRF needs a unique route distinguisher and route target for BGP import/export, plus interface assignment, so a dedicated VDOM is unnecessary.

Route leaking configuration

Why it fails: Route leaking is optional, used only when VRFs must exchange selected routes; it is not a mandatory per-VRF component. It is tempting because leaking is commonly configured alongside VRFs in multi-tenant designs, but the required components are the interface and the virtual router, so this fails the scenario.

A separate firewall policy for each VRF

Why it fails: Firewall policies are not a per-VRF configuration component; VRFs require an interface assignment and a route table (plus route leaking where needed). It is tempting because traffic separation between departments sounds like a policy task, but policy enforcement is separate from VRF instantiation, so this fails the requirement.

Anti-spam Bayesian filtering

Why it fails: Bayesian filtering scores message content statistically for spam likelihood; it does not authenticate the sending domain, so spoofed mail can still pass. It is tempting because it is a core FortiMail anti-spam control, and would be correct for filtering unsolicited bulk mail rather than verifying SPF, DKIM or DMARC authentication results.

TLS encryption for inbound/outbound

Why it fails: TLS encrypts transport, but does not authenticate sender.

Mismatched HA group IDs

Why it fails: Differing HA group IDs stop the devices recognising each other as cluster peers, so the cluster never establishes and no synchronisation occurs at all. Group ID matching is the right check when building a new cluster or when members show as standalone, not for intermittent sync faults.

Incorrect BGP route advertisements

Why it fails: BGP route advertisements affect Layer 3 reachability and path selection, not the HA session-sync channel, which uses the dedicated HA heartbeat and sync interfaces. Verifying BGP is correct when failover succeeds but traffic takes a suboptimal path afterwards.

Mismatched HA passwords

Why it fails: Mismatched HA passwords prevent the cluster from forming or cause members to leave the group entirely, which surfaces as HA status errors rather than selective session-sync failures. Password alignment is the correct check when a FortiGate cannot join an HA cluster at all.

A report schedule

Why it fails: A report schedule generates periodic PDF or email reports and has no role in playbook execution. Playbooks require a trigger, an action or task, and connectors or a fabric device to act on; scheduling belongs to reporting workflows, not automated incident response.

A dashboard visualization

Why it fails: A dashboard visualisation only displays collected data and cannot trigger or execute playbook tasks. Playbooks need a trigger, an action, and connectors or fabric devices. Dashboards serve monitoring and reporting, which is a separate FortiAnalyzer function from automated response.

Enable NAT on the VDOM link interface

Why it fails: NAT is not required for inter-VDOM routing; the VDOM link forwards traffic between the two routing domains without address translation. It is tempting because NAT commonly accompanies routed traffic, but it is needed only when hiding addresses, not for VDOM-A hosts to reach VDOM-B servers directly.

Disable ARP on the VDOM link interfaces

Why it fails: ARP operates normally on VDOM link interfaces; disabling it prevents the peer interface from resolving link-layer addresses, breaking forwarding. It is tempting as a security hardening step, but ARP must remain enabled for the two VDOM link ends to exchange traffic across the link.

The management VDOM cannot have firewall policies

Why it fails: A management VDOM can hold firewall policies, including policies permitting administrative access to the FortiGate. Policies are restricted only when the VDOM is in management-only mode with no data-plane interfaces. The genuine constraints concern interface and traffic handling, not policy creation itself.

The management VDOM requires a separate license

Why it fails: Management VDOMs are a built-in administrative construct available on any multi-VDOM FortiGate; no additional licence is required to create or run one. It is tempting because separate licensing does apply to other FortiGate features, such as FortiGuard services or virtual machine capacity, so administrators may assume a management VDOM follows the same model.

All user traffic must pass through the management VDOM

Why it fails: User traffic is not required to traverse the management VDOM; it carries administrative and management-plane traffic, while data-plane traffic is handled by the other VDOMs. It is tempting because the management VDOM can host management-access interfaces, which administrators may wrongly assume must also carry production user traffic.

Use the same physical interface in multiple VDOMs directly

Why it fails: A physical interface can belong to only one VDOM; assigning it directly to several is rejected by the FortiGate configuration. It tempts administrators because interfaces are the natural building block of VDOM segmentation, and a single interface does serve one VDOM entirely — the limitation is that sharing requires a VLAN subinterface or virtual switch layer above it.

Create a software switch interface and assign it to multiple VDOMs

Why it fails: A software switch binds its member interfaces to one VDOM, so it cannot be placed in multiple VDOMs simultaneously. It tempts because software switches do let several physical ports share one broadcast domain, which is the correct tool when the goal is aggregating ports inside a single VDOM rather than spanning VDOMs.

Configure inter-VDOM routing to share the same IP subnet

Why it fails: Inter-VDOM routing forwards traffic between VDOMs and cannot place one interface in several VDOMs or share a subnet across them. It tempts because inter-VDOM links are the standard mechanism for connecting VDOMs, and they are correct when separate VDOMs must exchange traffic while each retains its own distinct interfaces.

Inter-VDOM routing must be enabled

Why it fails: Not a prerequisite for management.

FortiAnalyzer must be registered with FortiManager

Why it fails: FortiAnalyzer is separate; not required for VDOM management.

All VDOMs must be in the same ADOM

Why it fails: VDOMs can be in different ADOMs if needed.

Reboot the FortiGate

Why it fails: Rebooting does not reconcile a policy that FortiManager reports as installed but the FortiGate has not applied; the discrepancy lies in installation target, revision, or policy package assignment. It is tempting because reboots clear transient daemon faults, which is the right step when a FortiGate is unresponsive rather than when a specific policy is missing.

Review the FortiGate's routing table

Why it fails: Routing determines whether traffic reaches the FortiGate, not whether an installed policy matches it; a policy that never sees matching traffic is a policy-lookup or installation-scope problem. It is tempting because routing is the first check for traffic that never arrives, which is the correct scenario when sessions fail before policy evaluation.

Verify the FortiGate's HA status

Why it fails: HA status affects which unit holds the primary role and synchronises configuration, but a policy installed to the managed FortiGate is present regardless of HA state; the failure is in policy installation scope or matching. It is tempting because HA failover can revert configuration, which is the right check when a policy disappears after a cluster event.

The pre-shared key is incorrect

Why it fails: PSK mismatch causes Phase 1 authentication failure, not Phase 2 proposal mismatch.

The firewall policy does not allow UDP port 500

Why it fails: This would affect Phase 1 negotiation, not Phase 2.

The IKE version (IKEv1 vs IKEv2) is different

Why it fails: IKE version mismatch prevents Phase 1 from completing, not Phase 2.

One unit has a higher priority

Why it fails: Priority determines which unit becomes primary, not whether heartbeats are exchanged; split-brain arises from lost heartbeat links or monitor failures, so unequal priority merely decides the winner once both units are already active. Priority is genuinely configured to control primary election in a healthy cluster.

Firmware version mismatch

Why it fails: Firmware version mismatch between cluster members prevents proper HA state synchronisation but does not itself cause both nodes to claim active status simultaneously. Version consistency is required for supported clustering, yet split-brain stems from heartbeat or connectivity failures, not image differences.

Session pickup is disabled

Why it fails: Session pickup governs whether TCP sessions survive failover to the new primary; it has no role in detecting peer availability, so disabling it cannot partition the cluster. It is correctly configured when uninterrupted session continuity across a failover is required.

FortiAnalyzer log query

Why it fails: Automation stitches trigger on local FortiGate event logs, so an external FortiAnalyzer log query is not a valid trigger here. It tempts because FortiAnalyzer is the central log repository, and querying it would be right when correlating events across multiple devices rather than reacting to one firewall's IPS log.

Action: 'Email Notification'

Why it fails: Email Notification only reports the event to an administrator; it performs no address blocking, so the SSH brute-force source stays permitted. It tempts because notification actions are common in stitches, and this would be correct when the requirement is alerting staff rather than automatically denying the offending IP.

FortiGuard category

Why it fails: FortiGuard categories classify web-filter and DNS traffic, not IPS signature events, so they cannot trigger on an SSH brute-force signature. It tempts because FortiGuard feeds drive many blocking policies, and this would be correct when the trigger is a category lookup rather than an IPS log.

FortiMail

Why it fails: FortiMail is email security but not a primary ATP solution.

FortiWeb

Why it fails: FortiWeb protects web applications but is not core to general ATP.

Enable TLS encryption for incoming SMTP

Why it fails: TLS encryption for incoming SMTP secures the transmission channel between mail servers but does not perform any authentication of the sender’s identity via SPF, DKIM, or DMARC, nor does it trigger quarantine actions for failing those checks. It is tempting because encrypting SMTP traffic is a common security practice for protecting email content in transit, and in a scenario requiring confidentiality and integrity of message delivery, enabling TLS would be the correct choice.

Configure a recipient verification policy

Why it fails: Recipient verification is separate from authentication.

Destination IP address

Why it fails: Already known (malicious IP); not needed to identify the user.

Event type (e.g., traffic, event, attack)

Why it fails: Event type is not directly useful for identifying the user.

Playbook

Why it fails: FortiManager playbooks are a distinct orchestration feature for multi-step workflows across devices; automation stitches instead require a trigger and a response action, so a playbook is not a stitch component. It is tempting because both automate FortiGate responses, but playbooks orchestrate sequences, whereas a stitch is a single trigger-action pair.

Destination

Why it fails: A stitch's action specifies what runs — CLI script, webhook, email or quarantine — and its target is the device or group executing it; a bare destination is not a stitch component. It is tempting because forwarding events to an external system needs an address, but that address is configured inside the action, not as a separate stitch element.

Schedule

Why it fails: An automation stitch pairs a trigger with an action; a schedule is a separate FortiGate object used for recurring tasks such as script execution or reports, and cannot initiate a stitch. It is tempting because scheduled automation exists elsewhere in FortiOS, but stitch triggering here comes from the IPS event itself, not a timer.

Terminate IPsec VPN tunnels on the FortiManager

Why it fails: VPN termination is done on FortiGate.

Configure FortiGate to manage the FortiManager

Why it fails: FortiManager manages FortiGate, not the reverse.