Troubleshooting practice questions

An administrator is troubleshooting high memory utilization on a FortiGate. They run 'get system performance status' and see that memory usage is in conserve mode. What immediate action does FortiOS take when entering conserve mode?

Trap 1: It immediately reboots the device to clear RAM.

Conserve mode does not reboot the FortiGate; it drops new sessions and blocks resource-heavy processes to free RAM. Rebooting is tempting as a generic memory remedy, but it would only be the correct action when a device is unresponsive and cannot recover through normal conserve-mode protections.

Trap 2: It wipes all historical log files from local disk storage.

Conserve mode does not wipe local logs; log storage is managed separately through log settings and disk quotas. Deleting logs is tempting because logs consume disk, but it would be the correct action only when disk space, not RAM, is the constrained resource triggering the problem.

Trap 3: It automatically initiates a firmware rollback to the previous…

Conserve mode never triggers a firmware rollback; that is a manual administrative recovery step. Rollback is tempting because firmware faults can cause memory leaks, but it would be the correct choice only after confirming a specific firmware defect, not as an automatic FortiOS response to memory pressure.

A
It stops allocating memory for certain cache operations and may block new non-administrative connection attempts.
Conserve mode triggers FortiOS to halt memory allocation for non-essential cache operations and refuse new non-administrative connections, preserving memory for critical processes. This directly addresses the high memory utilisation constraint, keeping the FortiGate responsive and administrative access available.
B
It immediately reboots the device to clear RAM.
Why it fails: Conserve mode does not reboot the FortiGate; it drops new sessions and blocks resource-heavy processes to free RAM. Rebooting is tempting as a generic memory remedy, but it would only be the correct action when a device is unresponsive and cannot recover through normal conserve-mode protections.
C
It wipes all historical log files from local disk storage.
Why it fails: Conserve mode does not wipe local logs; log storage is managed separately through log settings and disk quotas. Deleting logs is tempting because logs consume disk, but it would be the correct action only when disk space, not RAM, is the constrained resource triggering the problem.
D
It automatically initiates a firmware rollback to the previous stable version.
Why it fails: Conserve mode never triggers a firmware rollback; that is a manual administrative recovery step. Rollback is tempting because firmware faults can cause memory leaks, but it would be the correct choice only after confirming a specific firmware defect, not as an automatic FortiOS response to memory pressure.

Read the full VPN explanation →

Question 2hardmultiple choice

An administrator is troubleshooting a certificate validation error when users connect to an SSL VPN portal. Where can the active SSL VPN server certificate be verified or changed in the web-based manager?

Trap 1: Policy & Objects > SSL Settings

Policy & Objects > SSL Settings configures portal and authentication options, not the server certificate bound to the SSL VPN. It is tempting because SSL-related settings logically appear there; the active certificate is verified and replaced under VPN > SSL-VPN Settings, where the server certificate is selected.

Trap 2: System > Certificates > SSL-VPN

System > Certificates lists and imports certificates but does not bind one to the SSL VPN service. It is tempting because the certificate itself lives there and can be inspected; changing the active SSL VPN server certificate happens under VPN > SSL-VPN Settings, where the portal's certificate is assigned.

Trap 3: Security Fabric > VPN Settings

Security Fabric > VPN Settings covers fabric-wide VPN configuration, not the SSL VPN portal's server certificate. It is tempting because it aggregates VPN-related options in one place; the active certificate is verified and changed under VPN > SSL-VPN Settings, where the portal's server certificate is selected.

A
VPN > SSL-VPN Settings (Server Certificate field)
The Server Certificate field under VPN > SSL-VPN Settings binds the certificate presented to portal users, so replacing or verifying it there resolves the validation error. This is the only GUI location where the active SSL VPN server certificate is assigned.
B
Policy & Objects > SSL Settings
Why it fails: Policy & Objects > SSL Settings configures portal and authentication options, not the server certificate bound to the SSL VPN. It is tempting because SSL-related settings logically appear there; the active certificate is verified and replaced under VPN > SSL-VPN Settings, where the server certificate is selected.
C
System > Certificates > SSL-VPN
Why it fails: System > Certificates lists and imports certificates but does not bind one to the SSL VPN service. It is tempting because the certificate itself lives there and can be inspected; changing the active SSL VPN server certificate happens under VPN > SSL-VPN Settings, where the portal's certificate is assigned.
D
Security Fabric > VPN Settings
Why it fails: Security Fabric > VPN Settings covers fabric-wide VPN configuration, not the SSL VPN portal's server certificate. It is tempting because it aggregates VPN-related options in one place; the active certificate is verified and changed under VPN > SSL-VPN Settings, where the portal's server certificate is selected.

Question 3hardmultiple choice

An administrator needs to review the exact CLI commands executed during a troubleshooting session or audit log history. Which log category records administrative CLI command execution?

Trap 1: Security Fabric > Audit Logs

Security Fabric > Audit Logs covers Fabric topology and device events, not administrative CLI command execution, which resides in Log & Report > Audit Logs. It tempts because the word audit suggests command history, but this location records Fabric-level activity instead of per-administrator CLI entries.

Trap 2: FortiView > Command History

FortiView provides graphical traffic and threat visualisation dashboards, not administrative command records, so it cannot show executed CLI commands. It tempts because FortiView aggregates logged activity into drill-down views, which feels like an audit trail, yet command execution is captured only in Audit Logs.

Trap 3: Log & Report > CLI History

CLI History does not exist under Log & Report; administrative command execution is recorded in the Audit Logs, not the log category tree. It tempts because Log & Report hosts event, traffic and security logs, so an administrator expects command records there, but no such CLI-specific log category is present.

A
Security Fabric > Audit Logs
Why it fails: Security Fabric > Audit Logs covers Fabric topology and device events, not administrative CLI command execution, which resides in Log & Report > Audit Logs. It tempts because the word audit suggests command history, but this location records Fabric-level activity instead of per-administrator CLI entries.
B
FortiView > Command History
Why it fails: FortiView provides graphical traffic and threat visualisation dashboards, not administrative command records, so it cannot show executed CLI commands. It tempts because FortiView aggregates logged activity into drill-down views, which feels like an audit trail, yet command execution is captured only in Audit Logs.
C
Log & Report > System Events (Admin Login and CLI Command Logs)
Log & Report > System Events captures administrative CLI command execution through the Admin Login and CLI Command Logs sub-category, recording each command an administrator runs on the FortiGate. This directly satisfies the requirement to review exact CLI commands executed during a troubleshooting session or audit history, unlike traffic or event logs that omit command-level detail.
D
Log & Report > CLI History
Why it fails: CLI History does not exist under Log & Report; administrative command execution is recorded in the Audit Logs, not the log category tree. It tempts because Log & Report hosts event, traffic and security logs, so an administrator expects command records there, but no such CLI-specific log category is present.

Question 4hardmulti select

An administrator is investigating a network performance degradation issue and needs to check hardware sensor health on a high-end FortiGate unit. Which THREE hardware parameters or components can be monitored via FortiGate hardware status commands or widgets? (Choose three)

Trap 1: Active BGP peer uptime metrics

BGP peer uptime is a routing-protocol metric reported by get router info bgp, not a hardware sensor. It is tempting because BGP monitoring matters for connectivity troubleshooting, but the question targets chassis sensors such as temperature, fan speed and power supply status exposed by hardware status commands.

Trap 2: SSL VPN tunnel encryption keys

SSL VPN tunnel encryption keys are cryptographic session material, not a hardware sensor, so no hardware status command or widget reports them. It is tempting because VPN monitoring is a common FortiGate task, and would be correct when inspecting active tunnel status rather than physical component health.

A
Power supply unit (PSU) status
PSU status is exposed through hardware sensor monitoring, reporting whether each power supply is present, healthy or failed. On high-end chassis units this directly satisfies the requirement to check hardware sensor health when diagnosing performance degradation.
B
Internal chassis or CPU temperature sensors
Internal chassis and CPU temperature sensors report thermal readings through hardware status commands and widgets. Elevated temperatures cause throttling, so this parameter directly satisfies the requirement to check hardware sensor health when investigating performance degradation.
C
Active BGP peer uptime metrics
Why it fails: BGP peer uptime is a routing-protocol metric reported by get router info bgp, not a hardware sensor. It is tempting because BGP monitoring matters for connectivity troubleshooting, but the question targets chassis sensors such as temperature, fan speed and power supply status exposed by hardware status commands.
D
Fan operational status and speeds
Fan status and speed readings are reported by hardware sensor monitoring, revealing failed or degraded fans. Because inadequate cooling throttles throughput, this component directly satisfies the requirement to check hardware sensor health during performance degradation investigations.
E
SSL VPN tunnel encryption keys
Why it fails: SSL VPN tunnel encryption keys are cryptographic session material, not a hardware sensor, so no hardware status command or widget reports them. It is tempting because VPN monitoring is a common FortiGate task, and would be correct when inspecting active tunnel status rather than physical component health.

Question 5hardmultiple choice

An administrator is troubleshooting a packet loss issue and needs to inspect the kernel buffer drops and interface error counters. Which CLI command provides a summary of interface drop statistics?

Trap 1: execute interface-test drops

`execute interface-test drops` runs an active diagnostic test that injects traffic to probe interface behaviour, so it cannot report the kernel buffer drops and error counters already accumulated on the interface. It is tempting because interface-test commands do exist for fault isolation, and would suit confirming suspected hardware faults after reviewing statistics.

Trap 2: show interface drops

'show interface drops' is not a valid FortiOS command; interface error and drop counters are viewed with 'diagnose hardware deviceinfo nic' or 'get system interface physical'. It tempts because the wording matches the question, but the syntax does not exist.

Trap 3: get system drop-stats

'get system drop-stats' does not exist in FortiOS; kernel buffer drops are inspected with 'diagnose netlink interface list' or 'diagnose hardware deviceinfo nic'. It tempts because it sounds like a drop-statistics command, but the actual diagnostic syntax differs.

A
execute interface-test drops
Why it fails: `execute interface-test drops` runs an active diagnostic test that injects traffic to probe interface behaviour, so it cannot report the kernel buffer drops and error counters already accumulated on the interface. It is tempting because interface-test commands do exist for fault isolation, and would suit confirming suspected hardware faults after reviewing statistics.
B
diagnose hardware deviceinfo nic [interface]
`diagnose hardware deviceinfo nic` queries the network interface driver directly, reporting kernel-level buffer drops alongside interface error counters such as RX/TX errors and overruns. This satisfies the stem's requirement to inspect kernel buffer drops and interface error counters in one summary view.
C
show interface drops
Why it fails: 'show interface drops' is not a valid FortiOS command; interface error and drop counters are viewed with 'diagnose hardware deviceinfo nic' or 'get system interface physical'. It tempts because the wording matches the question, but the syntax does not exist.
D
get system drop-stats
Why it fails: 'get system drop-stats' does not exist in FortiOS; kernel buffer drops are inspected with 'diagnose netlink interface list' or 'diagnose hardware deviceinfo nic'. It tempts because it sounds like a drop-statistics command, but the actual diagnostic syntax differs.

Review the full routing breakdown →

Question 6hardmultiple choice

An administrator is investigating a network routing issue on the FortiGate and needs to see the current active kernel routing table entries. Which CLI command provides this information?

Trap 1: execute traceroute

execute traceroute sends probe packets hop by hop to map the path to a destination; it reveals where traffic stops, not the installed routing entries. It is tempting because it is the standard reachability diagnostic, and it would be correct for locating which hop drops traffic once the routing table is known.

Trap 2: get system interface

get system interface displays interface configuration and status — addresses, link state, MTU — not the kernel routing table. It is tempting because interface details are the first thing checked when a route looks wrong, and it would be the right command to confirm an interface is up and correctly addressed before investigating routes.

Trap 3: diagnose firewall IP-antibot list

diagnose firewall IP-antibot list prints the IP reputation or botnet blocklist entries held by the firewall; it contains no routing information. It is tempting because diagnose commands expose FortiGate internals, and this one would be correct when verifying whether a source address is blocked by IP reputation.

A
execute traceroute
Why it fails: execute traceroute sends probe packets hop by hop to map the path to a destination; it reveals where traffic stops, not the installed routing entries. It is tempting because it is the standard reachability diagnostic, and it would be correct for locating which hop drops traffic once the routing table is known.
B
get system interface
Why it fails: get system interface displays interface configuration and status — addresses, link state, MTU — not the kernel routing table. It is tempting because interface details are the first thing checked when a route looks wrong, and it would be the right command to confirm an interface is up and correctly addressed before investigating routes.
C
get router info routing-table all
`get router info routing-table all` queries the FortiGate's active kernel routing table directly, dumping every installed route rather than filtering by protocol or prefix. This satisfies the administrator's requirement to view current active entries, unlike configuration-oriented commands that display static route definitions without confirming which routes the kernel actually selected.
D
diagnose firewall IP-antibot list
Why it fails: diagnose firewall IP-antibot list prints the IP reputation or botnet blocklist entries held by the firewall; it contains no routing information. It is tempting because diagnose commands expose FortiGate internals, and this one would be correct when verifying whether a source address is blocked by IP reputation.

Read the full DHCP explanation →

Question 7hardmultiple choice

An administrator is troubleshooting a DHCP server issue on the FortiGate and needs to see active IP address leases assigned by the built-in DHCP server. Which CLI command provides this information?

Trap 1: diagnose system dhcp list

This command lists DHCP scope configuration and pool parameters, not the active lease bindings the administrator needs. It is tempting because its name suggests lease enumeration, and it would be the right choice when verifying scope settings or address ranges rather than inspecting which clients currently hold leases.

Trap 2: get router info dhcp

This queries the routing table for DHCP-derived routes, not the built-in server's lease database, so no client bindings appear. It is tempting because it is a genuine DHCP diagnostic command, and it would be correct for checking addresses learned from an upstream DHCP server via the interface, not local leases.

Trap 3: get system dhcp-server lease

This command displays lease information held by the FortiGate's own DHCP server, but the administrator needs the leases currently assigned and active. It would be correct for inspecting the server's configured lease database rather than the live lease list shown by the execute command.

A
execute dhcp lease-list
The execute dhcp lease-list command queries the FortiGate's built-in DHCP server and returns currently active leases with IP, MAC and expiry details. It directly satisfies the requirement to view active IP address leases assigned by the built-in server.
B
diagnose system dhcp list
Why it fails: This command lists DHCP scope configuration and pool parameters, not the active lease bindings the administrator needs. It is tempting because its name suggests lease enumeration, and it would be the right choice when verifying scope settings or address ranges rather than inspecting which clients currently hold leases.
C
get router info dhcp
Why it fails: This queries the routing table for DHCP-derived routes, not the built-in server's lease database, so no client bindings appear. It is tempting because it is a genuine DHCP diagnostic command, and it would be correct for checking addresses learned from an upstream DHCP server via the interface, not local leases.
D
get system dhcp-server lease
Why it fails: This command displays lease information held by the FortiGate's own DHCP server, but the administrator needs the leases currently assigned and active. It would be correct for inspecting the server's configured lease database rather than the live lease list shown by the execute command.

Question 8mediummultiple choice

An administrator is troubleshooting intermittent latency on a specific interface. They need to capture live packet data passing through that interface directly from the FortiGate CLI. Which command is used for packet capture?

Trap 1: execute ping-packet

execute ping-packet is not a FortiGate packet-capture command; it does not mirror live frames from an interface. It is tempting because the name suggests packet handling, and it would be correct for testing reachability to a host rather than capturing traffic.

Trap 2: execute trace-route

execute trace-route maps the path packets take to a destination; it does not capture live frames on an interface. It is tempting because it is a diagnostic command, and it would be correct for locating a routing hop failure rather than recording packet data.

Trap 3: get system interface traffic

get system interface traffic displays interface counters and statistics, not captured packet payloads. It is tempting because it reports traffic on the named interface, and it would be correct for checking throughput or error counts rather than inspecting live frames.

A
execute ping-packet
Why it fails: execute ping-packet is not a FortiGate packet-capture command; it does not mirror live frames from an interface. It is tempting because the name suggests packet handling, and it would be correct for testing reachability to a host rather than capturing traffic.
B
execute trace-route
Why it fails: execute trace-route maps the path packets take to a destination; it does not capture live frames on an interface. It is tempting because it is a diagnostic command, and it would be correct for locating a routing hop failure rather than recording packet data.
C
get system interface traffic
Why it fails: get system interface traffic displays interface counters and statistics, not captured packet payloads. It is tempting because it reports traffic on the named interface, and it would be correct for checking throughput or error counts rather than inspecting live frames.
D
diagnose sniffer packet
The diagnose sniffer packet command captures live packets at the interface level from the CLI, letting the administrator inspect traffic on the specific interface. It directly satisfies the requirement to capture live packet data without external tools.

Question 9hardmultiple choice

An administrator is troubleshooting a scenario where internal users can browse safe websites, but HTTPS inspection using certificates is throwing browser security warnings for certain internal web applications. What is the most likely cause of this behavior when using Deep Packet Inspection (DPI) on FortiGate?

Trap 1: The Web Filtering license on the FortiGate has expired, causing…

An expired Web Filtering licence disables category-based blocking and FortiGuard lookups, but HTTPS inspection itself continues using the local CA certificate; browsers warn because they distrust that certificate, not because licensing lapsed. The licence matters when URL filtering categories must be enforced.

Trap 2: The firewall policy is configured with proxy-based inspection…

Proxy-based inspection terminates the TLS session and re-signs with the FortiGate CA, so browsers trust it only if that CA is installed; the scenario's warnings on internal apps point to certificate trust, not inspection mode. Flow-based inspection is chosen for throughput, not to prevent warnings.

Trap 3: The Antivirus database update failed, preventing the FortiGate from…

Antivirus database updates are unrelated to TLS decryption; deep inspection uses the FortiGate's certificate and CA chain, so browser warnings arise when the inspection CA is not trusted by the client or the certificate is mismatched. It is tempting because update failures do cause inspection problems, but not certificate trust errors.

A
The Web Filtering license on the FortiGate has expired, causing HTTPS inspection to fail open.
Why it fails: An expired Web Filtering licence disables category-based blocking and FortiGuard lookups, but HTTPS inspection itself continues using the local CA certificate; browsers warn because they distrust that certificate, not because licensing lapsed. The licence matters when URL filtering categories must be enforced.
B
The firewall policy is configured with proxy-based inspection instead of flow-based inspection.
Why it fails: Proxy-based inspection terminates the TLS session and re-signs with the FortiGate CA, so browsers trust it only if that CA is installed; the scenario's warnings on internal apps point to certificate trust, not inspection mode. Flow-based inspection is chosen for throughput, not to prevent warnings.
C
The Antivirus database update failed, preventing the FortiGate from decrypting TLS 1.3 handshakes.
Why it fails: Antivirus database updates are unrelated to TLS decryption; deep inspection uses the FortiGate's certificate and CA chain, so browser warnings arise when the inspection CA is not trusted by the client or the certificate is mismatched. It is tempting because update failures do cause inspection problems, but not certificate trust errors.
D
The FortiGate CA certificate has not been installed in the trusted root certificate store of the client endpoints.
HTTPS inspection requires FortiGate to re-sign traffic with its own CA certificate. If that CA is absent from each endpoint's trusted root store, browsers cannot chain the forged certificate to a trusted authority, so they raise security warnings for the internal web applications.

Question 10hardmultiple choice

An administrator is configuring a FortiGate firewall and needs to ensure that packets matching an explicit allow policy are also logged. Where should the administrator enable logging for this specific policy?

Trap 1: Inside the static route next-hop configuration

A static route's next-hop configuration determines packet forwarding path only; it holds no logging parameter. Policy logging is enabled within the firewall policy's log settings. Static routes would be the correct place when redirecting traffic through a specific gateway or blackhole route.

Trap 2: Within the physical interface administrative access profile

Interface administrative access profiles control which management protocols—HTTPS, SSH, ping—are permitted on that interface, not traffic logging. Policy logging is configured inside the firewall policy itself. Access profiles would be the correct setting when restricting administrator login methods on an interface.

Trap 3: Under the global system time zone and NTP settings

Time zone and NTP settings govern timestamp accuracy across the device, not whether traffic matching a policy generates log entries. Per-policy logging is enabled within the firewall policy's own log settings. Global time configuration would be the correct place when correcting skewed event timestamps in log correlation.

A
Inside the static route next-hop configuration
Why it fails: A static route's next-hop configuration determines packet forwarding path only; it holds no logging parameter. Policy logging is enabled within the firewall policy's log settings. Static routes would be the correct place when redirecting traffic through a specific gateway or blackhole route.
B
Within the physical interface administrative access profile
Why it fails: Interface administrative access profiles control which management protocols—HTTPS, SSH, ping—are permitted on that interface, not traffic logging. Policy logging is configured inside the firewall policy itself. Access profiles would be the correct setting when restricting administrator login methods on an interface.
C
Inside the specific firewall policy rule settings under Log Allowed Traffic
Enabling Log Allowed Traffic within the individual firewall policy activates per-policy traffic logging, so only packets matching that explicit allow rule are recorded. This directly satisfies the requirement to log traffic for one specific policy without altering global logging settings or affecting other rules.
D
Under the global system time zone and NTP settings
Why it fails: Time zone and NTP settings govern timestamp accuracy across the device, not whether traffic matching a policy generates log entries. Per-policy logging is enabled within the firewall policy's own log settings. Global time configuration would be the correct place when correcting skewed event timestamps in log correlation.

Read the full network assurance explanation →

Question 11hardmulti select

An administrator is troubleshooting log delivery failures to a remote syslog server. Which TWO troubleshooting commands or tools can be used from the FortiGate CLI to verify connectivity and log transmission?

Trap 1: diagnose debug flow filter

Used for debugging firewall policy traffic matching, not syslog application layer packets.

Trap 2: execute factory-reset

Destroys the configuration and does not help troubleshoot logs.

Trap 3: get system arps

Displays ARP cache, which does not directly test log transmission or application connectivity.

A
diagnose debug flow filter
Why it fails: Used for debugging firewall policy traffic matching, not syslog application layer packets.
B
execute factory-reset
Why it fails: Destroys the configuration and does not help troubleshoot logs.
C
get system arps
Why it fails: Displays ARP cache, which does not directly test log transmission or application connectivity.
D
execute ping <syslog-server-ip>
The execute ping command tests ICMP reachability to the syslog server, confirming whether routing, firewall policy or upstream connectivity is blocking traffic. It satisfies the requirement to verify connectivity from the FortiGate CLI before assuming the logging daemon itself is at fault.
E
diagnose sniffer packet any 'port 514' 4
The sniffer captures live packets on UDP or TCP port 514, confirming whether syslog traffic actually leaves the FortiGate and reaches the remote server. This directly satisfies the stem's requirement to verify log transmission, exposing drops, wrong destinations or filtering that `execute log filter` alone cannot reveal.

Question 12easymultiple choice

What is the primary function of a firewall policy ID on a FortiGate?

Trap 1: To assign an IP address to the DHCP client

A firewall policy ID is the unique numeric identifier FortiGate assigns to each policy so it can be referenced in logs, routing and CLI commands; it plays no part in address assignment. It tempts because DHCP configuration also lives on the FortiGate, but lease addressing is handled by the DHCP server settings.

Trap 2: To determine the cryptographic key used for IPsec VPN encryption

Policy IDs are lookup labels for referencing a firewall rule in logs, CLI edits and diagnostics; they carry no cryptographic material. IPsec encryption keys come from the phase 2 proposal and pre-shared key or certificate. The option tempts because both policies and VPNs are configured on the FortiGate, so their identifiers appear adjacent in the GUI.

Trap 3: To define the physical switch port VLAN assignment

Firewall policy IDs are sequential integers FortiGate assigns to identify and order policies in the policy table; they never touch Layer 2 switching. VLAN-to-port assignment belongs on the FortiSwitch or interface configuration. The option tempts because policy IDs are numeric labels, which can be mistaken for configuration identifiers of any kind.

A
To assign an IP address to the DHCP client
Why it fails: A firewall policy ID is the unique numeric identifier FortiGate assigns to each policy so it can be referenced in logs, routing and CLI commands; it plays no part in address assignment. It tempts because DHCP configuration also lives on the FortiGate, but lease addressing is handled by the DHCP server settings.
B
To uniquely identify and reference the firewall policy rule
The policy ID is a unique numeric identifier assigned to each firewall policy, used for referencing, logging, reordering and troubleshooting. This satisfies the stem's identification requirement, letting administrators and logs distinguish individual rules within a large policy set.
C
To determine the cryptographic key used for IPsec VPN encryption
Why it fails: Policy IDs are lookup labels for referencing a firewall rule in logs, CLI edits and diagnostics; they carry no cryptographic material. IPsec encryption keys come from the phase 2 proposal and pre-shared key or certificate. The option tempts because both policies and VPNs are configured on the FortiGate, so their identifiers appear adjacent in the GUI.
D
To define the physical switch port VLAN assignment
Why it fails: Firewall policy IDs are sequential integers FortiGate assigns to identify and order policies in the policy table; they never touch Layer 2 switching. VLAN-to-port assignment belongs on the FortiSwitch or interface configuration. The option tempts because policy IDs are numeric labels, which can be mistaken for configuration identifiers of any kind.

Question 13mediummultiple choice

A network administrator is troubleshooting an intermittent connectivity issue on a FortiGate 100F running FortiOS 7.2. They suspect that the problem is related to the session table filling up. Which CLI command should they use to view the current session count and the maximum session limit?

Trap 1: get system session status

This is not a valid FortiOS command. The correct command family for session information is 'diagnose sys session'. Using an invalid command will return an error and not provide the needed session statistics, wasting time during troubleshooting.

Trap 2: show system session info

This command does not exist in FortiOS. Session information is accessed via 'diagnose' commands. Attempting to use this command will fail and not show the session count or limit, so it cannot help diagnose the issue.

Trap 3: diagnose netlink session list

This command is not a standard FortiOS command for viewing session statistics. While 'diagnose netlink' commands exist for low-level interface information, they do not provide session table counts. Using this would not yield the required session utilization data.

A
get system session status
Why it fails: This is not a valid FortiOS command. The correct command family for session information is 'diagnose sys session'. Using an invalid command will return an error and not provide the needed session statistics, wasting time during troubleshooting.
B
show system session info
Why it fails: This command does not exist in FortiOS. Session information is accessed via 'diagnose' commands. Attempting to use this command will fail and not show the session count or limit, so it cannot help diagnose the issue.
C
diagnose sys session stat
This command displays statistics about the session table, including the current number of sessions and the maximum session limit. It is the correct tool to quickly assess session table utilization and determine if the table is near capacity, which could cause new sessions to be dropped and lead to intermittent connectivity issues.
D
diagnose netlink session list
Why it fails: This command is not a standard FortiOS command for viewing session statistics. While 'diagnose netlink' commands exist for low-level interface information, they do not provide session table counts. Using this would not yield the required session utilization data.