System Configuration practice questions

get hardware npu np6

Why it fails: This command does not exist.

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.

config system npu

Why it fails: This is for configuring, not checking status.

diagnose firewall npu

Why it fails: This is not a valid syntax.

get hardware status

Why it fails: This is too generic.

Applying firewall policies

Why it fails: This is supported in both modes.

Adding a new VDOM

Why it fails: Multi-VDOM supports adding VDOMs.

Inter-VDOM routing

Why it fails: This is supported in both modes.

monitor-interface

Why it fails: This is for HA failover triggering based on link state.

override

Why it fails: This affects master selection logic.

heartbeat-interval

Why it fails: This affects HA cluster health detection, not session sync performance.

Device Hostname

Why it fails: FortiGate HA clustering does not require matching hostnames; each unit may keep a distinct name while still forming the cluster. It is tempting because hostname is a basic device setting, and identical hostnames would matter for DNS or asset identification, not for HA negotiation.

Serial Number

Why it fails: Serial numbers are unique hardware identifiers.

Priority value

Why it fails: Priority should differ to influence the master election.

VLAN tagging

Why it fails: VLAN tagging is a Layer 2 encapsulation setting, not an LACP traffic-distribution mode. It tempts candidates confusing interface tagging with aggregation. Distributing traffic by source and destination IP requires the LACP mode set to L4 or a matching hash algorithm, not VLAN tagging.

Interface mirroring

Why it fails: Mirroring is for traffic inspection, not aggregation.

LACP mode active

Why it fails: Active/passive is for link negotiation.

diag hardware ha

Why it fails: This is not a standard command.

show system ha

Why it fails: This shows the local configuration, not the cluster status.

diagnose sys ha sync

Why it fails: This is for debugging synchronization.

SSH

Why it fails: SSH is encrypted.

HTTPS

Why it fails: HTTPS is encrypted and generally safe.

SNMP

Why it fails: SNMP can be restricted but HTTP is more critical.

It shuts down its interfaces

Why it fails: It remains active for detection but cannot take over unless it thinks the master is dead.

It enters standalone mode

Why it fails: It remains part of the HA cluster architecture.

It ignores the loss

Why it fails: The system requires heartbeat for synchronization.

Schedule

Why it fails: Schedule changes affect new sessions.

Comments field

Why it fails: Comments are metadata only.

Policy Name

Why it fails: Name changes do not affect traffic processing.

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.

The TCP handshake timeout

Why it fails: That is a different setting.

The maximum session duration

Why it fails: That is the absolute-timeout.

The time before an idle session is dropped

Why it fails: That is the session-ttl.

SNMP

Why it fails: SNMP is for management polling.

TCP/443

Why it fails: This is HTTPS.

IP (Non-UDP/TCP)

Why it fails: HA heartbeats use a dedicated EtherType.

UDP/514

Why it fails: This is Syslog.

CPU load

Why it fails: Not a direct factor in election.

Device Hostname

Why it fails: Does not affect election.

group-password

Why it fails: Security setting.

priority

Why it fails: Used for master selection, not failover speed.

monitored-interfaces

Why it fails: Used to trigger failover, not the speed of the detection.

Simple ICMP packets

Why it fails: Simple ICMP packets are offloaded by NP6 once the session is created, so they are not among the excluded traffic types. It tempts because ICMP is connectionless and diagnostic, suggesting it needs CPU inspection, but the NP6 handles established ICMP sessions in hardware.

Standard UDP traffic

Why it fails: NP6 offloads standard UDP flows once a session is established, so this traffic is accelerated rather than excluded. It tempts because UDP lacks TCP's state machine, leading candidates to assume the NP6 cannot track it, yet connectionless session entries are still created.

Hardware acceleration must be disabled

Why it fails: Not required.

The link must be in transparent mode

Why it fails: Inter-VDOM links are logical, not mode-specific.

config ips custom-signature; edit <name>; set signature "<signature>"; end

Why it fails: While this command creates a custom signature entry, it requires the signature text to be manually entered or referenced, and it does not load a file from the local disk. The scenario specifies uploading a custom signature file, which typically contains multiple signatures. This approach is inefficient and error-prone for bulk signatures, and it does not address the file upload method.

execute ips update custom-signature <filename>

Why it fails: This command does not exist in FortiOS. The 'execute ips update' command is used to update the IPS signature database from FortiGuard, not to load a custom signature file. Custom signatures are managed through the 'ips custom-signature' configuration branch, not via an execute command. Using this would result in an error or no effect on the custom signature list.

config firewall custom-signature; edit <name>; set file <filename>; end

Why it fails: This command does not exist. Custom signatures are not configured under 'config firewall custom-signature'. FortiGate uses the 'ips custom-signature' configuration branch for managing custom signatures, and the import is done via an execute command. Attempting this would result in a syntax error or unrecognized command, and the signature would not be loaded.

Enable session pickup and configure the secondary unit to forward traffic for vdom1 using a static route.

Why it fails: Session pickup ensures session synchronization between HA nodes but does not change which unit actively processes traffic. Static routes do not influence HA primary selection. This approach would not make the secondary unit the active node for vdom1; it would remain in standby for all VDOMs.

Set the HA mode to active-active and assign vdom1 to the secondary unit using the 'set vdom' command under the HA secondary configuration.

Why it fails: Active-active HA distributes sessions across all cluster members, but it does not allow per-VDOM active/standby roles. The 'set vdom' command is not valid under HA secondary settings. Virtual clustering is the correct feature to assign different VDOMs to different primary roles, not active-active mode.

Set the HA mode to active-passive and use VDOM link to redirect traffic to the secondary unit.

Why it fails: Active-passive HA designates one unit as primary for all VDOMs and the other as standby. VDOM links are used for inter-VDOM routing within a single unit, not for HA traffic distribution. This configuration would not allow the secondary to actively process vdom1 traffic while the primary handles root.

Configure the FortiGate to operate in NAT/route mode instead of transparent mode.

Why it fails: Switching to NAT/route mode would change the FortiGate's operation to Layer 3 routing, which is not required for bridging VLANs on the same subnet. Transparent mode is specifically designed for this scenario where the FortiGate is inserted into an existing network without changing IP addressing.

Enable inter-VLAN routing on the FortiGate by creating a VLAN interface with an IP address.

Why it fails: Inter-VLAN routing requires a Layer 3 device with IP addresses on each VLAN. In transparent mode, the FortiGate does not perform routing; it bridges traffic. Assigning an IP address to a VLAN interface would not enable routing in transparent mode and is not the correct approach.

Create a VLAN interface for each VLAN and assign them to the same VDOM, then create a firewall policy allowing traffic between them.

Why it fails: In transparent mode, the FortiGate acts as a Layer 2 bridge, so VLAN interfaces are not used for inter-VLAN routing. Creating VLAN interfaces and policies would imply a routed mode configuration, which is not applicable. Transparent mode forwards traffic based on MAC addresses, not IP routing.