How should I use these System and Network Administration practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just System and Network Administration questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the System and Network Administration domain.

NSE4 · topic practice

System and Network Administration practice questions

Practise Fortinet NSE 4 Network Security Professional NSE4 System and Network Administration practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: System and Network Administration

Practice 10 questions Browse domain →

What the exam tests

What to know about System and Network Administration

System and Network Administration questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common System and Network Administration exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

System and Network Administration questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full System and Network Administration explanation →

A company wants to ensure that administrative access to FortiGate is only allowed from the internal trusted network (192.168.1.0/24) and that all other access attempts are blocked. Which CLI command should the administrator configure first?

Trap 1: config system interface; edit port1; set allowaccess ping https…

This command configures the administrative protocols (ping, HTTPS, SSH) allowed on the physical interface port1. It does not limit which source IP addresses can initiate administrative sessions; any host that can reach port1's network can attempt an admin login. It is an interface-level service control, not a source-based access restriction. Without a 'trusthost' entry, an admin can log in from any reachable IP, so this does not achieve the stated 192.168.1.0/24 restriction.

Trap 2: config system global; set admin-http-redirect enable; end

Enabling 'admin-http-redirect' under 'config system global' only forces HTTP requests to the admin interface to be redirected to HTTPS for secure communication. It does not filter or restrict where administrative connections can originate. The setting merely changes the protocol behavior during login and has no effect on source IP validation, so it cannot ensure that only 192.168.1.0/24 users can access the FortiGate's admin functions.

Trap 3: set admin-sport 443

Executing 'set admin-sport 443' (presumably in 'config system global') changes the TCP port used for HTTPS administrative access from the default to 443 (or reasserts it). This modifies only the listening port — it does not inspect or restrict the source IP of incoming admin connections. As a result, it has no capability to limit administrative access to the 192.168.1.0/24 subnet, and the option is solely a port configuration, not a security policy.

Study all System and Network Administration common traps →

A
config system admin; edit admin; set trusthost 192.168.1.0 255.255.255.0; end
The 'trusthost' command under 'config system admin' defines an allowed source IP or subnet for administrative logins to that specific admin account. By setting '192.168.1.0 255.255.255.0', only clients originating from the 192.168.1.0/24 network can authenticate as 'admin' — all other source IPs are rejected at the management daemon level, regardless of credentials. This is the only provided option that actually restricts administrative access to a specific source address range.
B
config system interface; edit port1; set allowaccess ping https ssh; end
Why wrong: This command configures the administrative protocols (ping, HTTPS, SSH) allowed on the physical interface port1. It does not limit which source IP addresses can initiate administrative sessions; any host that can reach port1's network can attempt an admin login. It is an interface-level service control, not a source-based access restriction. Without a 'trusthost' entry, an admin can log in from any reachable IP, so this does not achieve the stated 192.168.1.0/24 restriction.
C
config system global; set admin-http-redirect enable; end
Why wrong: Enabling 'admin-http-redirect' under 'config system global' only forces HTTP requests to the admin interface to be redirected to HTTPS for secure communication. It does not filter or restrict where administrative connections can originate. The setting merely changes the protocol behavior during login and has no effect on source IP validation, so it cannot ensure that only 192.168.1.0/24 users can access the FortiGate's admin functions.
D
set admin-sport 443
Why wrong: Executing 'set admin-sport 443' (presumably in 'config system global') changes the TCP port used for HTTPS administrative access from the default to 443 (or reasserts it). This modifies only the listening port — it does not inspect or restrict the source IP of incoming admin connections. As a result, it has no capability to limit administrative access to the 192.168.1.0/24 subnet, and the option is solely a port configuration, not a security policy.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full System and Network Administration explanation →

A FortiGate administrator is troubleshooting a high CPU usage issue. The 'get system performance status' command shows that the CPU usage is consistently above 80% with no traffic. Which of the following is the most likely cause?

Trap 1: An interface is in error-disable state causing CPU interrupts.

Error-disable state is a port-level protection mechanism that disables the interface in hardware, so the CPU is no longer involved in forwarding or receiving packets on that port. It typically triggers a log or alarm but does not generate sustained interrupt processing; in fact, it reduces CPU load by stopping traffic. Interrupt-driven CPU spikes are usually associated with physical-layer issues like duplex mismatches or flapping links, not an error-disabled interface.

Trap 2: The firewall policy is misconfigured, causing packet drops.

A misconfigured firewall policy causes packets to be denied or dropped by the data plane's ASIC or NP6 processor, which handles forwarding and policy enforcement in hardware without involving the main CPU. The CPU only becomes involved when a session is being established, when traffic is punted for deep inspection, or when the policy requires proxy operations. Therefore, high CPU usage would not be caused simply by packet drops; the drops would be handled off-CPU and appear in the traffic logs.

Trap 3: A DDoS attack is overwhelming the CPU.

A DDoS attack, especially a volumetric one, would be clearly visible as a large spike in received traffic, packet rates, and session counts in the traffic logs and interface counters. FortiGate has hardware offloading and DoS policies (e.g., SYN cookie) that mitigate floods at the data plane, so an attack that truly overwhelms the CPU would be accompanied by high traffic. If the administrator is troubleshooting high CPU with little or no traffic, a DDoS attack is not a plausible root cause, as the CPU load must come from somewhere else.

Study all System and Network Administration common traps →

A
An interface is in error-disable state causing CPU interrupts.
Why wrong: Error-disable state is a port-level protection mechanism that disables the interface in hardware, so the CPU is no longer involved in forwarding or receiving packets on that port. It typically triggers a log or alarm but does not generate sustained interrupt processing; in fact, it reduces CPU load by stopping traffic. Interrupt-driven CPU spikes are usually associated with physical-layer issues like duplex mismatches or flapping links, not an error-disabled interface.
B
The firewall policy is misconfigured, causing packet drops.
Why wrong: A misconfigured firewall policy causes packets to be denied or dropped by the data plane's ASIC or NP6 processor, which handles forwarding and policy enforcement in hardware without involving the main CPU. The CPU only becomes involved when a session is being established, when traffic is punted for deep inspection, or when the policy requires proxy operations. Therefore, high CPU usage would not be caused simply by packet drops; the drops would be handled off-CPU and appear in the traffic logs.
C
A DDoS attack is overwhelming the CPU.
Why wrong: A DDoS attack, especially a volumetric one, would be clearly visible as a large spike in received traffic, packet rates, and session counts in the traffic logs and interface counters. FortiGate has hardware offloading and DoS policies (e.g., SYN cookie) that mitigate floods at the data plane, so an attack that truly overwhelms the CPU would be accompanied by high traffic. If the administrator is troubleshooting high CPU with little or no traffic, a DDoS attack is not a plausible root cause, as the CPU load must come from somewhere else.
D
A process such as the IPS engine is stuck in an infinite loop.
A stuck process like the IPS engine can enter an infinite loop or deadlock in user space, consuming an entire CPU core even when no traffic is passing through the device. This is a well-known software defect scenario; the process runs continuously, executing instructions without yielding, causing high CPU while traffic counters remain low. Administrators can confirm this with `diag sys top` to identify the process ID, then restart the engine or the FortiGate, and also check for crash logs to identify the underlying bug.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full System and Network Administration explanation →

An administrator needs to back up the FortiGate configuration to a TFTP server at 10.0.0.10. Which command should be used?

Trap 1: tftp -p -l mybackup.conf 10.0.0.10

This is a standard Unix/Linux TFTP client command, not a FortiGate CLI command. On FortiGate, you must use the 'execute' command hierarchy; a bare 'tftp' binary is not available in the FortiGate CLI environment. Even if it were, the -p and -l flags are for a client push, not the FortiGate's backup operation syntax.

Trap 2: execute backup config ftp mybackup.conf 10.0.0.10

This command would attempt the backup over FTP instead of TFTP, which is the wrong protocol per the requirement. Moreover, an FTP backup on FortiGate generally requires additional credential parameters (username and password) to authenticate to the FTP server; without them, the command is incomplete and would likely fail even if FTP were acceptable. The presence of 'ftp' instead of 'tftp' changes the entire operation.

Trap 3: copy config tftp://10.0.0.10/mybackup.conf

FortiGate does not use a 'copy' command for configuration backups — that syntax is typical of Cisco IOS. The FortiGate's operational commands are under 'execute', so 'copy config tftp://...' would produce an 'Unknown action' error. Additionally, FortiGate backup commands take the filename and server as separate positional arguments, not as a URL with a scheme.

Study all System and Network Administration common traps →

A
tftp -p -l mybackup.conf 10.0.0.10
Why wrong: This is a standard Unix/Linux TFTP client command, not a FortiGate CLI command. On FortiGate, you must use the 'execute' command hierarchy; a bare 'tftp' binary is not available in the FortiGate CLI environment. Even if it were, the -p and -l flags are for a client push, not the FortiGate's backup operation syntax.
B
execute backup config tftp mybackup.conf 10.0.0.10
This is the correct FortiGate CLI command for backing up the configuration to a TFTP server. The command 'execute backup config' specifies the backup operation, 'tftp' selects the protocol, 'mybackup.conf' is the destination filename on the server, and '10.0.0.10' is the server IP. On FortiGate, this initiates a TFTP put from the unit, and it is the exact syntax required to meet the administrator's need.
C
execute backup config ftp mybackup.conf 10.0.0.10
Why wrong: This command would attempt the backup over FTP instead of TFTP, which is the wrong protocol per the requirement. Moreover, an FTP backup on FortiGate generally requires additional credential parameters (username and password) to authenticate to the FTP server; without them, the command is incomplete and would likely fail even if FTP were acceptable. The presence of 'ftp' instead of 'tftp' changes the entire operation.
D
copy config tftp://10.0.0.10/mybackup.conf
Why wrong: FortiGate does not use a 'copy' command for configuration backups — that syntax is typical of Cisco IOS. The FortiGate's operational commands are under 'execute', so 'copy config tftp://...' would produce an 'Unknown action' error. Additionally, FortiGate backup commands take the filename and server as separate positional arguments, not as a URL with a scheme.

Full breakdown with real-world context →

Question 4hardmultiple choice

Read the full network assurance explanation →

Refer to the exhibit. An administrator wants to enable SNMP access on the wan1 interface. Which of the following is the most efficient method?

Exhibit

config system interface
    edit "wan1"
        set vdom "root"
        set ip 10.0.0.1 255.255.255.0
        set allowaccess ping https ssh
        set type wan
        set role wan
        set snmp-index 1
    next
end

Trap 1: Change the interface type to 'management' to allow SNMP.

The interface type in FortiGate is a structural classification (e.g., physical, vlan, loopback, tunnel) and does not act as an access-control switch for SNMP or other management protocols. There is no supported 'management' interface type; even a dedicated management interface still uses the same allowaccess setting to control which services it accepts. Changing the interface type would not add snmp to the allowaccess list, so SNMP requests would remain unanswered on that interface.

Trap 2: Execute 'config system interface' and edit wan1, then set…

The snmp-index parameter under 'config system interface' defines an arbitrary integer used as the ifIndex in SNMP MIB walks, ensuring a stable identifier for that interface regardless of its order in the system. It is an identification attribute, not an authorization attribute, and it has no bearing on whether SNMP is reachable. Moreover, a snmp-index is typically generated automatically for each interface, so manually setting it adds no functional value for enabling SNMP service.

Trap 3: Configure an SNMP community under 'config system snmp community'.

Creating an SNMP community under 'config system snmp community' defines the authentication credentials, read/write permissions, and allowed manager IPs for SNMPv1/v2c queries, which is a necessary prerequisite for any SNMP communication. However, it is not sufficient: the FortiGate also requires each interface to explicitly include snmp in its allowaccess statement before it will respond on that interface. Without that per-interface permission, the community is configured but silently ignored for wan1 traffic, so SNMP requests will time out.

Study all System and Network Administration common traps →

A
Execute 'config system interface' and edit wan1, then set allowaccess ping https ssh snmp.
The FortiGate CLI command 'config system interface' followed by 'edit wan1' and 'set allowaccess ping https ssh snmp' explicitly appends snmp to the interface's list of permitted management access services. This is the mandatory per-interface gate: even after defining an SNMP community globally, the FortiGate will only respond to SNMP requests on interfaces whose allowaccess includes snmp. Adding snmp to wan1 therefore enables SNMP agents to serve queries and traps on that interface while preserving existing ping, https, and ssh management access.
B
Change the interface type to 'management' to allow SNMP.
Why wrong: The interface type in FortiGate is a structural classification (e.g., physical, vlan, loopback, tunnel) and does not act as an access-control switch for SNMP or other management protocols. There is no supported 'management' interface type; even a dedicated management interface still uses the same allowaccess setting to control which services it accepts. Changing the interface type would not add snmp to the allowaccess list, so SNMP requests would remain unanswered on that interface.
C
Execute 'config system interface' and edit wan1, then set snmp-index 1.
Why wrong: The snmp-index parameter under 'config system interface' defines an arbitrary integer used as the ifIndex in SNMP MIB walks, ensuring a stable identifier for that interface regardless of its order in the system. It is an identification attribute, not an authorization attribute, and it has no bearing on whether SNMP is reachable. Moreover, a snmp-index is typically generated automatically for each interface, so manually setting it adds no functional value for enabling SNMP service.
D
Configure an SNMP community under 'config system snmp community'.
Why wrong: Creating an SNMP community under 'config system snmp community' defines the authentication credentials, read/write permissions, and allowed manager IPs for SNMPv1/v2c queries, which is a necessary prerequisite for any SNMP communication. However, it is not sufficient: the FortiGate also requires each interface to explicitly include snmp in its allowaccess statement before it will respond on that interface. Without that per-interface permission, the community is configured but silently ignored for wan1 traffic, so SNMP requests will time out.

Full breakdown with real-world context →

Question 5hardmulti select

Read the full System and Network Administration explanation →

An administrator is troubleshooting a FortiGate that is not passing traffic. The policy allows traffic, but the session table shows no sessions. Which THREE steps should the administrator take to diagnose the issue? (Choose three.)

Trap 1: Run 'diagnose npu np6 show' to check offloading.

The `diagnose npu np6 show` command is designed for FortiGate models equipped with NP6 network processors to inspect offloading counters and performance statistics. It does not diagnose basic connectivity issues like interface state, routing, or ARP resolution, and on non-NP6 models it will error out. Since offloading is a performance optimization rather than a forwarding prerequisite, this command is irrelevant to isolating traffic failures.

Trap 2: Disable the firewall policy and check if traffic flows.

Disabling the firewall policy is a blunt, insecure test that removes the security barrier without revealing the actual root cause. If traffic starts flowing after disabling the policy, the issue might be in policy matching (source/destination, service, schedule), but the problem could also be elsewhere, and disabling the policy would not fix forwarding failures caused by an interface down, missing route, or unresolved ARP. This approach increases risk and provides no diagnostic value; you should first verify the underlying Layer 1 through Layer 3 elements.

Study all System and Network Administration common traps →

A
Verify the interface status and link state.
Verifying the physical and logical interface state is the first step in any FortiGate connectivity troubleshooting. If the interface is administratively down or the link has no carrier (e.g., bad cable, remote device powered off), all traffic through that interface is dropped regardless of routes or policies. Use `get system interface physical` and `diagnose hardware deviceinfo nic` to confirm link status, speed, and duplex.
B
Run 'diagnose npu np6 show' to check offloading.
Why wrong: The `diagnose npu np6 show` command is designed for FortiGate models equipped with NP6 network processors to inspect offloading counters and performance statistics. It does not diagnose basic connectivity issues like interface state, routing, or ARP resolution, and on non-NP6 models it will error out. Since offloading is a performance optimization rather than a forwarding prerequisite, this command is irrelevant to isolating traffic failures.
C
Check the ARP table to ensure the next-hop MAC is resolved.
For a FortiGate to forward a packet to a next-hop router, it must first resolve that router's IP address to a MAC address in its ARP cache. If the ARP entry is incomplete or missing—due to a misconfigured gateway, L2 isolation, VDOM issues, or an unresponsive peer—the FortiGate cannot construct the Layer 2 frame and silently drops the packet. Verify with `get system arp` or `diagnose ip arp list` to ensure the next-hop MAC is present and correct.
D
Examine the routing table for the destination network.
The FortiGate must have an active route in its routing table that matches the destination network to determine the outgoing interface and next-hop IP. If no such route exists—whether static, connected, or learned via dynamic routing—the FortiGate drops the traffic and often sends an ICMP destination unreachable message to the source. Use `get router info routing-table all` or `get route` to confirm a valid path; without a route, no policy can ever match the traffic because the route lookup happens first.
E
Disable the firewall policy and check if traffic flows.
Why wrong: Disabling the firewall policy is a blunt, insecure test that removes the security barrier without revealing the actual root cause. If traffic starts flowing after disabling the policy, the issue might be in policy matching (source/destination, service, schedule), but the problem could also be elsewhere, and disabling the policy would not fix forwarding failures caused by an interface down, missing route, or unresolved ARP. This approach increases risk and provides no diagnostic value; you should first verify the underlying Layer 1 through Layer 3 elements.

Full breakdown with real-world context →

Question 6easymultiple choice

Read the full System and Network Administration explanation →

What is the default administrative account on a FortiGate?

Trap 1: master

The name 'master' is not a default account in FortiOS. FortiGate is configured with only the factory bootstrap account 'admin', and there is no 'master' user created in the local user database. Some switching or wireless equipment uses 'master' as a role, but FortiGate administrative access has no such default identity, so this option is incorrect.

Trap 2: root

FortiGate does not have a Unix-style 'root' administrative account. Although the underlying operating system includes Linux-like components, FortiOS handles administrator authentication through its own privilege model, and 'root' is not a valid default username in the local user table. Attempting to log in as 'root' would fail because no such account exists in the default configuration.

Trap 3: guest

The 'guest' account is not an administrative identity on FortiGate. FortiOS creates guest users separately for scenarios such as captive portals or guest Wi-Fi, and those accounts are limited to network-access authentication rather than device management. No guest account is provisioned with super_admin or any other administrative privilege, so it cannot be the default admin.

Study all System and Network Administration common traps →

A
master
Why wrong: The name 'master' is not a default account in FortiOS. FortiGate is configured with only the factory bootstrap account 'admin', and there is no 'master' user created in the local user database. Some switching or wireless equipment uses 'master' as a role, but FortiGate administrative access has no such default identity, so this option is incorrect.
B
root
Why wrong: FortiGate does not have a Unix-style 'root' administrative account. Although the underlying operating system includes Linux-like components, FortiOS handles administrator authentication through its own privilege model, and 'root' is not a valid default username in the local user table. Attempting to log in as 'root' would fail because no such account exists in the default configuration.
C
guest
Why wrong: The 'guest' account is not an administrative identity on FortiGate. FortiOS creates guest users separately for scenarios such as captive portals or guest Wi-Fi, and those accounts are limited to network-access authentication rather than device management. No guest account is provisioned with super_admin or any other administrative privilege, so it cannot be the default admin.
D
admin
The correct default administrative account is 'admin'. Every FortiGate ships with this local account, which is assigned the 'super_admin' profile and provides full control through the web GUI and CLI. On first login, administrators are required to set a password for the admin account, ensuring the factory state does not remain with an empty secret.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full network assurance explanation →

An administrator needs to configure a FortiGate to send logs to two different syslog servers for redundancy. Which configuration method should be used?

Trap 1: Configure two separate log settings for each server.

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.

Trap 2: Configure one syslog server and use a load balancer.

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.

Trap 3: Use a FortiAnalyzer to forward logs to syslog servers.

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.

Study all System and Network Administration common traps →

A
Under 'config log syslogd setting', set 'status enable' and then add multiple servers using 'set server <ip1> <ip2>'.
This is the correct method. In FortiOS, the `config log syslogd setting` block is the dedicated configuration object for remote syslog logging. By setting `status enable` and then using `set server <ip1> <ip2>`, you define a space-separated list of up to four syslog server IP addresses. The FortiGate will send logs to every address in that list simultaneously, providing direct, native redundancy without any additional equipment.
B
Configure two separate log settings for each server.
Why wrong: 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.
C
Configure one syslog server and use a load balancer.
Why wrong: 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.
D
Use a FortiAnalyzer to forward logs to syslog servers.
Why wrong: 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.

Full breakdown with real-world context →

Question 8mediummultiple choice

Read the full System and Network Administration explanation →

Refer to the exhibit. The administrator notices that traffic from internal to wan1 is being logged, but the logs do not show the original source IP. What is the most likely reason?

Exhibit

config firewall policy
    edit 1
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
    next
end

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

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.

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

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.

Trap 3: The policy action is 'accept' without authentication.

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.

Study all System and Network Administration common traps →

A
The schedule is set to 'always', causing no time-based logging.
Why wrong: 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.
B
NAT is enabled, so the source IP is replaced with the public IP.
NAT is enabled, so FortiGate rewrites the packet's source address to the egress interface's public IP before forwarding it. The remote server or packet capture will see the public IP, not the original private client address. In the traffic log, the original source IP is still available in the srcip field while the translated address appears in natip, but for traffic leaving the network the observable source has been replaced.
C
Logging is set to 'all' but only 'utma' events are logged.
Why wrong: 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.
D
The policy action is 'accept' without authentication.
Why wrong: 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.

Full breakdown with real-world context →

Question 9easymulti select

Read the full System and Network Administration explanation →

Which TWO of the following are prerequisites for configuring a high availability (HA) cluster on FortiGate? (Choose two.)

Trap 1: An HA heartbeat interface must be a dedicated interface.

For FortiGate HA, the heartbeat link does not have to be a dedicated physical interface. While using a dedicated interface is a best practice to isolate heartbeat traffic from data traffic and improve stability, FortiGate supports sharing heartbeat on an interface that also carries user traffic, such as a VLAN or a physical port. The key requirement is that the heartbeat interface must be reachable between the two units and configured appropriately, not that it is exclusively reserved for HA communication.

Trap 2: All interfaces must be configured with static IP addresses.

FortiGate HA does not mandate static IP addresses on all interfaces. In fact, many deployments use DHCP for WAN or other uplinks, and HA configuration synchronizes the learned or configured addresses; however, certain HA management or dedicated heartbeat interfaces may need static or well-known addresses to ensure connectivity. The actual prerequisites focus on firmware, hardware model, and specific HA settings like interface monitoring, not on every interface having a static IP.

Trap 3: The configuration must be identical on both units.

The configuration does not need to be identical on both units before HA is established, because the primary unit's configuration is automatically synchronized to the secondary unit during HA formation. The whole purpose of HA is to replicate configuration from the active unit to the standby unit, so pre-matching configurations is unnecessary. What matters is that both units have a minimal configuration to support HA (e.g., administrative access, heartbeat), and the primary's full configuration is then pushed to the peer.

Study all System and Network Administration common traps →

A
An HA heartbeat interface must be a dedicated interface.
Why wrong: For FortiGate HA, the heartbeat link does not have to be a dedicated physical interface. While using a dedicated interface is a best practice to isolate heartbeat traffic from data traffic and improve stability, FortiGate supports sharing heartbeat on an interface that also carries user traffic, such as a VLAN or a physical port. The key requirement is that the heartbeat interface must be reachable between the two units and configured appropriately, not that it is exclusively reserved for HA communication.
B
All interfaces must be configured with static IP addresses.
Why wrong: FortiGate HA does not mandate static IP addresses on all interfaces. In fact, many deployments use DHCP for WAN or other uplinks, and HA configuration synchronizes the learned or configured addresses; however, certain HA management or dedicated heartbeat interfaces may need static or well-known addresses to ensure connectivity. The actual prerequisites focus on firmware, hardware model, and specific HA settings like interface monitoring, not on every interface having a static IP.
C
The FortiGate units must be running the same firmware version.
Running the same firmware version is a strict prerequisite for FortiGate HA. Both units must have the exact same FortiOS build, including any minor patches or hotfixes, because differences in firmware can cause protocol incompatibilities and prevent successful HA synchronization. Even minor version discrepancies can break the HA heartbeat and failover behavior, so Fortinet requires matching firmware before enabling HA.
D
The configuration must be identical on both units.
Why wrong: The configuration does not need to be identical on both units before HA is established, because the primary unit's configuration is automatically synchronized to the secondary unit during HA formation. The whole purpose of HA is to replicate configuration from the active unit to the standby unit, so pre-matching configurations is unnecessary. What matters is that both units have a minimal configuration to support HA (e.g., administrative access, heartbeat), and the primary's full configuration is then pushed to the peer.
E
The FortiGate units must be the same model.
The FortiGate units must be the same model for HA to work. Different models have different hardware capabilities, such as CPU, memory, and interface counts, and Fortinet's HA implementation requires matching hardware to ensure consistent performance and configuration compatibility. A FortiGate 100F cannot form an HA cluster with a 200F, even if running the same firmware, because the resource capacities and interface mappings differ.

Full breakdown with real-world context →

Question 10hardmulti select

Read the full System and Network Administration explanation →

Which THREE statements about FortiGate's 'config system global' settings are true? (Choose three.)

Trap 1: The 'trusthost' setting restricts administrative access to specific…

The 'trusthost' parameter is not part of config system global; it is configured under individual administrator accounts (config system admin) to limit which source IP addresses that admin can log in from. While trusthost does restrict administrative access, it is an admin-scoped setting rather than a global device-wide parameter. The exam traps you into thinking it belongs with global security settings, but it lives elsewhere.

Trap 2: The 'allowaccess' setting controls which protocols are allowed on…

The 'allowaccess' setting is configured under config system interface, not under config system global, and it specifies which management protocols (such as HTTPS, HTTP, SSH, PING) are allowed on that specific interface. It determines how administrators can reach the FortiGate for management through that interface, not global traffic forwarding. Because it is interface-scoped, different interfaces can have different allowaccess lists.

Study all System and Network Administration common traps →

A
The 'trusthost' setting restricts administrative access to specific source IPs.
Why wrong: The 'trusthost' parameter is not part of config system global; it is configured under individual administrator accounts (config system admin) to limit which source IP addresses that admin can log in from. While trusthost does restrict administrative access, it is an admin-scoped setting rather than a global device-wide parameter. The exam traps you into thinking it belongs with global security settings, but it lives elsewhere.
B
The 'admin-login-retry-limit' setting limits the number of failed login attempts before lockout.
This is correct because 'admin-login-retry-limit' is a global security setting under config system global. It defines the maximum number of consecutive failed administrator login attempts (default is 3) before the source IP is locked out for a period (admin-lockout-duration). This helps mitigate brute-force attacks on management interfaces and applies across all administrators and access methods.
C
The 'hostname' setting sets the device name displayed in the GUI.
The 'hostname' setting under config system global defines the device's network identity, displayed in the GUI, CLI prompt, and as the SNMP sysName. It is device-wide and not tied to any specific admin or interface. Changing it requires a system administrator and takes effect immediately without rebooting.
D
The 'allowaccess' setting controls which protocols are allowed on an interface.
Why wrong: The 'allowaccess' setting is configured under config system interface, not under config system global, and it specifies which management protocols (such as HTTPS, HTTP, SSH, PING) are allowed on that specific interface. It determines how administrators can reach the FortiGate for management through that interface, not global traffic forwarding. Because it is interface-scoped, different interfaces can have different allowaccess lists.
E
The 'timezone' setting sets the FortiGate's local time zone.
The 'timezone' setting under config system global sets the device's local time zone, which determines the timestamps used in logs, reports, and scheduled tasks. It supports IANA timezone names, such as 'America/New_York', and is critical for accurate auditing across multi-site deployments. This global setting affects all administrators and log entries uniformly.

Full breakdown with real-world context →

Question 11mediummultiple choice

Study the full SD-WAN breakdown →

A company has a FortiGate 200F with FortiOS 7.2 and two ISPs (WAN1: 100 Mbps, WAN2: 50 Mbps). The company uses SD-WAN to load balance outbound internet traffic. Recently, the company added a new VoIP application that requires low latency and jitter. The administrator configured an SD-WAN rule to match the VoIP traffic and set the strategy to 'best quality' with a performance SLA measuring latency and jitter. However, after testing, the VoIP traffic is still using WAN2 (the slower link) even when WAN1 has lower latency. The performance SLA shows both links meeting the SLA thresholds. What is the most likely reason?

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

NPU offloading does not bypass SD-WAN rules.

Trap 2: The administrator needs to enable 'set internet-service enable' on…

Internet service is for specific applications, not required.

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

The administrator tested and confirmed the rule is applied.

Study all System and Network Administration common traps →

A
The 'best quality' strategy uses bandwidth as a tiebreaker when SLA is met.
Fortinet's best quality uses bandwidth to break ties.
B
The VoIP traffic is being offloaded by NPU bypassing SD-WAN.
Why wrong: NPU offloading does not bypass SD-WAN rules.
C
The administrator needs to enable 'set internet-service enable' on the rule.
Why wrong: Internet service is for specific applications, not required.
D
The SD-WAN rule is not matching the VoIP traffic correctly.
Why wrong: The administrator tested and confirmed the rule is applied.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full System and Network Administration explanation →

A large enterprise is deploying a FortiGate 600F as the perimeter firewall. The security team requires that all administrative access (SSH, HTTPS, and Ping) to the FortiGate must be restricted to a dedicated management network (10.10.10.0/24). Additionally, any failed login attempt from outside the management network should be logged and the source IP should be blocked for 30 minutes. The administrator has configured a local-in policy to deny all administrative access from non-management networks and enabled logging. However, the administrator wants to automatically block the offending IPs. The FortiGate is not connected to any FortiAnalyzer or FortiManager. What should the administrator do to achieve this?

Trap 1: Use a FortiAnalyzer to generate alerts and send to SIEM.

FortiAnalyzer's role is to aggregate logs and generate alerts that can be forwarded to an external SIEM for monitoring and reporting, but it does not enforce security actions on the FortiGate. In this environment, no FortiAnalyzer is present, so the solution is architecturally invalid. Even when it is deployed, it only provides visibility—it cannot dynamically add IPs to a block list, leaving the response manual and non-automated.

Trap 2: Configure a firewall policy to block the offending IPs manually…

Manually configuring a firewall policy from logs is a reactive process that requires an administrator to detect the attack, interpret the logs, and create a rule to block the IP. This is not automated and introduces significant response time, during which the FortiGate management interface remains vulnerable. Furthermore, a regular firewall policy applies to transit traffic passing through the device, not to local-in traffic destined to the FortiGate itself; a local-in policy would be required, so a manually created firewall policy may not even block the hostile source.

Trap 3: Enable 'set block-session-ttl' on the local-in policy.

The `set block-session-ttl` option on a local-in policy only controls the time-to-live of a denied session's session table entry; it is a per-session parameter that does not create a persistent IP block. Once the session TTL expires, the next packet from that source creates a new session and is denied again, but the source IP is never added to an address or block list. Thus it fails to provide the ongoing, IP-based blocking needed to stop repeated attacks, unlike the automation stitch that adds the IP to a blocked list for a defined period.

Study all System and Network Administration common traps →

A
Create an automation stitch that triggers on local-in policy logging and adds the source IP to a blocked list via CLI script.
An automation stitch is the correct approach because it creates an event-triggered workflow: a local-in policy log entry (e.g., 'local-in denial') fires an automation trigger, which then executes a CLI script to add the offending source IP to a configured blocked address list. This provides immediate, autonomous enforcement without waiting for human intervention, and it directly addresses the source IP at the device level.
B
Use a FortiAnalyzer to generate alerts and send to SIEM.
Why wrong: FortiAnalyzer's role is to aggregate logs and generate alerts that can be forwarded to an external SIEM for monitoring and reporting, but it does not enforce security actions on the FortiGate. In this environment, no FortiAnalyzer is present, so the solution is architecturally invalid. Even when it is deployed, it only provides visibility—it cannot dynamically add IPs to a block list, leaving the response manual and non-automated.
C
Configure a firewall policy to block the offending IPs manually based on logs.
Why wrong: Manually configuring a firewall policy from logs is a reactive process that requires an administrator to detect the attack, interpret the logs, and create a rule to block the IP. This is not automated and introduces significant response time, during which the FortiGate management interface remains vulnerable. Furthermore, a regular firewall policy applies to transit traffic passing through the device, not to local-in traffic destined to the FortiGate itself; a local-in policy would be required, so a manually created firewall policy may not even block the hostile source.
D
Enable 'set block-session-ttl' on the local-in policy.
Why wrong: The `set block-session-ttl` option on a local-in policy only controls the time-to-live of a denied session's session table entry; it is a per-session parameter that does not create a persistent IP block. Once the session TTL expires, the next packet from that source creates a new session and is denied again, but the source IP is never added to an address or block list. Thus it fails to provide the ongoing, IP-based blocking needed to stop repeated attacks, unlike the automation stitch that adds the IP to a blocked list for a defined period.

Full breakdown with real-world context →

Question 13easymultiple choice

Read the full System and Network Administration explanation →

Which command is used to display the current FortiGate firmware version?

Trap 1: get system statistics

The 'get system statistics' command exposes real-time traffic counters, including session counts, packet rates, and bandwidth utilization across interfaces. While valuable for monitoring data-plane activity, it does not reference the FortiOS build, version number, or patch level. Therefore, it cannot reveal the installed firmware release.

Trap 2: get hardware status

The 'get hardware status' command inventories physical components such as CPU temperature, fan speed, power supply health, and chassis model. Although it reports the platform's hardware identity, it never reads the firmware version because firmware is stored as software on flash memory. To find the FortiOS version, you must query the system-level status instead.

Trap 3: get system performance status

The 'get system performance status' command delivers a snapshot of CPU load, memory usage, and session setup rates, focusing on system resource consumption under live traffic. It does not include any software version attributes, such as the FortiOS build or branch. Hence, while useful for capacity planning and bottleneck analysis, it cannot answer firmware-version queries.

Study all System and Network Administration common traps →

A
get system statistics
Why wrong: The 'get system statistics' command exposes real-time traffic counters, including session counts, packet rates, and bandwidth utilization across interfaces. While valuable for monitoring data-plane activity, it does not reference the FortiOS build, version number, or patch level. Therefore, it cannot reveal the installed firmware release.
B
get hardware status
Why wrong: The 'get hardware status' command inventories physical components such as CPU temperature, fan speed, power supply health, and chassis model. Although it reports the platform's hardware identity, it never reads the firmware version because firmware is stored as software on flash memory. To find the FortiOS version, you must query the system-level status instead.
C
get system status
The 'get system status' command is the standard FortiGate CLI command to display the current firmware version, along with build number, serial number, hostname, uptime, and the configured operating mode. This output is essential for troubleshooting, verifying patch compliance, and confirming that the device is running an expected FortiOS release. It is the authoritative source for firmware identification.
D
get system performance status
Why wrong: The 'get system performance status' command delivers a snapshot of CPU load, memory usage, and session setup rates, focusing on system resource consumption under live traffic. It does not include any software version attributes, such as the FortiOS build or branch. Hence, while useful for capacity planning and bottleneck analysis, it cannot answer firmware-version queries.

Full breakdown with real-world context →

Question 14easymultiple choice

Read the full System and Network Administration explanation →

An administrator needs to configure a FortiGate to allow web traffic from the internal network to the Internet. The internal network is 192.168.1.0/24 and the WAN interface is port1 with IP 203.0.113.1. Which firewall policy is correct?

Trap 1: Source: port1, Destination: internal, Service: HTTP/HTTPS, Action:…

Reversing the source and destination interfaces would create an inbound policy: traffic arriving on port1 (the external/Internet-facing interface) is allowed to reach the internal network. This would permit external users to access internal resources, which is the exact opposite of what the administrator needs—allowing internal users to reach the web. Additionally, for outbound web traffic, the source must be the internal network, not the external side, so this policy's direction is fundamentally incorrect.

Trap 2: Source: external, Destination: internal, Service: HTTP/HTTPS,…

This policy also describes inbound traffic, but it uses 'external' as the source and 'internal' as the destination, meaning it will allow external hosts to connect to internal servers over HTTP/HTTPS. Such a policy is typically used to expose an internal web server to the Internet (e.g., a DMZ or port-forwarding scenario), not to give internal users web access. Since the requirement is for internal users to initiate web requests, the source should be 'internal' and the destination should be the outgoing interface 'port1', making this option wrong in its traffic direction.

Trap 3: Source: internal, Destination: port1, Service: ALL, Action: ACCEPT

While this policy has the correct source and destination (internal to port1) and Action ACCEPT, it allows ALL services, not just HTTP/HTTPS. This violates the principle of least privilege because internal users would be able to send any traffic (e.g., Telnet, SSH, SMTP, or other protocols) to the Internet, significantly expanding the attack surface. The administrator's goal is to permit web browsing only, so the Service should be specifically limited to HTTP/HTTPS; using ALL is overly permissive and a common security misconfiguration.

Study all System and Network Administration common traps →

A
Source: internal, Destination: port1, Service: HTTP/HTTPS, Action: ACCEPT
This policy correctly implements outbound web access: traffic originates from the internal network, exits via the port1 interface that connects to the Internet, and is restricted to HTTP/HTTPS services. Because FortiGate firewall policies are interface-based and stateful, this single policy also allows the corresponding return traffic from external web servers to flow back to the internal users without an explicit reverse rule. The Action ACCEPT ensures that the traffic is permitted, aligning with the required use case.
B
Source: port1, Destination: internal, Service: HTTP/HTTPS, Action: ACCEPT
Why wrong: Reversing the source and destination interfaces would create an inbound policy: traffic arriving on port1 (the external/Internet-facing interface) is allowed to reach the internal network. This would permit external users to access internal resources, which is the exact opposite of what the administrator needs—allowing internal users to reach the web. Additionally, for outbound web traffic, the source must be the internal network, not the external side, so this policy's direction is fundamentally incorrect.
C
Source: external, Destination: internal, Service: HTTP/HTTPS, Action: ACCEPT
Why wrong: This policy also describes inbound traffic, but it uses 'external' as the source and 'internal' as the destination, meaning it will allow external hosts to connect to internal servers over HTTP/HTTPS. Such a policy is typically used to expose an internal web server to the Internet (e.g., a DMZ or port-forwarding scenario), not to give internal users web access. Since the requirement is for internal users to initiate web requests, the source should be 'internal' and the destination should be the outgoing interface 'port1', making this option wrong in its traffic direction.
D
Source: internal, Destination: port1, Service: ALL, Action: ACCEPT
Why wrong: While this policy has the correct source and destination (internal to port1) and Action ACCEPT, it allows ALL services, not just HTTP/HTTPS. This violates the principle of least privilege because internal users would be able to send any traffic (e.g., Telnet, SSH, SMTP, or other protocols) to the Internet, significantly expanding the attack surface. The administrator's goal is to permit web browsing only, so the Service should be specifically limited to HTTP/HTTPS; using ALL is overly permissive and a common security misconfiguration.

Full breakdown with real-world context →

Question 15mediummultiple choice

Read the full System and Network Administration explanation →

A FortiGate administrator notices that the device's disk usage is critically high, causing logging failures. The administrator wants to free up space without losing important logs. Which action should be taken first?

Trap 1: Delete all existing log files

Deleting all existing log files frees disk space immediately but is a destructive, one-time action that permanently erases forensic data, audit trails, and historical records needed for incident response, troubleshooting, or regulatory compliance. It treats the symptom without addressing the root cause, so the disk will again fill as new logs accumulate — making it an unsustainable 'band-aid' that sacrifices valuable evidence.

Trap 2: Disable logging to the local disk

Disabling logging to the local disk stops the device from writing new log entries, but it does not actively shrink the existing log files; it only halts further growth. This radically reduces security visibility — the device can no longer retain critical event information locally for troubleshooting or compliance — making it a disproportionate response that leaves the FortiGate blind to historical and ongoing threats.

Trap 3: Increase the disk retention period

Increasing the disk retention period would instruct the FortiGate to keep logs for a longer time before overwriting or purging them, which necessarily consumes more disk space over time, not less. This option is logically opposite to the administrator's goal of reducing disk usage and would accelerate the disk-full condition rather than alleviating it.

Study all System and Network Administration common traps →

A
Delete all existing log files
Why wrong: Deleting all existing log files frees disk space immediately but is a destructive, one-time action that permanently erases forensic data, audit trails, and historical records needed for incident response, troubleshooting, or regulatory compliance. It treats the symptom without addressing the root cause, so the disk will again fill as new logs accumulate — making it an unsustainable 'band-aid' that sacrifices valuable evidence.
B
Configure log compression
Configuring log compression on a FortiGate (typically using gzip) reduces the on-disk footprint of stored logs without removing any data, preserving full log fidelity for later analysis. This non-destructive approach directly addresses disk-full pressure by shrinking existing and future log files, and it can be combined with retention policies to keep more history within the same space.
C
Disable logging to the local disk
Why wrong: Disabling logging to the local disk stops the device from writing new log entries, but it does not actively shrink the existing log files; it only halts further growth. This radically reduces security visibility — the device can no longer retain critical event information locally for troubleshooting or compliance — making it a disproportionate response that leaves the FortiGate blind to historical and ongoing threats.
D
Increase the disk retention period
Why wrong: Increasing the disk retention period would instruct the FortiGate to keep logs for a longer time before overwriting or purging them, which necessarily consumes more disk space over time, not less. This option is logically opposite to the administrator's goal of reducing disk usage and would accelerate the disk-full condition rather than alleviating it.

Full breakdown with real-world context →

Question 16hardmultiple choice

Review the full routing breakdown →

Refer to the exhibit. The FortiGate has two default routes. The administrator attempts to ping 8.8.8.8 from the CLI and receives no response. What is the most likely reason?

Exhibit

Refer to the exhibit.
config router static
    edit 1
        set device port1
        set gateway 203.0.113.1
        set dst 0.0.0.0 0.0.0.0
        set distance 10
    next
    edit 2
        set device port2
        set gateway 10.0.0.1
        set dst 0.0.0.0 0.0.0.0
        set distance 20
    next
end

Trap 1: The second route is overwriting the first route

FortiGate does not replace a lower-distance route with a higher-distance route when the destination prefix is identical. The routing table (RIB) can hold multiple static routes to 0.0.0.0/0 as long as their administrative distances differ, and the router selects the one with the lowest distance as the active route. The distance-20 route remains in the RIB as a backup candidate, so it is not overwriting or deleting the distance-10 route.

Trap 2: Both routes are equal-cost and load-balancing is not working

Equal-cost multipath (ECMP) load balancing requires routes to have the same administrative distance and same metric (cost) to the same destination. Here the distances are 10 and 20, so the routes are not equal-cost; only the distance-10 route is installed as the preferred route, and the distance-20 route is a floating static backup. Therefore, failing to see load balancing is not a misconfiguration—it is expected behavior when distances differ.

Trap 3: The configuration is invalid because duplicate default routes are…

FortiGate explicitly allows multiple default routes (0.0.0.0/0) in the configuration, provided they are distinguishable by metrics or administrative distances. Having two default static routes with distances 10 and 20 is a valid design for link redundancy, and the configuration will be accepted by the CLI or GUI. Duplicate default routes are only invalid if they have the exact same distance and metric and the platform does not support ECMP, but FortiGate does support it; thus, this is not the reason traffic is failing.

Study all System and Network Administration common traps →

A
The second route is overwriting the first route
Why wrong: FortiGate does not replace a lower-distance route with a higher-distance route when the destination prefix is identical. The routing table (RIB) can hold multiple static routes to 0.0.0.0/0 as long as their administrative distances differ, and the router selects the one with the lowest distance as the active route. The distance-20 route remains in the RIB as a backup candidate, so it is not overwriting or deleting the distance-10 route.
B
Both routes are equal-cost and load-balancing is not working
Why wrong: Equal-cost multipath (ECMP) load balancing requires routes to have the same administrative distance and same metric (cost) to the same destination. Here the distances are 10 and 20, so the routes are not equal-cost; only the distance-10 route is installed as the preferred route, and the distance-20 route is a floating static backup. Therefore, failing to see load balancing is not a misconfiguration—it is expected behavior when distances differ.
C
The configuration is invalid because duplicate default routes are not allowed
Why wrong: FortiGate explicitly allows multiple default routes (0.0.0.0/0) in the configuration, provided they are distinguishable by metrics or administrative distances. Having two default static routes with distances 10 and 20 is a valid design for link redundancy, and the configuration will be accepted by the CLI or GUI. Duplicate default routes are only invalid if they have the exact same distance and metric and the platform does not support ECMP, but FortiGate does support it; thus, this is not the reason traffic is failing.
D
The gateway 203.0.113.1 (port1) is unreachable
The route via 203.0.113.1 on port1 has an administrative distance of 10, making it the preferred route for all traffic. If that next-hop gateway becomes unreachable—for instance, port1 goes down, the connected network fails, or ARP resolution for 203.0.113.1 fails—the active route is removed or becomes unusable. FortiGate will not immediately fail over to the distance-20 route unless the primary route is completely removed; in many scenarios, traffic is dropped because the lower-distance route is still considered valid in the RIB but cannot forward packets. Thus, unreachability of the primary gateway directly explains the total loss of connectivity.

Full breakdown with real-world context →

Question 17mediummulti select

Read the full System and Network Administration explanation →

Which TWO configuration changes can reduce the risk of unauthorized administrative access to a FortiGate?

Trap 1: Use the default 'admin' account for all administrators

Using the default 'admin' account is risky because the username is publicly known, enabling attackers to focus solely on password cracking. It also lacks individual accountability since multiple administrators share one identity, making audits and per-user MFA impossible. Fortinet recommends creating unique named administrators with granular permissions and two-factor authentication.

Trap 2: Set a simple password for ease of use

Setting a simple password for ease of use directly undermines security because trivial passwords are easily guessed or cracked with dictionary attacks. FortiOS enforces password complexity and length policies; a weak password can quickly lead to full device compromise. Always use long, complex passphrases and consider MFA for administrative accounts.

Trap 3: Disable both HTTPS and HTTP administrative access

Disabling both HTTPS and HTTP administrative access would eliminate web-based management entirely, leaving only CLI over SSH or serial connection, which is an overly drastic step that reduces usability and operational flexibility. More importantly, HTTPS is a secure encrypted channel when properly configured with strong ciphers; the risk comes from weak authentication, not the protocol itself. The recommended approach is to keep HTTPS, enforce trusted hosts, and disable insecure HTTP instead.

Study all System and Network Administration common traps →

A
Use the default 'admin' account for all administrators
Why wrong: Using the default 'admin' account is risky because the username is publicly known, enabling attackers to focus solely on password cracking. It also lacks individual accountability since multiple administrators share one identity, making audits and per-user MFA impossible. Fortinet recommends creating unique named administrators with granular permissions and two-factor authentication.
B
Restrict administrative access to trusted hosts
Restricting administrative access to trusted hosts limits which source IP addresses can initiate management sessions to the FortiGate. By configuring an allowlist of management station IPs on each admin user or the administrative interface, you drastically reduce the attack surface and block brute-force attempts from the internet. This is a fundamental, highly effective hardening measure.
C
Change the default administrative port
Changing the default administrative port (e.g., 443/TCP for HTTPS, 22/TCP for SSH) hides the management interface from automated scanners that probe common ports. While this is security-by-obscurity and not a primary defense, it significantly reduces opportunistic scanning noise and forces attackers to actively discover the service. It should always accompany strong authentication and host restrictions.
D
Set a simple password for ease of use
Why wrong: Setting a simple password for ease of use directly undermines security because trivial passwords are easily guessed or cracked with dictionary attacks. FortiOS enforces password complexity and length policies; a weak password can quickly lead to full device compromise. Always use long, complex passphrases and consider MFA for administrative accounts.
E
Disable both HTTPS and HTTP administrative access
Why wrong: Disabling both HTTPS and HTTP administrative access would eliminate web-based management entirely, leaving only CLI over SSH or serial connection, which is an overly drastic step that reduces usability and operational flexibility. More importantly, HTTPS is a secure encrypted channel when properly configured with strong ciphers; the risk comes from weak authentication, not the protocol itself. The recommended approach is to keep HTTPS, enforce trusted hosts, and disable insecure HTTP instead.

Full breakdown with real-world context →

Question 18hardmulti select

Read the full System and Network Administration explanation →

Which THREE configuration steps are required to enable transparent proxy mode on a FortiGate?

Trap 1: Enable web proxy globally under config system settings

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.

Trap 2: Assign an IP address to the proxy interface

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.

Study all System and Network Administration common traps →

A
Create a firewall policy with explicit proxy enabled
Explicit proxy traffic must be matched by a firewall policy that has explicit proxy enabled. This policy tells the FortiGate which source/destination traffic should be processed by the proxy engine rather than being passed through unproxied. Without this policy, even with bridging and NAT disabled, the proxy will not inspect any sessions. The policy also defines the proxy profile and applicable security features for the proxied traffic.
B
Enable web proxy globally under config system settings
Why wrong: 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.
C
Disable NAT on the firewall policy
Transparent proxy operates at Layer 2 and must preserve the original source IP from the client to the web server. If NAT were enabled on the firewall policy, the proxy would perform source address translation, which would break the transparent traffic flow and require routing instead of bridging. Disabling NAT ensures the proxy sees the real client address and that responses are returned through the same Layer 2 bridge. Thus, NAT is turned off on the explicit proxy firewall policy to maintain transparency.
D
Configure a software switch or 802.1Q VLAN trunk to bridge the interfaces
To pass traffic transparently (without routing), the physical interfaces on both sides of the FortiGate must be bridged together. You create a software switch or an 802.1Q VLAN trunk to build the Layer 2 bridge, and then the FortiGate is injected as a bump in the wire. This bridge has a single management IP, and the proxy listens for traffic on the bridge's IP. Without the bridging configuration, the FortiGate would attempt to route packets and would not be transparent.
E
Assign an IP address to the proxy interface
Why wrong: 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.

Full breakdown with real-world context →

Question 19mediumdrag order

Review the full routing breakdown →

Drag and drop the steps to configure a static route on a FortiGate firewall into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Enter config router static, then edit route, then set gateway, then…

This order is incorrect because the gateway should be entered after defining the destination network and the outgoing interface. Although FortiGate CLI accepts set commands in any order, the device parameter establishes the egress interface that must be able to reach the gateway IP; assigning the gateway first risks referencing an interface that is not yet selected, leading to a route that fails validation or is unintentionally associated with the wrong interface. Additionally, the destination is the primary key for route matching, so it should precede optional fields like gateway for clarity and to avoid configuration errors.

Trap 2: Enter config router static, then set destination, then set device,…

This order is fundamentally flawed because the 'edit route' command must be executed before any 'set' statements to create or select the specific static route entry. Without entering the edit context, the set commands are issued at the 'config router static' table level, where no destination, device, or gateway attributes exist; FortiGate will return a syntax error or the settings will be discarded, so the route is never properly configured. Only after a valid 'edit <seq>' are the parameters accepted and stored for that route entry.

Trap 3: Enter config router static, then edit route, then set device, then…

Setting the destination after 'end' means the change is applied outside the route edit context, so the destination will not be part of the route. The destination must be set before exiting the edit mode.

Study all System and Network Administration common traps →

A
Enter config router static, then edit route with sequence number, then set destination, then set device, then set gateway, then end
This order follows the FortiGate CLI: first enter the static route configuration context, then add or edit a route entry, then configure the destination network, outgoing interface, and next-hop gateway, and finally apply the changes with 'end'.
B
Enter config router static, then edit route, then set gateway, then set destination, then set device, then end
Why wrong: This order is incorrect because the gateway should be entered after defining the destination network and the outgoing interface. Although FortiGate CLI accepts set commands in any order, the device parameter establishes the egress interface that must be able to reach the gateway IP; assigning the gateway first risks referencing an interface that is not yet selected, leading to a route that fails validation or is unintentionally associated with the wrong interface. Additionally, the destination is the primary key for route matching, so it should precede optional fields like gateway for clarity and to avoid configuration errors.
C
Enter config router static, then set destination, then set device, then set gateway, then edit route, then end
Why wrong: This order is fundamentally flawed because the 'edit route' command must be executed before any 'set' statements to create or select the specific static route entry. Without entering the edit context, the set commands are issued at the 'config router static' table level, where no destination, device, or gateway attributes exist; FortiGate will return a syntax error or the settings will be discarded, so the route is never properly configured. Only after a valid 'edit <seq>' are the parameters accepted and stored for that route entry.
D
Enter config router static, then edit route, then set device, then set gateway, then end, then set destination
Why wrong: Setting the destination after 'end' means the change is applied outside the route edit context, so the destination will not be part of the route. The destination must be set before exiting the edit mode.

Full breakdown with real-world context →

Question 20mediumdrag order

Read the full System and Network Administration explanation →

Drag and drop the steps to troubleshoot a user unable to access the internet through FortiGate into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Check routing, then check NAT rules, then check firewall policies,…

Starting with routing and NAT before firewall policies is inefficient because the FortiGate evaluates policy as the first logical gate; if traffic is denied by a policy, no route or NAT rule can rescue it, and you may spend time analyzing routing tables for packets that are never forwarded. Additionally, placing review logs before packet capture inverts the correct forensic flow: logs often only show high-level results (e.g., 'denied by policy'), while a packet capture provides the raw packets needed to understand why the session failed, such as NAT port exhaustion or asymmetric routing. A proper diagnosis should eliminate the most common policy issues first, then verify NAT and routing, because both NAT and routing assume a policy already allowed the session.

Trap 2: Review logs, then check firewall policies, then check NAT rules,…

Beginning with logs is misleading because a log entry only tells you that a session was dropped or accepted, not which configuration object caused the action—for example, a log might show 'action=deny' but you still need to check the firewall policy to see which policy did the denial and why. It also risks anchoring you to a single log record without context; you might miss that the traffic was never logged because it was dropped before the policy check, such as on the incoming interface due to IPS or route lookup failure. Furthermore, saving packet capture for last means you may have already committed to a hypothesis based on logs, whereas capturing earlier—after policy, NAT, and routing checks—would give you decisive packet-level evidence to confirm the actual path.

Trap 3: Check NAT rules, then perform packet capture, then check firewall…

Checking NAT rules before firewall policies is inherently flawed because a FortiGate does not even consult the NAT table until the session has matched a policy; so a NAT rule you diagnose may be irrelevant if the traffic is denied by policy or falls into an implicit deny. Performing packet capture immediately after NAT and before policy checks will capture traffic indiscriminately, including packets that are about to be dropped by policy, which wastes analysis time and can hide the real root cause behind irrelevant packets. Even worse, this order places routing last, yet routing is critical for the return path and for determining which interface the packet egresses; without checking routing, you might capture ingress packets and think the problem is NAT when it is actually a missing route. A correct sequence must follow the dataplane's actual evaluation order: policy, NAT, routing, then capture, with logs used only for final confirmation.

Study all System and Network Administration common traps →

A
Check firewall policies, then check NAT rules, then check routing, then perform packet capture, then review logs
This sequence mirrors the FortiOS session creation order: traffic must match a firewall policy first, and if no policy permits it, the session is denied before any NAT or routing decision is consulted. After a policy match, Destination NAT (VIP) and Source NAT are evaluated via the NAT table, followed by routing to choose the egress interface and next hop. Only after those configuration layers are verified does a packet capture make sense, because it will show traffic that already passed or failed those checks. Reviewing traffic logs last lets you correlate the captured packets with log records, confirming whether the session was allowed, denied, or stuck due to NAT or routing misconfiguration.
B
Check routing, then check NAT rules, then check firewall policies, then review logs, then perform packet capture
Why wrong: Starting with routing and NAT before firewall policies is inefficient because the FortiGate evaluates policy as the first logical gate; if traffic is denied by a policy, no route or NAT rule can rescue it, and you may spend time analyzing routing tables for packets that are never forwarded. Additionally, placing review logs before packet capture inverts the correct forensic flow: logs often only show high-level results (e.g., 'denied by policy'), while a packet capture provides the raw packets needed to understand why the session failed, such as NAT port exhaustion or asymmetric routing. A proper diagnosis should eliminate the most common policy issues first, then verify NAT and routing, because both NAT and routing assume a policy already allowed the session.
C
Review logs, then check firewall policies, then check NAT rules, then check routing, then perform packet capture
Why wrong: Beginning with logs is misleading because a log entry only tells you that a session was dropped or accepted, not which configuration object caused the action—for example, a log might show 'action=deny' but you still need to check the firewall policy to see which policy did the denial and why. It also risks anchoring you to a single log record without context; you might miss that the traffic was never logged because it was dropped before the policy check, such as on the incoming interface due to IPS or route lookup failure. Furthermore, saving packet capture for last means you may have already committed to a hypothesis based on logs, whereas capturing earlier—after policy, NAT, and routing checks—would give you decisive packet-level evidence to confirm the actual path.
D
Check NAT rules, then perform packet capture, then check firewall policies, then check routing, then review logs
Why wrong: Checking NAT rules before firewall policies is inherently flawed because a FortiGate does not even consult the NAT table until the session has matched a policy; so a NAT rule you diagnose may be irrelevant if the traffic is denied by policy or falls into an implicit deny. Performing packet capture immediately after NAT and before policy checks will capture traffic indiscriminately, including packets that are about to be dropped by policy, which wastes analysis time and can hide the real root cause behind irrelevant packets. Even worse, this order places routing last, yet routing is critical for the return path and for determining which interface the packet egresses; without checking routing, you might capture ingress packets and think the problem is NAT when it is actually a missing route. A correct sequence must follow the dataplane's actual evaluation order: policy, NAT, routing, then capture, with logs used only for final confirmation.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused System and Network Administration sessions

Start a System and Network Administration only practice session

Every question in these sessions is drawn from the System and Network Administration domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all System and Network Administration questions →Mixed NSE4 session

Frequently asked questions

What does the NSE4 exam test about System and Network Administration?: System and Network Administration questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just System and Network Administration questions in a focused session?: Yes — the session launcher on this page draws every question from the System and Network Administration domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other NSE4 topics?: Use the topic links above to move to related areas, or go back to the NSE4 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the NSE4 exam covers. They are not copied from any real exam or dump site.

System and Network Administration only

10 questions 20 questions 30 questions 50 questions

Mixed NSE4 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All NSE4 questions System and Network Administration domain overview NSE4 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

System and Network Administration practice questions

What to know about System and Network Administration

Common System and Network Administration exam traps

System and Network Administration questions

A company wants to ensure that administrative access to FortiGate is only allowed from the internal trusted network (192.168.1.0/24) and that all other access attempts are blocked. Which CLI command should the administrator configure first?

A FortiGate administrator is troubleshooting a high CPU usage issue. The 'get system performance status' command shows that the CPU usage is consistently above 80% with no traffic. Which of the following is the most likely cause?

An administrator needs to back up the FortiGate configuration to a TFTP server at 10.0.0.10. Which command should be used?

Refer to the exhibit. An administrator wants to enable SNMP access on the wan1 interface. Which of the following is the most efficient method?

Exhibit

An administrator is troubleshooting a FortiGate that is not passing traffic. The policy allows traffic, but the session table shows no sessions. Which THREE steps should the administrator take to diagnose the issue? (Choose three.)

What is the default administrative account on a FortiGate?

An administrator needs to configure a FortiGate to send logs to two different syslog servers for redundancy. Which configuration method should be used?

Refer to the exhibit. The administrator notices that traffic from internal to wan1 is being logged, but the logs do not show the original source IP. What is the most likely reason?

Exhibit

Which TWO of the following are prerequisites for configuring a high availability (HA) cluster on FortiGate? (Choose two.)

Which THREE statements about FortiGate's 'config system global' settings are true? (Choose three.)

Which command is used to display the current FortiGate firmware version?

An administrator needs to configure a FortiGate to allow web traffic from the internal network to the Internet. The internal network is 192.168.1.0/24 and the WAN interface is port1 with IP 203.0.113.1. Which firewall policy is correct?

A FortiGate administrator notices that the device's disk usage is critically high, causing logging failures. The administrator wants to free up space without losing important logs. Which action should be taken first?

Refer to the exhibit. The FortiGate has two default routes. The administrator attempts to ping 8.8.8.8 from the CLI and receives no response. What is the most likely reason?

Exhibit

Which TWO configuration changes can reduce the risk of unauthorized administrative access to a FortiGate?

Which THREE configuration steps are required to enable transparent proxy mode on a FortiGate?

Drag and drop the steps to configure a static route on a FortiGate firewall into the correct order.

Drag and drop the steps to troubleshoot a user unable to access the internet through FortiGate into the correct order.

Track your progress over time

Start a System and Network Administration only practice session

Related NSE4 topic practice pages