Nse7 Enterprise Firewall System Configuration practice questions

get hardware npu np6

Why it fails: This displays NP6 hardware statistics and session counts per processor, not per-session offload flags. It is tempting because it confirms the NP6 subsystem is running, which is useful when checking whether acceleration is enabled globally, but it cannot identify whether one specific session bypassed the NPU.

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.

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: monitor-interface controls which interfaces trigger failover by tracking link status, not the volume or efficiency of synchronised sessions. It is tempting because it governs HA behaviour, and would be correct when you need failover to occur only when specific links drop.

override

Why it fails: override determines whether a device keeps primary role after a failover, having no bearing on session synchronisation throughput. It is tempting because it is a genuine HA parameter, and would be correct when you must prevent a recovered unit from reclaiming the primary role automatically.

heartbeat-interval

Why it fails: heartbeat-interval sets how often HA heartbeat packets are sent to detect peer failure, not how sessions are synchronised. It is tempting because it tunes HA traffic timing, and would be correct when failover detection speed or heartbeat overhead needs adjusting.

VLAN tagging

Why it fails: VLANs are a sub-layer, not an aggregation algorithm.

Interface mirroring

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

LACP mode active

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

config system npu

Why it fails: Entering config system npu opens the NPU configuration context for editing settings such as offload and fastpath, but it displays no comparison against previous values, so it cannot reveal whether the NP configuration changed. It is tempting because it is the correct place to modify NP behaviour, which suits reconfiguring acceleration rather than diagnosing a firmware-induced change.

diagnose firewall npu

Why it fails: diagnose firewall npu is not a valid FortiGate command, so it returns an error rather than showing whether NP settings changed. It is tempting because the diagnose namespace does contain many hardware-acceleration inspection commands, making the syntax look plausible, but the actual NPU diagnostics live under diagnose npu and related subcommands.

get hardware status

Why it fails: get hardware status reports chassis inventory such as sensors, fans, power supplies and interface presence; it does not read NPU offload configuration, so it cannot show whether NP settings changed. It is tempting because it is a genuine hardware-inspection command, which suits verifying physical components rather than comparing configuration after firmware upgrade.

It shuts down its interfaces

Why it fails: On heartbeat loss the secondary does not shut down its interfaces; it remains passive and waits, while the primary's interfaces are the ones that fail over. Shutting down interfaces is tempting because some vendors do this, and it would be correct if the question described a primary detecting failure and withdrawing its interfaces.

It enters standalone mode

Why it fails: The secondary does not enter standalone mode on heartbeat loss; it stays in HA and monitors for the primary to return, since standalone mode requires an explicit override or HA disable. Standalone mode is tempting because it describes a device operating alone, and it would be correct if HA were deliberately disabled or the unit were removed from the cluster.

It ignores the loss

Why it fails: The secondary does not ignore the loss; it actively monitors the heartbeat and can take over if the primary remains unreachable, depending on failover settings. Ignoring the loss is tempting because passive units appear idle, and it would be correct if the question asked about a unit with HA override disabled and the primary still forwarding traffic.

diag hardware ha

Why it fails: diag hardware ha reports hardware-level HA state such as member priority and link status, not configuration checksums. It tempts because it is a genuine HA diagnostic command, and would be correct when verifying physical HA interface health or failover state rather than configuration synchronisation between cluster members.

show system ha

Why it fails: show system ha displays configured HA settings such as mode, group name and priorities, not live synchronisation status or checksums. It tempts because it is a valid HA command, and would be correct when reviewing the HA configuration itself rather than confirming that configurations are actually in sync.

diagnose sys ha sync

Why it fails: This is for debugging synchronization.

SSH

Why it fails: SSH provides encrypted CLI administration, so disabling it removes a hardened management path rather than closing an exposure. It is tempting because plaintext Telnet is the protocol that should be disabled on public-facing interfaces, but SSH itself is not the recommended access type to remove.

HTTPS

Why it fails: HTTPS provides encrypted GUI administration and is the preferred secure management access method. It is tempting because HTTP, its unencrypted counterpart, should be disabled on public-facing interfaces, but HTTPS itself is not the access type recommended for removal.

SNMP

Why it fails: SNMP is a monitoring protocol, not an administrative access type, so it falls outside the access categories the question addresses. It is tempting because SNMPv1 and v2c are insecure and worth restricting, but the recommended disable applies to administrative access types such as Telnet and HTTP.

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.

Flow-based inspection

Why it fails: Flow-based inspection is a processing mode that examines packets as they stream through the FortiGate; it does not move SSL decryption work onto dedicated hardware. It is tempting because flow-based mode reduces CPU load generally, and would be the right answer if the question asked how to lower inspection overhead rather than offload SSL processing.

IPS engine offloading

Why it fails: IPS engine offloading shifts intrusion-prevention pattern matching onto CP processors, leaving SSL/TLS decryption and re-encryption on the main CPU. It is tempting because both features use the same acceleration hardware, and would be correct if the requirement were to offload IPS inspection rather than SSL inspection.

NP6 offloading

Why it fails: NP handles network throughput/L3/L4.

SNMP

Why it fails: SNMP is for management polling.

TCP/443

Why it fails: This is HTTPS.

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.

Hardware acceleration must be disabled

Why it fails: Inter-VDOM links operate with hardware acceleration enabled; disabling it is not a requirement and would degrade throughput. The condition is tempting because acceleration sometimes causes issues with certain features, so administrators may assume it must be turned off, but that is not the actual criterion.

The link must be in transparent mode

Why it fails: Inter-VDOM links are routed interfaces assigned IP addresses; transparent mode is not required and conflicts with their design. Transparent mode is tempting because it appears to simplify traffic forwarding between VDOMs, which is its purpose in bridging scenarios, but inter-VDOM links do not operate that way.

Enable 'set vdom-admin enable' under system global to enforce strict VDOM separation for administrators.

Why it fails: The 'vdom-admin' setting under system global does not exist in FortiOS. Administrative separation is achieved through VDOM-scoped admin profiles, not a global toggle. This command would be rejected by the CLI, so it cannot provide the required isolation.

Configure an administrative profile with 'set scope global' and assign it only to the tenant1 administrator.

Why it fails: Setting an admin profile to global scope allows the administrator to manage all VDOMs, which is the opposite of isolation. To restrict an administrator to a single VDOM, the profile must be scoped to that VDOM, not global. This would grant broader access, not limit it.

Enable 'set management-vdom enable' under system global and assign a dedicated management VDOM.

Why it fails: The 'management-vdom' command designates a VDOM for out-of-band management and restricts which interfaces can be used for administrative access, but it does not prevent a super_admin user in another VDOM from viewing or modifying other VDOMs. It only changes where management traffic terminates, not the administrative scope.

Automatic disablement of HA

Why it fails: Switching to multi-vdom restarts the device and requires an admin VDOM, but HA configuration persists across the change; it is not automatically disabled. HA is deliberately turned off only when the cluster members must run independent, separately managed configurations rather than synchronised policies.

Loss of all firewall policies

Why it fails: Existing firewall policies are retained and migrated into the management VDOM when multi-vdom is enabled; they are not deleted. Administrators would intentionally remove policies when rebuilding a configuration from scratch, not as a consequence of changing the VDOM mode itself.

No impact, immediate change

Why it fails: Enabling multi-vdom requires a reboot and moves all existing interfaces and policies into a new management VDOM, so the change is disruptive rather than immediate. A no-impact, live change describes operations such as editing an address object, not altering the device's VDOM architecture.

Drop the packet

Why it fails: Transparent mode forwards frames with unknown MAC addresses out of other ports, flooding them like a switch, rather than dropping them. Dropping is tempting because firewall policy may later block the traffic, but the default forwarding behaviour is flood-and-learn, not discard.

Forward to the management interface

Why it fails: Forwarding to the management interface is not part of transparent-mode switching; the FortiGate floods unknown-unicast frames out all ports in the same forwarding domain, excluding the ingress port. The management interface is a host interface for administrative access, so it would be the destination only when management traffic is explicitly directed there.

Send an ICMP unreachable message

Why it fails: Transparent mode forwards unknown-destination frames out all ports in the same broadcast domain, flooding like a switch; it never generates ICMP unreachables for L2 traffic. ICMP unreachable is emitted by routers when an IP packet cannot be delivered, so it fits routed mode, not transparent forwarding.

Device Hostname

Why it fails: Hostname is not a synchronisation requirement; FortiGates in an HA cluster may keep different hostnames and still form successfully. It is tempting because identical hostnames aid identification, but the parameters that must match are group name, group password, and heartbeat interface configuration.

Serial Number

Why it fails: Cluster formation requires matching group-name and group-password, not serial numbers; each FortiGate keeps its own unique serial. Serial number is used for licensing and FortiGuard identification, so it is tempting as an identity field, but it must differ between cluster members.

Priority value

Why it fails: Priority only influences which member becomes primary during elections; mismatched values still allow the cluster to form. Identical group name and password, plus matching interface settings, are what permit heartbeat negotiation. The option is tempting because priority is configured on both devices and visibly affects HA behaviour.

To provide extra management access

Why it fails: Dedicated HA interfaces carry heartbeat and synchronisation traffic between cluster members; management access is provided by separate management or reserved ports. It is tempting because HA links do pass traffic between units and can be reached in troubleshooting, but they are not intended for administrator login, and using them so risks disrupting failover.

To increase throughput

Why it fails: Dedicated HA interfaces carry heartbeat and session-synchronisation traffic between cluster members, not user data, so they cannot raise forwarding throughput. They are tempting because adding links usually boosts capacity, and dedicated HA links do run at high speed — but that bandwidth serves state sync, not client traffic.

To act as a backup WAN port

Why it fails: Dedicated HA interfaces exchange heartbeats and synchronise sessions between cluster units; they cannot forward WAN traffic or provide failover internet access. The temptation is that HA links do carry traffic and survive failures, but a backup WAN requires a separate internet-facing interface with its own route and gateway.

Policy-based routing

Why it fails: Policy-based routing only redirects traffic matching criteria to a specified gateway; it does not create the inter-VDOM link required to pass and inspect traffic between VDOMs. It is tempting because PBR does influence forwarding decisions, but the actual requirement is an inter-VDOM link.

Physical loopback cable

Why it fails: A physical loopback cable would require dedicating two physical interfaces and cabling them together, which is unnecessary since FortiOS provides an internal inter-VDOM link. It is tempting because a cable does physically connect interfaces, but the required mechanism is the software-defined inter-VDOM link.

Static NAT

Why it fails: Static NAT translates addresses and does not establish a path between VDOMs, so traffic cannot traverse or be inspected across them. It is tempting because NAT is commonly configured on FortiGate policies, but the actual requirement is an inter-VDOM link joining the two VDOMs.

Schedule

Why it fails: Changing a schedule alters when the policy is active but does not tear down established sessions; existing connections continue until they idle out or the policy is otherwise changed. Session flush is triggered by edits to the policy's matching or action criteria, such as services or source/destination.

Comments field

Why it fails: Comments are metadata only and are not part of the policy's match or action logic, so editing them leaves the session table untouched. Session flush occurs when fields that determine policy lookup or forwarding change; comments are documentation, useful for auditing but never affecting traffic handling.

Policy Name

Why it fails: The policy name is an administrative label used for identification and logging; it is not evaluated during session lookup, so renaming it does not flush sessions. Flush is caused by changes to matching criteria or actions, not by renaming, which is useful for clarity but functionally inert.