Troubleshooting practice questions

A user is attempting to authenticate via a FortiAuthenticator-backed portal but receives an 'Access Denied' message. The user exists in the AD group mapped to the policy. What should you check first?

Trap 1: The AD domain controller's disk space

Disk space on a domain controller does not determine whether FortiAuthenticator maps an AD group to a portal policy; authentication would fail differently, not with a policy denial. Checking DC health is tempting because AD outages break authentication, and would be correct if the user's credentials or LDAP lookups were failing.

Trap 2: The FortiGate session table

The FortiGate session table tracks firewall connections, not FortiAuthenticator's group-to-policy evaluation, so it cannot explain this portal denial. The session table is tempting because stale sessions cause access problems, and would be the right check if traffic were dropped by the FortiGate rather than rejected during authentication.

Trap 3: The WAF policy on FortiWeb

FortiWeb's WAF inspects HTTP traffic for attacks; it does not evaluate FortiAuthenticator group-to-policy mappings, so it cannot cause this portal denial. Checking WAF policy is tempting because web-facing portals traverse FortiWeb, and would be right if the failure were a blocked or filtered HTTP request rather than authentication.

A
The AD domain controller's disk space
Why it fails: Disk space on a domain controller does not determine whether FortiAuthenticator maps an AD group to a portal policy; authentication would fail differently, not with a policy denial. Checking DC health is tempting because AD outages break authentication, and would be correct if the user's credentials or LDAP lookups were failing.
B
The FortiGate session table
Why it fails: The FortiGate session table tracks firewall connections, not FortiAuthenticator's group-to-policy evaluation, so it cannot explain this portal denial. The session table is tempting because stale sessions cause access problems, and would be the right check if traffic were dropped by the FortiGate rather than rejected during authentication.
C
FortiAuthenticator Authentication Logs
The authentication logs record each attempt's result, matched policy, and failure reason, so they immediately reveal whether the denial stems from group mismatch, token failure, or policy ordering. Checking them first satisfies the need to diagnose the cause rather than guessing at AD or network configuration.
D
The WAF policy on FortiWeb
Why it fails: FortiWeb's WAF inspects HTTP traffic for attacks; it does not evaluate FortiAuthenticator group-to-policy mappings, so it cannot cause this portal denial. Checking WAF policy is tempting because web-facing portals traverse FortiWeb, and would be right if the failure were a blocked or filtered HTTP request rather than authentication.

Question 2hardmultiple choice

Which command allows you to verify if the FortiMail can reach a remote mail server on port 25?

Trap 1: ping <IP>

ICMP echo confirms IP reachability only; it cannot test TCP port 25, so a host answering ping may still block SMTP. It is tempting because ping is the quickest reachability check, but the axis is ICMP versus TCP, and the correct tool is a TCP port test such as telnet or execute tcp-port.

Trap 2: arp -a

arp -a displays the local ARP cache mapping IP addresses to MAC addresses on the same subnet; it sends no traffic to the remote mail server and cannot test port 25. It is tempting as a connectivity diagnostic, but the axis is layer-2 cache inspection versus layer-4 TCP reachability.

Trap 3: traceroute <IP>

Traceroute maps the router path to a destination using UDP or ICMP probes; it never opens a TCP session on port 25, so SMTP reachability stays unverified. It is tempting because it diagnoses routing failures, but the axis is path discovery versus port-level connectivity testing.

A
ping <IP>
Why it fails: ICMP echo confirms IP reachability only; it cannot test TCP port 25, so a host answering ping may still block SMTP. It is tempting because ping is the quickest reachability check, but the axis is ICMP versus TCP, and the correct tool is a TCP port test such as telnet or execute tcp-port.
B
arp -a
Why it fails: arp -a displays the local ARP cache mapping IP addresses to MAC addresses on the same subnet; it sends no traffic to the remote mail server and cannot test port 25. It is tempting as a connectivity diagnostic, but the axis is layer-2 cache inspection versus layer-4 TCP reachability.
C
traceroute <IP>
Why it fails: Traceroute maps the router path to a destination using UDP or ICMP probes; it never opens a TCP session on port 25, so SMTP reachability stays unverified. It is tempting because it diagnoses routing failures, but the axis is path discovery versus port-level connectivity testing.
D
telnet <IP> 25
Using telnet to the remote server on port 25 opens a raw TCP connection, directly confirming SMTP reachability and any firewall or routing block between FortiMail and the destination. It satisfies the stem's requirement to verify port-level connectivity, unlike ping, which only tests ICMP and cannot validate that TCP port 25 is open.

Question 3mediummultiple choice

You are troubleshooting a sync issue where a device shows 'Modified' status in the Device Manager. What is the most likely cause?

Trap 1: The FortiManager license has expired.

A 'Modified' status means the device's running configuration diverges from the policy package installed by FortiManager; an expired licence blocks management functions but does not produce that specific status. It tempts because licensing faults do disrupt FortiManager operations, yet the Modified flag reflects configuration drift.

Trap 2: The FortiManager firmware is outdated.

'Modified' indicates configuration drift between the device and its installed policy package, not a version mismatch on FortiManager itself. It tempts because firmware differences can cause interoperability faults, but the status specifically compares device configuration against the policy package.

Trap 3: The policy package was deleted.

Deleting a policy package removes it from FortiManager entirely, so no package remains to compare against the device; 'Modified' requires an installed package whose contents differ. It tempts because missing packages do break policy installation, but the status itself denotes drift, not deletion.

A
The FortiManager license has expired.
Why it fails: A 'Modified' status means the device's running configuration diverges from the policy package installed by FortiManager; an expired licence blocks management functions but does not produce that specific status. It tempts because licensing faults do disrupt FortiManager operations, yet the Modified flag reflects configuration drift.
B
The FortiManager firmware is outdated.
Why it fails: 'Modified' indicates configuration drift between the device and its installed policy package, not a version mismatch on FortiManager itself. It tempts because firmware differences can cause interoperability faults, but the status specifically compares device configuration against the policy package.
C
The policy package was deleted.
Why it fails: Deleting a policy package removes it from FortiManager entirely, so no package remains to compare against the device; 'Modified' requires an installed package whose contents differ. It tempts because missing packages do break policy installation, but the status itself denotes drift, not deletion.
D
The configuration on the FortiGate was changed locally.
Local configuration changes on the FortiGate set the device's synchronisation state to 'Modified', because FortiManager detects a configuration drift between its own database and the managed device. This mismatch is exactly the sync issue described in the stem, making a local edit the most likely cause.

Question 4hardmultiple choice

You are troubleshooting a FortiADC health check. The health check is failing even though the server is up. What should you verify first?

Trap 1: The ADC management IP

The ADC management IP addresses the appliance itself, not the monitored server's reachability. It is tempting because connectivity faults often stem from addressing, but a failing health check despite an up server points to the health check's probe settings, such as port, protocol, or expected response.

Trap 2: Server RAM utilization

RAM utilisation does not affect FortiADC health check probes; these test TCP, HTTP or ICMP reachability, not host resource headroom. It is tempting because high memory can slow application responses, so it would be worth checking when a server passes its probe but serves requests slowly.

Trap 3: The switch MTU

Switch MTU affects packet fragmentation on the path, not whether FortiADC's health check probe receives a valid response from a server that is already up. MTU is worth checking when large packets are dropped or tunnels fail; here the probe configuration, port, protocol and expected response code should be verified first.

A
The ADC management IP
Why it fails: The ADC management IP addresses the appliance itself, not the monitored server's reachability. It is tempting because connectivity faults often stem from addressing, but a failing health check despite an up server points to the health check's probe settings, such as port, protocol, or expected response.
B
Expected Response code in the Health Check object
A health check fails when the server's reply does not match the configured Expected Response code, even if the service is reachable. Verifying that value first confirms whether FortiADC is rejecting a valid response, such as a 200 versus the configured 302.
C
Server RAM utilization
Why it fails: RAM utilisation does not affect FortiADC health check probes; these test TCP, HTTP or ICMP reachability, not host resource headroom. It is tempting because high memory can slow application responses, so it would be worth checking when a server passes its probe but serves requests slowly.
D
The switch MTU
Why it fails: Switch MTU affects packet fragmentation on the path, not whether FortiADC's health check probe receives a valid response from a server that is already up. MTU is worth checking when large packets are dropped or tunnels fail; here the probe configuration, port, protocol and expected response code should be verified first.

Question 5easymultiple choice

What is the primary function of the FortiAnalyzer 'Log View' page?

Trap 1: Configuring device passwords

Device password configuration belongs to FortiManager's device provisioning, not FortiAnalyzer's Log View, which displays raw and filtered log entries for investigation. It is tempting because FortiAnalyzer does hold registered device records, but credential management is FortiManager's role.

Trap 2: Creating SOC playbooks

SOC playbooks are built in FortiSOAR's automation engine, not FortiAnalyzer's Log View, which only queries and displays stored log entries. It is tempting because FortiAnalyzer feeds those playbooks with log data, yet orchestration itself sits outside its Log View page.

Trap 3: Generating PDF reports

PDF report generation is handled by FortiAnalyzer's Reports module, not Log View, which presents live log entries for searching and filtering. It is tempting because both consume the same log database, but scheduled output formatting is a separate function from interactive log inspection.

A
Configuring device passwords
Why it fails: Device password configuration belongs to FortiManager's device provisioning, not FortiAnalyzer's Log View, which displays raw and filtered log entries for investigation. It is tempting because FortiAnalyzer does hold registered device records, but credential management is FortiManager's role.
B
Creating SOC playbooks
Why it fails: SOC playbooks are built in FortiSOAR's automation engine, not FortiAnalyzer's Log View, which only queries and displays stored log entries. It is tempting because FortiAnalyzer feeds those playbooks with log data, yet orchestration itself sits outside its Log View page.
C
Generating PDF reports
Why it fails: PDF report generation is handled by FortiAnalyzer's Reports module, not Log View, which presents live log entries for searching and filtering. It is tempting because both consume the same log database, but scheduled output formatting is a separate function from interactive log inspection.
D
Viewing raw log data
Log View displays raw, unparsed log entries exactly as received, letting analysts inspect original fields and values. This satisfies the primary function by presenting source log data directly, rather than aggregated reports or dashboards built from parsed and indexed content.

Question 6hardmultiple choice

You are troubleshooting a failed policy installation. Where can you view the detailed diff between the FortiManager policy database and the actual FortiGate running configuration?

Trap 1: Object Usage.

Object Usage lists where objects are referenced across policies and ADOMs; it never compares FortiManager's database against a FortiGate's running configuration. It tempts for impact analysis before deleting objects, but the installation diff appears in the Install Wizard's preview pane instead.

Trap 2: FortiView.

FortiView presents traffic, threat and session analytics from logs; it holds no configuration comparison data. It tempts because it is a go-to troubleshooting console, but the policy-installation diff is shown in the Install Wizard preview, not in log-driven dashboards.

Trap 3: Device Manager > Revision History.

Revision History stores FortiManager database revisions for rollback and comparison between saved versions, not against a FortiGate's live running configuration. It tempts because it does show configuration diffs, but those are historical FortiManager snapshots, not the device-versus-manager installation diff.

A
Policy & Objects > Installation Preview.
Installation Preview compares the FortiManager policy database against the FortiGate's running configuration, displaying the exact configuration diff before installation. This satisfies the troubleshooting requirement by exposing precisely which policy objects differ, without committing changes to the managed device.
B
Object Usage.
Why it fails: Object Usage lists where objects are referenced across policies and ADOMs; it never compares FortiManager's database against a FortiGate's running configuration. It tempts for impact analysis before deleting objects, but the installation diff appears in the Install Wizard's preview pane instead.
C
FortiView.
Why it fails: FortiView presents traffic, threat and session analytics from logs; it holds no configuration comparison data. It tempts because it is a go-to troubleshooting console, but the policy-installation diff is shown in the Install Wizard preview, not in log-driven dashboards.
D
Device Manager > Revision History.
Why it fails: Revision History stores FortiManager database revisions for rollback and comparison between saved versions, not against a FortiGate's live running configuration. It tempts because it does show configuration diffs, but those are historical FortiManager snapshots, not the device-versus-manager installation diff.
E
System Settings > Task Monitor.
Why it fails: Task Monitor shows installation task status, progress and any error messages, but not a line-by-line configuration diff. It tempts because failed installs surface there, yet the detailed comparison between FortiManager's policy database and the FortiGate's running configuration is displayed in the Install Wizard preview.

Question 7hardmultiple choice

You are troubleshooting a scenario where an Event Handler is not triggering as expected. What is the most effective way to verify if the logs are matching the filter criteria defined in the handler?

Trap 1: Run a manual report

A manual report aggregates historical log data into a formatted output; it does not replay raw logs against the handler's filter expression, so a non-matching filter stays invisible. Reports suit scheduled compliance or trend summaries, not filter validation. The log preview or test-filter function shows exactly which entries satisfy the criteria.

Trap 2: Rebuild the SQL database

Rebuilding the SQL database reinitialises the log store and destroys existing logs, so it cannot reveal whether entries match the handler's filter. It is a recovery step for corruption or schema faults. Verifying filter matches requires inspecting live log entries against the criteria, not rebuilding storage.

Trap 3: Check the FortiAnalyzer system logs

FortiAnalyzer system logs record daemon, task and administrative events, not the traffic or security logs the handler filters on. They are the right place to diagnose process crashes or task failures. Confirming filter matches needs the log preview showing which raw entries satisfy the handler's criteria.

A
Run a manual report
Why it fails: A manual report aggregates historical log data into a formatted output; it does not replay raw logs against the handler's filter expression, so a non-matching filter stays invisible. Reports suit scheduled compliance or trend summaries, not filter validation. The log preview or test-filter function shows exactly which entries satisfy the criteria.
B
Use the 'Test' button in the Event Handler definition
The Test button evaluates the handler's filter against existing logs and reports matches immediately, confirming whether criteria align with real log entries. This satisfies the troubleshooting need by isolating filter mismatch from trigger or delivery faults without waiting for live events.
C
Rebuild the SQL database
Why it fails: Rebuilding the SQL database reinitialises the log store and destroys existing logs, so it cannot reveal whether entries match the handler's filter. It is a recovery step for corruption or schema faults. Verifying filter matches requires inspecting live log entries against the criteria, not rebuilding storage.
D
Check the FortiAnalyzer system logs
Why it fails: FortiAnalyzer system logs record daemon, task and administrative events, not the traffic or security logs the handler filters on. They are the right place to diagnose process crashes or task failures. Confirming filter matches needs the log preview showing which raw entries satisfy the handler's criteria.

Question 8mediummultiple choice

You are troubleshooting a scenario where FortiADC is failing to perform health checks on a backend server. Which log should you prioritize to identify the specific reason for the health check failure?

Trap 1: Session Table Logs

Session table logs record established connections and their state, not the probe result or failure cause, so they cannot explain why a health check failed. They are tempting when connections are absent, but FortiADC health check diagnostics are recorded in the health check or event logs.

Trap 2: Application Traffic Logs

Application traffic logs record requests traversing the virtual server, not the health check probe results, so they cannot reveal why a monitor marked a server down. They are tempting because they show backend responses, but that is for diagnosing application errors, not health check state transitions.

Trap 3: Security Policy Logs

Security policy logs record firewall permit or deny decisions on traffic, not the outcome of health check probes, so they cannot explain why a server was marked down. They are tempting when a policy blocks probe traffic, but that is a security troubleshooting scenario, not health check diagnosis.

A
System Event Logs
Health check failures are recorded by the health check daemon, and its detailed probe results appear in the System Event Logs, which capture the specific reason such as a timeout or connection refusal. This log directly satisfies the troubleshooting requirement to identify why the backend server check is failing.
B
Session Table Logs
Why it fails: Session table logs record established connections and their state, not the probe result or failure cause, so they cannot explain why a health check failed. They are tempting when connections are absent, but FortiADC health check diagnostics are recorded in the health check or event logs.
C
Application Traffic Logs
Why it fails: Application traffic logs record requests traversing the virtual server, not the health check probe results, so they cannot reveal why a monitor marked a server down. They are tempting because they show backend responses, but that is for diagnosing application errors, not health check state transitions.
D
Security Policy Logs
Why it fails: Security policy logs record firewall permit or deny decisions on traffic, not the outcome of health check probes, so they cannot explain why a server was marked down. They are tempting when a policy blocks probe traffic, but that is a security troubleshooting scenario, not health check diagnosis.
E
SNMP Traps
Why it fails: SNMP traps only report state-change notifications such as a server transitioning down; they carry no detail on the probe's failure cause. They are tempting for alerting on health status, but that is monitoring, whereas the specific failure reason requires the health check log.

Question 9mediummultiple choice

You are troubleshooting a Security Fabric deployment where a downstream FortiGate is not appearing in the Fabric topology on the root FortiGate. You have verified that the downstream FortiGate is configured with the correct root FortiGate IP and that network connectivity exists. Which action should you take next to resolve the issue?

Trap 1: Delete and re-add the downstream FortiGate on the root FortiGate.

Deleting and re-adding the downstream FortiGate on the root is premature. The downstream device may not have attempted to join, so it wouldn't be listed to delete. This action is not the next logical step; verifying the downstream's Fabric settings is more appropriate.

Trap 2: Restart the FortiAnalyzer service.

Restarting the FortiAnalyzer service is irrelevant because FortiAnalyzer is not involved in the Fabric topology discovery between FortiGates. The issue is with the Fabric connection between the root and downstream FortiGate, not with logging or analysis. This action would not resolve the missing device.

Trap 3: Reconfigure the root FortiGate's management IP.

Changing the root FortiGate's management IP is unnecessary and could disrupt the existing Fabric. The downstream FortiGate is configured with the correct root IP, so the root's IP is likely correct. The problem lies elsewhere, such as the downstream's Fabric enablement or authorization.

A
Check the downstream FortiGate's Fabric settings to ensure the Security Fabric is enabled.
If the Security Fabric is not enabled on the downstream FortiGate, it will not attempt to join the Fabric, even if the root IP is configured. Enabling the Fabric on the downstream device is a prerequisite for it to appear in the topology. This is a common oversight during deployment.
B
Delete and re-add the downstream FortiGate on the root FortiGate.
Why it fails: Deleting and re-adding the downstream FortiGate on the root is premature. The downstream device may not have attempted to join, so it wouldn't be listed to delete. This action is not the next logical step; verifying the downstream's Fabric settings is more appropriate.
C
Restart the FortiAnalyzer service.
Why it fails: Restarting the FortiAnalyzer service is irrelevant because FortiAnalyzer is not involved in the Fabric topology discovery between FortiGates. The issue is with the Fabric connection between the root and downstream FortiGate, not with logging or analysis. This action would not resolve the missing device.
D
Reconfigure the root FortiGate's management IP.
Why it fails: Changing the root FortiGate's management IP is unnecessary and could disrupt the existing Fabric. The downstream FortiGate is configured with the correct root IP, so the root's IP is likely correct. The problem lies elsewhere, such as the downstream's Fabric enablement or authorization.

Question 10hardmultiple choice

A network security analyst is troubleshooting why certain inbound emails are being marked as spam by FortiMail even though they originate from a trusted partner's domain. The partner's domain has a valid SPF record, but the emails are failing the 'Domain-based Message Authentication, Reporting, and Conformance' (DMARC) check. The analyst confirms that the partner's emails are being forwarded by a third-party mailing list. What is the most likely reason for the DMARC failure?

Trap 1: The partner's DMARC policy is set to 'p=reject', which causes…

A 'p=reject' policy instructs receivers to reject emails that fail DMARC, but the scenario says emails are marked as spam, not rejected. FortiMail's action depends on its configuration, not solely on the DMARC policy. The policy itself does not cause the failure; it dictates the action. The root cause is the authentication failure, not the policy.

Trap 2: The third-party mailing list is modifying the 'From' header,…

DMARC alignment checks the 'From' header domain against the SPF or DKIM authenticated domain. If the mailing list modifies the 'From' header, alignment would fail. However, the scenario states the partner's domain has a valid SPF record, and forwarding typically affects SPF, not the 'From' header unless the list rewrites it. This is not the most likely cause given the details.

Trap 3: FortiMail is not configured to perform DKIM verification, so DMARC…

FortiMail does support DKIM verification and will perform it if enabled. However, even if DKIM is verified, DMARC requires alignment with the 'From' domain. The scenario does not indicate DKIM is disabled. The more likely issue is that DKIM signature is broken by the mailing list, not that FortiMail lacks DKIM verification capability.

A
The third-party mailing list is not included in the partner's SPF record, causing SPF to fail, which in turn causes DMARC to fail if DKIM is not aligned.
When a mailing list forwards email, the original SPF check fails because the forwarding server's IP is not in the original domain's SPF record. DMARC requires either SPF or DKIM to pass and align. If the mailing list does not modify the 'From' header and DKIM signature is broken or not aligned, DMARC fails. This is the most common reason for DMARC failures with forwarded mail.
B
The partner's DMARC policy is set to 'p=reject', which causes FortiMail to quarantine all emails from that domain.
Why it fails: A 'p=reject' policy instructs receivers to reject emails that fail DMARC, but the scenario says emails are marked as spam, not rejected. FortiMail's action depends on its configuration, not solely on the DMARC policy. The policy itself does not cause the failure; it dictates the action. The root cause is the authentication failure, not the policy.
C
The third-party mailing list is modifying the 'From' header, breaking the DMARC alignment.
Why it fails: DMARC alignment checks the 'From' header domain against the SPF or DKIM authenticated domain. If the mailing list modifies the 'From' header, alignment would fail. However, the scenario states the partner's domain has a valid SPF record, and forwarding typically affects SPF, not the 'From' header unless the list rewrites it. This is not the most likely cause given the details.
D
FortiMail is not configured to perform DKIM verification, so DMARC cannot pass even if SPF fails.
Why it fails: FortiMail does support DKIM verification and will perform it if enabled. However, even if DKIM is verified, DMARC requires alignment with the 'From' domain. The scenario does not indicate DKIM is disabled. The more likely issue is that DKIM signature is broken by the mailing list, not that FortiMail lacks DKIM verification capability.