Scenario practice questions

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 ZTNA application is not configured with HTTPS

Why it fails: ZTNA application access requires the application definition to specify the correct protocol and port; HTTPS is only relevant for web apps, so a non-web application would be blocked regardless. It is tempting because HTTPS is the common transport for browser-based ZTNA apps, and would be correct if the failing application were a web service.

The FortiClient EMS server is not reachable from the FortiGate

Why it fails: If FortiClient EMS were unreachable from the FortiGate, tag and posture information would not synchronise, but the client would not show 'Connected'. It is tempting because EMS connectivity underpins ZTNA. The failure occurs after connection, so the blocking mechanism is policy or application matching, not EMS reachability.

The FortiGate is not configured with the correct ZTNA application gateway

Why it fails: A missing or incorrect ZTNA application gateway would prevent the tunnel from establishing, so FortiClient would not report 'Connected'. It is tempting because gateway configuration is central to ZTNA. The correct cause lies in policy or access-proxy matching, since authentication and connection already succeeded.

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.

To encrypt routing protocol traffic

Why it fails: BFD carries no encryption; it only exchanges lightweight hello packets to verify bidirectional forwarding. It is tempting because it runs alongside routing protocols, and encryption would be correct if the requirement were protecting OSPF or BGP sessions, which IPsec or protocol authentication handles.

To authenticate routing peers

Why it fails: BFD performs no peer authentication; it merely confirms that packets traverse the path in both directions. It is tempting because BFD sessions are established between neighbours, and authentication would be correct for securing routing adjacencies, which MD5 or SHA authentication on OSPF and BGP provides.

To provide load balancing across multiple paths

Why it fails: BFD detects link or path failure quickly by exchanging control packets; it does not distribute traffic across multiple paths, which ECMP or SD-WAN rules handle. It is tempting because sub-second failure detection accelerates failover between paths, and it would be correct for rapid detection of a dead neighbour.

Configure traffic shaping to rate limit the URL

Why it fails: Traffic shaping only throttles bandwidth for matching traffic; it cannot block or drop a URL, so the Malware category stays permitted. It is tempting because shaping profiles are applied per firewall policy, but that scenario concerns congestion control, not web-filter enforcement.

Add a static URL filter with the exact URL and action 'block'

Why it fails: A static URL filter matches the literal URL string, so it blocks only that exact form and leaves variants, subdomains and other malicious URLs permitted. It is tempting as a surgical override, and would be correct to exempt or block one specific address regardless of category.

Enable DNS filter with botnet C2 domain blocking

Why it fails: DNS filtering blocks resolution of botnet C2 domains, not HTTP requests to URLs already resolved and categorised as Malware by FortiGuard. It is tempting because DNS filtering is a valid layer for known C2 infrastructure, but this scenario requires changing the web filter profile's Malware action from monitor to block.

To load balance traffic across multiple paths.

Why it fails: BFD detects link or neighbour failure quickly so routing protocols can reconverge; it does not distribute sessions across paths. It is tempting because sub-second failure detection underpins resilient multipath designs, yet the actual load balancing is performed by ECMP or SD-WAN rules.

To authenticate OSPF neighbors.

Why it fails: BFD provides liveness detection, not authentication; OSPF neighbour authentication uses MD5 or SHA keyed authentication configured separately. It is tempting because both features strengthen OSPF adjacency handling, but BFD only accelerates failure detection, leaving authentication to the OSPF interface settings.

To encrypt traffic between two FortiGates.

Why it fails: BFD carries no encryption; it only exchanges rapid liveness detection packets, so it cannot secure the tunnel. Confidentiality is tempting because FortiGate-to-FortiGate links are commonly protected, but that is the job of IPsec or TLS, not BFD.

RIP

Why it fails: RIP selects paths by hop count to a destination network; it cannot match source addresses or other attributes. It tempts as a simple distance-vector routing protocol, but policy routes provide the criteria-based forwarding beyond destination IP that the scenario requires.

OSPF route redistribution

Why it fails: OSPF redistribution imports routes from other protocols into OSPF, altering route availability rather than the forwarding decision criteria. It tempts in multi-protocol environments, but policy routes are what let a FortiGate forward based on source IP or other attributes.

ECMP

Why it fails: ECMP load-balances traffic across multiple equal-cost next hops using hashing, but all paths still share the same destination-based lookup. It tempts for path diversity, yet policy routes are the technique that forwards on source address or other criteria beyond destination IP.

Configure revision history to track changes

Why it fails: Revision history passively records configuration changes for audit and rollback; it performs no push to managed devices. Installation requires selecting the policy package and target devices, then invoking Install Wizard. Revision tracking is the right choice when you need to compare or revert prior FortiManager configuration states, not to deploy policy.

Create a new ADOM for the policy package

Why it fails: The policy must reach firewalls in an existing ADOM, so creating another ADOM adds no deployment step and would orphan the package. New ADOMs are created when separating administrative domains or device groups with distinct policy scopes. Installation instead assigns the package to the target ADOM's managed FortiGates.

Enable automation stitches to push the policy

Why it fails: Automation stitches trigger actions on event logs, not policy installation; they cannot push a package to an ADOM. The Install Wizard performs that deployment directly. Stitches suit reactive workflows such as quarantining a compromised host after an IPS event, which is unrelated to distributing configuration.

The priority values are set identically

Why it fails: Identical priority can cause election issues but not split-brain if heartbeat is working.

The HA uptime is mismatched between the two units

Why it fails: Mismatched HA uptime affects which unit assumes the primary role during a negotiated failover, not whether heartbeats are exchanged. Split-brain arises when both units lose visibility of each other across all heartbeat interfaces, so each promotes itself. Uptime synchronisation matters when recovering a failed primary and preventing unnecessary role flapping.

The session pickup feature is disabled

Why it fails: Session pickup only synchronises TCP session state for failover, so disabling it cannot produce two primaries; split-brain arises from lost heartbeat communication on all HA links. It is tempting because session pickup is a genuine HA setting, and it would be the correct focus when sessions drop after a failover rather than when both units claim primary.

Schedule (e.g., run every hour)

Why it fails: Automation stitches are event-driven, not scheduled.

Condition (e.g., severity threshold)

Why it fails: Condition is part of the trigger, not a separate component.

The FortiGate's clock is not synchronized with FortiAnalyzer

Why it fails: Clock skew would affect correlations but not prevent FortiView from showing data.

The FortiAnalyzer ADOM is configured as a global ADOM

Why it fails: A global ADOM spans all administrative domains and cannot hold device-specific FortiView traffic data, so per-device logs never surface in its views. It is tempting because global ADOMs centralise policy and object management across many FortiGates, which is correct when you need shared configuration rather than per-device traffic analysis.

The FortiAnalyzer disk is full and not indexing new logs

Why it fails: A full disk stops log indexing, but the stem states logs are still being received, so indexing is functioning. Disk exhaustion is tempting because it genuinely halts FortiView rendering once the log database cannot write, making it the right suspect when log reception itself has also stopped.

get system performance status

Why it fails: Shows overall system performance, not specific traffic blocking.

diagnose ip arp list

Why it fails: Shows ARP table, not relevant to policy blocking.

diagnose sys session list

Why it fails: Shows active sessions, but not helpful for blocked traffic that never creates a session.

Increase the MTU on the VPN interface

Why it fails: MTU issues cause fragmentation but not complete lack of connectivity.

Disable DPD on the VPN phase 1

Why it fails: DPD is for dead peer detection, not access.

The SD-WAN rule is configured with 'set load-balance-mode' instead of 'best-quality'

Why it fails: Load-balance mode distributes sessions across all SLA-compliant links, yet the stem states the rule uses the best quality SLA strategy, so that setting is not in effect. It is tempting because load balancing is a real SD-WAN strategy, correct when even traffic distribution across healthy links is wanted.

The health-check server is not reachable from the faster link

Why it fails: The health-check server being unreachable would mark that link SLA-failed, yet the stem shows both links above 90% compliance, so reachability is not the fault. Health checks legitimately measure link quality to a probe target; they would be the correct mechanism if the probe itself defined the monitored path.

The SD-WAN rule has a manual routing override configured

Why it fails: A manual routing override pins traffic to a specified member regardless of SLA scores, but the stem's health-check mismatch already explains the link selection. Overrides exist for deliberate path pinning during migrations or maintenance, where an administrator must force traffic down one link despite performance metrics.

A static route to the malicious IP

Why it fails: Unnecessary.

An SSL certificate for the FortiGate

Why it fails: Not relevant.

A firewall policy that allows the traffic

Why it fails: Not directly required for the automation stitch itself.

Check the FortiGate's DNS resolution for the FortiAnalyzer hostname

Why it fails: DNS is only relevant if using hostname; the status shows disconnected, likely IP-based.

Restart the FortiGate's logging service

Why it fails: Restarting may not resolve underlying connectivity.

Disable and re-enable logging to FortiAnalyzer

Why it fails: Toggling may help but should be done after connectivity is confirmed.

To load balance traffic across multiple links.

Why it fails: BFD detects link or path failure rapidly by exchanging hello packets with a peer, so it informs routing convergence rather than distributing sessions across links. It is tempting because fast failure detection supports ECMP failover, but load balancing itself is performed by ECMP or SD-WAN rules, not BFD.

To encrypt BGP updates between peers.

Why it fails: BGP update confidentiality comes from TCP MD5 signatures or IPsec, which encrypt and authenticate the session itself. BFD packets are unencrypted and only signal liveness. It is tempting because BFD is often enabled on the same BGP peering interfaces, but encryption is the right choice when peers traverse untrusted networks.

To authenticate OSPF neighbors.

Why it fails: OSPF neighbour authentication uses key chains or MD5/SHA hashes in the OSPF interface configuration; BFD carries no authentication fields and only exchanges detection timers. It is tempting because both features are configured per interface alongside OSPF, but authentication is the correct choice when you must verify neighbour identity.

The HA password is incorrect

Why it fails: Incorrect password prevents authentication but would not cause both to become primary.

The HA group ID is mismatched

Why it fails: Mismatched group ID prevents cluster formation but typically results in both units being standalone, not both primary.

The HA priority values are equal for both units

Why it fails: Equal priority does not cause both to be primary; tie-breaking uses device priority and serial number.

Check that NAT is enabled on the policies

Why it fails: NAT rewrites addresses and is unnecessary for inter-VDOM traffic, which routes between internal interfaces using the inter-VDOM link; enabling it can obscure the real fault. It is tempting because NAT appears on many FortiGate policies, and would be correct for internet-bound traffic needing source translation.

Check that the inter-VDOM link is configured as a physical interface

Why it fails: An inter-VDOM link is its own virtual interface type, not a physical one, so configuring it as physical is impossible. It is tempting because physical interfaces commonly carry routed traffic, and would be correct when verifying the underlying physical ports that member interfaces or VLANs are bound to.

Check that both VDOMs are in the same administrative VDOM

Why it fails: VDOMs are by definition separate administrative domains; there is no parent administrative VDOM containing them, so this check cannot exist. It is tempting because administrative scoping and multi-tenancy concepts are familiar, and would be relevant when verifying administrator profile access rather than inter-VDOM traffic flow.