Hard Difficulty Questions

The remote peer is rekeying the VPN tunnel

Why it fails: Rekeying is negotiated with CREATE_CHILD_SA exchanges within the existing IKE security association, whereas INITIAL_CONTACT signals a fresh phase 1 with no prior state. It is tempting because rekey failures do cause tunnels to drop, and it would be correct if the log showed rekey or CREATE_CHILD_SA messages rather than a new initial exchange.

The local FortiGate has a mismatched pre-shared key

Why it fails: A mismatched pre-shared key causes IKE phase 1 to fail outright, so the tunnel never establishes; repeated INITIAL_CONTACT instead shows the peer re-establishing an existing security association. It is tempting because key mismatch is a common cause of flapping tunnels, and it would be correct if the log showed NO_PROPOSAL_CHOSEN or authentication failures.

A dead peer detection timeout occurred

Why it fails: Dead peer detection produces DPD timeout or retransmission entries in the IKE log, not INITIAL_CONTACT, which the peer sends when it believes no prior IKE session exists. It is tempting because DPD commonly explains flapping tunnels, and it would be correct where the log shows DPD timeouts against an otherwise established phase 1.

The Fabric Root serial number is incorrect

Why it fails: The Fabric Root serial identifies the root FortiGate for topology and Fabric object sharing; it does not authenticate the FortiManager management tunnel. An incorrect root serial breaks Fabric synchronisation, but policy installation depends on FortiManager registration and the central management configuration.

The FortiGate is not registered with FortiManager

Why it fails: The exhibit already shows the FortiGate registered with FortiManager, so registration is not the cause; the failure lies elsewhere, such as policy package assignment or the installation target. Registration is the prerequisite checked when a device has never appeared in FortiManager at all.

The Security Fabric is not fully connected

Why it fails: A broken Security Fabric connection would block Fabric telemetry and dynamic address sharing, not FortiManager policy installation, which runs over the management tunnel independently. Fabric connectivity matters when the FortiGate must resolve Fabric connectors or share objects with other Fabric members.

ZTNA tagging with a dynamic firewall address

Why it fails: ZTNA tagging uses FortiClient EMS tags to dynamically populate firewall addresses based on endpoint compliance. It does not validate client certificates presented during the TLS handshake. While tagging can enforce compliance, it relies on the EMS agent reporting, not on the presence of a specific certificate in the user's certificate store. This would not satisfy the requirement to check for a valid certificate.

FortiClient EMS compliance rule with certificate check

Why it fails: FortiClient EMS compliance rules can check for the presence of certificates on the endpoint, but they do not validate the certificate during the ZTNA connection. The EMS check is performed by the FortiClient agent and reported to the FortiGate, which is separate from the TLS handshake. An attacker could bypass the check by spoofing the EMS report, whereas client certificate authentication provides cryptographic proof.

SSL VPN with certificate authentication

Why it fails: SSL VPN with certificate authentication is used for remote access VPN, not for ZTNA proxy rules. While it can enforce client certificates, it does not apply to ZTNA traffic to web applications. The scenario specifically mentions a ZTNA rule with a proxy-based policy, so SSL VPN configuration is irrelevant and would not enforce the requirement for ZTNA access.

DPD is not configured on the hub

Why it fails: DPD is for dead peer detection, not directly related to shortcut establishment.

The spoke's phase2 proposal does not match the hub's proposal

Why it fails: If IPsec SA is UP, the phase2 proposals match. So this is not the cause.

The spoke is using a different IKE version than the hub

Why it fails: If IKE SA is established, the IKE version matches.

The HA cluster is in active-active mode, causing routing loops for the Finance VDOM.

Why it fails: The cluster is active-passive, so active-active mode is not applicable.

The heartbeat interface is oversubscribed, causing intermittent HA synchronization failures.

Why it fails: Heartbeat oversubscription would cause HA status changes and failover events logged, which are not present.

The 'set ha-mgmt-status enable' command is configured on the passive unit, preventing route synchronization.

Why it fails: Management status only affects administrative access, not data traffic or route synchronization.

FortiView dashboard

Why it fails: FortiView is a monitoring tool, not a component of automation stitches.

ADOM

Why it fails: ADOM is a management container, not a component of an automation stitch.

The session is a UDP DNS request

Why it fails: proto=6 is TCP, whereas DNS uses UDP (proto=17), and dport 443 is HTTPS, not DNS port 53. UDP DNS is tempting because diagnose session filters commonly inspect DNS traffic, and would be correct if the output showed proto=17 with dport 53.

The session is being blocked by a firewall policy

Why it fails: proto=6 denotes TCP, and proto_state=01 with a full expire countdown indicates an established, permitted session, not a blocked one. Firewall-policy blocking is tempting because it also concerns session state, and would be correct if the session showed no reply direction or a deny state.

The session is an SSL VPN tunnel

Why it fails: proto_state=01 with duration and expire values describes an ordinary established TCP session on port 443, not a tunnel interface. SSL VPN is tempting because it also uses port 443, and would be correct if the output referenced a tunnel or VPN session table entry rather than a plain session.

The spoke's phase2 proposal includes a different encryption algorithm than the hub

Why it fails: Phase2 mismatch would affect the tunnel establishment itself, not specifically shortcut tunnel negotiation.

The hub does not have a route to the spoke's local subnets

Why it fails: The hub needs routes to all spoke subnets, but missing routes would not prevent shortcut negotiation between spokes directly.

The spoke's VPN interface is not in the same VDOM as the hub

Why it fails: VDOM mismatch would prevent any VPN connectivity; this is a more fundamental issue.

The 'redistribute static' command needs a route map to filter the route correctly.

Why it fails: A route map is optional for redistribution; without one, all static routes are redistributed. The route already appears in the OSPF database, so filtering is not blocking it. A route map would be correct when you need to control which specific routes are redistributed or set metrics and tags.

The static route's administrative distance is too high for OSPF.

Why it fails: Administrative distance governs which route a router prefers locally; it does not stop OSPF from redistributing a static route into the OSPF database. The route already appears there, so distance is irrelevant. Distance would matter when choosing between competing routes to the same prefix.

OSPF must be configured with 'default-information originate' to allow redistribution.

Why it fails: 'Default-information originate' injects a default route (0.0.0.0/0) into OSPF; it does not govern redistribution of ordinary static routes such as 192.168.100.0/24. It would be correct when you want OSPF neighbours to learn a default route from this FortiGate.

The anomaly detection is disabled

Why it fails: Anomaly detection is demonstrably running, since it produced type=SQLi entries with scores; disabled detection would generate no such log lines. It is tempting because a zero value can suggest inactivity, but the score quantifies confidence in a match, not whether the engine itself is enabled.

The IPS sensor is not applied to any policy

Why it fails: The score field reflects the anomaly engine's confidence in the matched signature, not whether the sensor is bound to a policy; an unapplied sensor produces no anomaly log entries at all. It is tempting because sensor-to-policy binding is a common cause of missing IPS enforcement, but that would suppress logging entirely rather than yield zero-scored matches.

The traffic is definitely an SQL injection attack

Why it fails: A score of 0 means the anomaly engine recorded the SQLi signature match but assigned no confidence, so the traffic is not confirmed as an attack. It is tempting because 'type=SQLi' names the signature category, yet the score field is precisely what distinguishes a benign pattern match from a genuine detection.

ECMP is not enabled globally under config system settings.

Why it fails: ECMP is enabled by default; disabling it would cause this.

The firewall policy is configured to use a specific egress interface.

Why it fails: Policy can override routing, but typically routing decides.

The traffic is session-based and ECMP uses per-packet load balancing.

Why it fails: FortiGate ECMP is per-session by default.

The weight values are not in the range 1-100

Why it fails: Weight can be any integer; the range is not limited to 1-100.

The load balancing algorithm is set to 'per-packet' instead of 'volume'

Why it fails: Per-packet is not an algorithm option.

The performance SLA is set to 'disable' on some interfaces, causing them to be excluded

Why it fails: SLA should be enabled for health, but not directly affect volume distribution.

The VDOMs are not configured with management IP addresses

Why it fails: Management IPs are for administrative access, not for forwarding traffic.

The VDOM limit has been exceeded

Why it fails: VDOM limit would affect creation, not forwarding.

Inter-VDOM routing is disabled between the VDOMs

Why it fails: The traffic is within the same VDOM if both VLANs are in the same VDOM.

To combine multiple ADOMs into a single management domain

Why it fails: ADOMs are administrative containers created and merged through ADOM management, not through automation stitches. A stitch chains triggers to actions such as CLI scripts, webhooks or quarantines in response to events. Consolidating management domains would be the goal when restructuring ADOM topology, not when automating event-driven tasks.

To automatically deploy configuration changes to devices

Why it fails: Automation stitches react to event triggers by running actions such as scripts, webhooks or quarantine, rather than pushing scheduled configuration. Configuration deployment is handled by install operations and policy package installation. A stitch would be chosen to automate a response to a log or event, not to distribute configuration changes.

To stitch together multiple policy packages into one

Why it fails: Automation stitches in FortiManager chain trigger-and-action tasks, such as running scripts or CLI commands when a log event fires; they do not merge policy packages. Consolidating policy packages is done through the Policy Package or ADOM structure itself, which is why this option tempts.

The FortiGate does not have a valid PKI certificate for the ZTNA proxy

Why it fails: A certificate issue would cause TLS handshake failure, not tag mismatch.

The user is not authenticated via SAML

Why it fails: If authentication were the issue, the error would be about authentication, not tags.

The ZTNA rule is using the wrong port number

Why it fails: Port mismatch would cause connection failure, not tag mismatch.

get router info bgp neighbors <neighbor> rejected-routes

Why it fails: This is not a valid command in FortiOS. The correct command to view neighbor status is 'get router info bgp neighbors <neighbor>'.

get router info bgp neighbors <neighbor> received-routes

Why it fails: This command shows received routes from the neighbor, but does not provide the reason for state changes. It may be useful after the session is established.

get router info bgp summary

Why it fails: This command provides a summary of all BGP neighbors and their states, but does not give detailed reasons for flapping for a specific neighbor.

Enable 'auto-discovery-receiver' on the hub's phase1.

Why it fails: Correct. The hub must have auto-discovery-receiver enabled to accept shortcut negotiation requests from spokes.

Set the phase1 authentication method to 'signature' on all devices.

Why it fails: Incorrect. Signature authentication is not required for ADVPN shortcuts; pre-shared key or certificate is used.

Configure the spokes with the hub's public IP as the remote gateway.

Why it fails: Incorrect. While spokes need the hub's public IP for the initial VPN connection, this is not a step specific to establishing shortcut tunnels.

Enable 'auto-discovery-sender' on the spokes' phase1.

Why it fails: Correct. Spokes must have auto-discovery-sender enabled to initiate shortcut tunnels with other spokes.

Enable NAT traversal on the hub's phase1 configuration.

Why it fails: Correct. NAT traversal must be enabled on the hub to handle NAT encapsulation when spokes are behind NAT and establish shortcuts.

Configure 'idle-timeout' to 30 seconds.

Why it fails: Idle-timeout is not related to DPD; it controls the idle time for IKE SAs, not failover detection.

Use aggressive mode for IKE negotiation.

Why it fails: Aggressive mode speeds up IKE phase 1 negotiation but does not affect dead peer detection or failover time.

Enable 'auto-negotiate' on the phase1 interface.

Why it fails: Auto-negotiate is used for interface speed and duplex, not for IPsec failover.

The FortiGate has reached its license limit for automation stitches

Why it fails: License limits affect the number of stitches, not whether they trigger.

The automation stitch was configured with a condition that was not met

Why it fails: A condition is evaluated after the stitch triggers; an unmet condition prevents the action from executing, not the triggering of the stitch itself.

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.