System and Network Administration practice questions

Use the command 'execute upgrade image tftp <ip> <filename>'.

Why it fails: The FortiGate CLI upgrade syntax is 'execute restore image tftp <filename> <ip>'; 'execute upgrade image' is not a valid command. It is tempting because the words 'upgrade' and 'image' appear in FortiOS documentation, but restore is the verb that actually writes firmware. TFTP transfer itself is a legitimate upgrade method.

Use the command 'execute backup config tftp'.

Why it fails: 'execute backup config tftp' uploads the configuration file to a TFTP server; it transfers no firmware image. It tempts because it is a legitimate 'execute' command involving file transfer, and would be the right choice when backing up configuration before an upgrade.

Use the command 'execute reboot'.

Why it fails: 'execute reboot' restarts the device and installs nothing; firmware requires 'execute restore image' or the GUI upgrade path. It tempts because rebooting is a normal part of completing an upgrade, and would be correct as the final step after the new image is already loaded.

Use the command 'execute restore config tftp'.

Why it fails: This command restores a configuration backup from a TFTP server, not firmware; it overwrites running config rather than upgrading FortiOS. It is tempting because 'restore' sounds like an upgrade operation, and TFTP is a legitimate transport for FortiGate backups and firmware images, but firmware upgrades require 'execute restore image' or the GUI.

Configure two separate log settings for each server.

Why it fails: This approach fails because FortiOS only supports a single `syslogd setting` object per VDOM; you cannot create multiple independent syslog server configuration blocks. Attempting to run two separate `config log syslogd setting` instances would result in the second overriding the first or an error, as the configuration namespace is not mergeable. The correct way is to list multiple servers within the one `set server` command, which the FortiGate treats as a multi-destination list.

Configure one syslog server and use a load balancer.

Why it fails: Adding a load balancer in front of a single syslog server is unnecessarily complex and contradicts the FortiGate’s built-in multi-server capability. A load balancer introduces a single point of failure and requires additional hardware or virtual appliance configuration, while the FortiGate can already send logs to multiple servers natively. Moreover, load balancing syslog traffic could split the log stream across collectors, making it harder to maintain a complete, ordered log trail, whereas listing servers directly sends the same log to every server.

Use a FortiAnalyzer to forward logs to syslog servers.

Why it fails: Using FortiAnalyzer solely to forward logs to syslog servers is an inefficient, roundabout architecture. FortiAnalyzer is designed for aggregation, correlation, and long-term storage of logs from many FortiGate devices, not as a proxy between a single FortiGate and external syslog collectors. This adds an extra network hop, increases latency, and creates a dependency on the FortiAnalyzer being online, whereas the FortiGate can directly send logs to multiple syslog servers using the native `syslogd` settings, which is simpler and more reliable.

The schedule is set to 'always', causing no time-based logging.

Why it fails: The schedule is set to 'always' means the policy is continuously active and generates logs 24/7, but it does not restrict or modify which fields are recorded. Logging content is determined by the policy's log settings and global log configuration, not by the schedule. Therefore, this cannot explain a non-original source IP in the logs.

Logging is set to 'all' but only 'utma' events are logged.

Why it fails: When policy logging is set to 'all', FortiGate is instructed to generate logs for both allowed and denied sessions, and for all events matching that policy. 'utma' is a specific UTM attack log type, not the complete set of traffic logs; seeing only utma entries indicates a log filter or analyzer rule, not the 'all' logging setting. Thus this option incorrectly describes the cause.

The policy action is 'accept' without authentication.

Why it fails: The policy action 'accept' means the firewall permits the traffic without requiring user authentication; authentication only affects identity-based policies and adds user fields to the log. It does not change the source IP address that appears in the packet or log. Accordingly, the lack of authentication cannot be responsible for the public source address shown in the traffic log.

The VoIP traffic is being offloaded by NPU bypassing SD-WAN.

Why it fails: NPU offloading does not bypass SD-WAN rules.

The administrator needs to enable 'set internet-service enable' on the rule.

Why it fails: Internet service is for specific applications, not required.

The SD-WAN rule is not matching the VoIP traffic correctly.

Why it fails: The administrator tested and confirmed the rule is applied.

Disable NAT inspection on the firewall policy

Why it fails: Disabling NAT inspection is unrelated to session persistence.

Configure gratuitous ARP on the virtual IP

Why it fails: Gratuitous ARP updates MAC tables but does not preserve sessions.

Increase the heartbeat interval to 2 seconds

Why it fails: Increasing heartbeat interval may delay failover detection, not preserve sessions.

Enable web proxy globally under config system settings

Why it fails: Global web proxy settings are not configured under `config system settings`. In FortiOS, global proxy behavior is defined under `config web-proxy` for the proxy server itself, while per-policy behavior is set via explicit proxy firewall policies. Enabling a nonexistent 'web proxy globally' switch under system settings would be an invalid CLI command and does nothing to establish transparent proxy functionality. The correct approach is to create an explicit proxy policy on the bridge interface.

Assign an IP address to the proxy interface

Why it fails: In transparent mode, the proxy does not own a dedicated IP address on each physical interface; instead, the software switch or bridge gets one administrative IP. Assigning an IP directly to the proxy interface would convert that interface to Layer 3 and cause the FortiGate to route traffic instead of bridging it, violating transparent proxy behavior. The bridge IP is used only for management and proxy access, not for traffic forwarding. Therefore, adding an IP address to the proxy interface is both unnecessary and harmful.

Antivirus profile: Controls application usage and blocks risky applications

Why it fails: This is incorrect because an Antivirus profile does not perform application identification or enforcement; its core function is to scan file content for malicious code patterns. Control over risky applications, such as peer-to-peer clients or unauthorized cloud storage, relies on the separate Application Control profile, which inspects application behavior and metadata rather than scanning for malware signatures.

Web filter profile: Detects and prevents network attacks

Why it fails: This is incorrect because Web filter profiles do not inspect packet payloads for exploit attempts or attack signatures; that is the role of an IPS profile. A Web filter only evaluates the reputation and category of a requested URL, blocking based on allowed/denied categories rather than detecting anomalies or malicious network activity in real time.

The FortiGate has a policy route overriding the static route.

Why it fails: A policy route is evaluated before the destination-based routing table and can force traffic to a different next hop or outgoing interface. If such a policy route matched, the FortiGate would still forward the packets out the specified interface, so the sniffer would capture them and replies would be expected if that path were functional. Since the symptom is that packets are not being transmitted successfully, a policy route alone would not explain the failure unless its outgoing interface is also misconfigured or down—which is the actual root cause suggested by the correct answer. Therefore, simply having a policy route override is not the most specific or likely explanation.

The destination host has a firewall blocking ICMP.

Why it fails: A firewall on the destination host blocking ICMP would only prevent the host from sending a reply; the FortiGate would still successfully transmit the ICMP echo requests out the correct interface, and the sniffer would show those outgoing packets. If the FortiGate's route has an incorrect or down outgoing interface, the sniffer might show no packets leaving at all, or packets leaving the wrong interface, which points to a routing-layer problem rather than a remote firewall filter. Blocking ICMP does not affect the FortiGate's ability to forward packets, so it cannot be the primary cause when the issue is at the FortiGate's routing/interface layer.

The static route has a higher administrative distance than a dynamic route.

Why it fails: Administrative distance is a preference value used to select among routes to the same destination from different routing protocols; a static route with a higher AD than a dynamic route would not be installed as the active route, but the lower-AD dynamic route would be used instead. As long as that dynamic route is valid, traffic would be forwarded normally and the sniffer would show packets leaving the correct interface, so this would not cause the observed failure. If the dynamic route later goes down, the static route becomes active and is used, so a higher AD alone never results in a black hole unless no viable route is active at all.

The FortiGate is not operating in a VDOM.

Why it fails: The FortiGate's VDOM mode is unrelated to its logging capability; VDOMs are a virtualization feature that divides the device into multiple logical firewalls. In both single-VDOM and multi-VDOM deployments, session logging works identically and is controlled by firewall policy settings and global logging configuration. Therefore, the absence of logs cannot be attributed to the FortiGate not operating in a VDOM; it is a red herring.

The FortiGate is in transparent mode and cannot log traffic.

Why it fails: Transparent mode fully supports logging—it is a Layer 2 deployment mode, not a limitation on logging. The FortiGate can inspect traffic and generate traffic logs, event logs, and even security logs regardless of whether it is running in transparent or routed mode. The fact that logs are missing is due to policy logging settings, not the operational mode, so this explanation is incorrect.

The log memory buffer is full and not sending to syslog.

Why it fails: A full log memory buffer would cause new logs to be dropped or overwritten, but it would not prevent the system from generating session logs in the first place. If the firewall policy has logging disabled, no session log entry is created at all, so there is nothing to buffer or forward to syslog. Thus, even if the buffer were full, it would not explain why no logs exist for the bridged traffic; the root cause is the policy configuration.

The SNMP community string is not configured.

Why it fails: An absent or incorrect community string would trigger an authentication failure at the SNMP agent, resulting in a 'wrong community' error message in the NMS or an SNMP response with an error status. This does not prevent the UDP packet from reaching the FortiGate; the NMS would still receive a response indicating the failure. Therefore, a community string misconfiguration cannot produce a complete lack of reachability or connectivity, which is the symptom described in the scenario.

NTP is not configured, causing time mismatch.

Why it fails: NTP synchronization affects the accuracy of log timestamps, event correlation, and certificate handling, but it is not a prerequisite for the SNMP agent to reply to queries. The FortiGate's SNMP daemon processes incoming polls independently of the system clock, so a time mismatch will not cause UDP 161 packets to be dropped or unanswered. At most, an NTP offset could lead to inconsistent event timestamps, but the NMS would still be able to reach the device and receive responses.

The FortiGate is not configured to send SNMP traps.

Why it fails: SNMP traps are unsolicited notifications sent from the FortiGate to the NMS (typically on UDP 162) and are used only for event-driven alerts, not for standard read/write monitoring. In this scenario, the NMS is polling the device for counters and status, which requires only a working UDP 161 path and valid SNMP credentials. The absence of trap configuration means the NMS will not receive proactive alert messages, but it has no effect on the NMS's ability to reach the FortiGate or obtain data via polling.

The FortiAnalyzer is not registered with the FortiGate.

Why it fails: Registration is not required for basic logging.

The FortiGate is not generating any logs.

Why it fails: Even if no logs, connection would be established.

The FortiAnalyzer SNMP community string is incorrect.

Why it fails: SNMP is not used for logging.

The cluster IP address is assigned to both units simultaneously.

Why it fails: In active-passive mode the cluster IP is active only on the primary unit; the subordinate holds it in standby and takes over on failover. It is tempting because the cluster IP appears on whichever unit is primary, which can look simultaneous, but only one unit answers at any time.

Both units can forward traffic simultaneously.

Why it fails: Active-passive HA designates one unit as primary and the other as subordinate; only the primary forwards traffic, while the subordinate stays on standby. The tempting misconception is that both appliances share the load, which describes active-active mode, where session synchronisation lets both units process traffic concurrently.

Heartbeat interfaces are optional.

Why it fails: FortiGate HA requires heartbeat communication over dedicated links or monitored interfaces to exchange hello packets and detect failures; without it, the cluster cannot form or synchronise. It is tempting because some vendors allow heartbeat over data interfaces, but FortiOS still mandates a heartbeat path.

NAT traversal is enabled on both sides.

Why it fails: NAT-T (RFC 3948) is only required when an intermediate device performs NAT between the two VPN peers; without NAT, IKE and ESP use their native UDP 500/IP protocol 50 transport. If no NAT exists, enabling or disabling NAT-T has no effect on IKE negotiation, so it cannot be the cause of a failing tunnel. Even when NAT is present, NAT-T is negotiated during IKE phase 1 as a vendor-specific payload, not as a standalone prerequisite.

The phase 2 proposal matches the remote device.

Why it fails: The phase 2 (IPsec) proposal defines encryption and integrity algorithms for ESP and is negotiated only after the phase 1 IKE SA has been authenticated and established. If the phase 1 tunnel is down, a phase 2 mismatch cannot be the initial cause because the FortiGate never reaches the phase 2 QUICK_MODE exchange. A mismatch would manifest as a missing IPsec SA or repeated phase 2 negotiation failed logs, but only after phase 1 is up, so it is not relevant to an IKE-level failure.

Enable VDOMs on the FortiGate.

Why it fails: VDOMs are not required for FortiManager integration.

Create a local admin account on the FortiGate for FortiManager to use.

Why it fails: FortiManager uses its own authentication.

Enable NTP in the admin settings

Why it fails: Although NTP must be enabled on the FortiGate, it is not enabled within 'admin settings.' The NTP client is configured globally under config system ntp (CLI) or via System > FortiGuard > NTP in the GUI, whereas admin settings manage administrator accounts, authentication methods, password policies, and idle timeout. There is no toggle for NTP inside administrator settings, and enabling NTP there would be both impossible and irrelevant to the synchronization process. The configuration location is a common point of confusion, but it does not affect the network-level requirement of allowing UDP 123 traffic.

Set the timezone using config system global

Why it fails: Setting the timezone using config system global is not a prerequisite for NTP synchronization. While the timezone is indeed configured in the global system settings, it only determines how the local time is derived from the UTC time maintained by the system. NTP synchronization operates independently of timezone because the NTP protocol exchanges UTC timestamps to adjust the system clock, and a timezone offset does not alter the NTP client's ability to send or receive time updates. Even with an incorrect timezone, NTP would still synchronize the clock; only the displayed local time would be wrong.

Disable daylight saving time

Why it fails: Disabling daylight saving time (DST) has no bearing on NTP synchronization because NTP works with UTC, which does not follow DST changes. The DST setting only affects how local time is presented by adding or subtracting an hour based on summer time rules. Since the NTP client communicates with servers using UTC, enabling or disabling DST does not affect the packet exchange on UDP 123 or the clock adjustment process. This is a misconception that confuses local time rendering with the fundamental time-synchronization mechanism.

The session is UDP (proto=6 is TCP? Actually proto=6 is TCP) and the output indicates an ICMP error

Why it fails: This is incorrect because proto=6 indicates TCP, not UDP, and there is no mention of an ICMP error.

There is a problem because the session duration equals the expire time, meaning it will be removed immediately

Why it fails: This is incorrect because the duration and expire values are not equal (3600 vs 3599), so the session will not be removed immediately.

Enable the 'Sync on Save' option

Why it fails: 'Sync on Save' is a feature for HA clusters, not for basic NTP configuration.

Configure a firewall policy to allow NTP traffic (UDP 123)

Why it fails: NTP traffic from the FortiGate itself is not subject to firewall policies unless it is a VDOM or transparent mode? Actually, the FortiGate's own NTP requests are not governed by policies. But if the FortiGate is behind another firewall, that firewall may need to allow NTP. However, on the FortiGate itself, no policy is needed for its own traffic.

Set the time zone to the local time zone

Why it fails: Setting time zone is important for display but not required for NTP to work.

Enable NAT on the policies to translate addresses between VLANs

Why it fails: NAT is not typically used in transparent mode for inter-VLAN traffic; it would be layer 2 forwarding.

Configure static routes to route between VLANs

Why it fails: Transparent mode does not route; it bridges. So no routing needed.

The aggregate interface is set to active-passive mode

Why it fails: Active-passive mode would not cause uneven load balancing; it simply uses one port at a time. The most likely cause is the default MAC-based hash algorithm.

The physical ports are connected to different switches

Why it fails: Connecting to different switches is possible with LACP and is not the most likely cause of uneven load balancing. The algorithm is the primary factor.

The MTU size is mismatched on the physical ports

Why it fails: MTU mismatch leads to packet fragmentation or drop, not uneven load balancing. It would cause connectivity issues rather than distribution imbalance.

The FortiGate was in HA mode and the peer did not upgrade

Why it fails: In an HA cluster the primary pushes firmware to the secondary, and a failed peer upgrade typically causes the cluster to keep running the old image rather than silently reverting. It is tempting because HA synchronisation issues do disrupt upgrades, but the symptom would be an out-of-sync cluster, not a single device on old firmware.

The admin did not reboot after the upgrade

Why it fails: The GUI upgrade process automatically reboots the FortiGate to load the new image, so a missing manual reboot cannot explain reverting to old firmware. It is tempting because some upgrade methods do require a separate reboot step, which is where this confusion arises.

The admin forgot to save the configuration before upgrading

Why it fails: Saving the configuration does not affect which firmware image boots; the upgrade process itself writes the new image to the boot partition. It is tempting because unsaved config is lost on reboot, which is a real FortiGate concern — but that would show as missing settings, not the old firmware version.