How should I use these Troubleshooting 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 Troubleshooting 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 Troubleshooting domain.

NGFW-Engineer · topic practice

Troubleshooting practice questions

Practise Certified Next-Generation Firewall Engineer (NGFW-Engineer) Troubleshooting 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.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

9 questionsDomain: Troubleshooting

Practice 10 questions Browse domain →

What the exam tests

What to know about Troubleshooting

Troubleshooting 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 Troubleshooting 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

Troubleshooting questions

9 questions · select your answer, then reveal the explanation

Question 1hardmultiple choice

Study the full Python automation breakdown →

You are troubleshooting a REST API integration where Python scripts are failing to retrieve device information. The API returns a '403 Forbidden' error. What is the most likely cause?

Trap 1: The API Key is expired.

An expired API key typically returns 401 Unauthorised, since the credential fails authentication before authorisation is evaluated. Expiry governs identity validation, not permission. It would be correct if the API rejected the credential outright with a 401 response.

Trap 2: The JSON body is malformed.

A malformed JSON body would return 400 Bad Request, since the server rejects the payload's syntax before evaluating authorisation. JSON formatting governs request parsing, not identity. It would be the answer if the API returned a schema or parse error on a POST or PUT.

Trap 3: The API endpoint URL is incorrect.

An incorrect endpoint URL returns 404 Not Found, because the server cannot match the requested resource path. URL correctness governs routing, not permission. It would be correct if the script hit a valid host but a non-existent path, producing a 404 rather than a 403.

Study all Troubleshooting common traps →

A
The API Key is expired.
Why it fails: An expired API key typically returns 401 Unauthorised, since the credential fails authentication before authorisation is evaluated. Expiry governs identity validation, not permission. It would be correct if the API rejected the credential outright with a 401 response.
B
The JSON body is malformed.
Why it fails: A malformed JSON body would return 400 Bad Request, since the server rejects the payload's syntax before evaluating authorisation. JSON formatting governs request parsing, not identity. It would be the answer if the API returned a schema or parse error on a POST or PUT.
C
The admin account lacks permissions for the requested object.
A 403 Forbidden response means the request reached the device but was refused, so authentication succeeded. The admin account authenticated to the API lacks the role or permission profile required for the requested object, unlike 401, which signals failed authentication.
D
The API endpoint URL is incorrect.
Why it fails: An incorrect endpoint URL returns 404 Not Found, because the server cannot match the requested resource path. URL correctness governs routing, not permission. It would be correct if the script hit a valid host but a non-existent path, producing a 404 rather than a 403.

Full breakdown with real-world context →

Question 2hardmultiple choice

Review the full OSPF breakdown →

An engineer is troubleshooting a Palo Alto Networks firewall that is not forming an OSPF adjacency with a neighboring router. The engineer verifies that the interfaces are up, IP addresses are correct, and OSPF is enabled on both devices. The firewall is configured with an OSPF area ID of 0.0.0.1, and the neighbor is in area 0.0.0.0. The engineer checks the OSPF neighbor state and sees it stuck in EXSTART. What is the most likely cause of the problem?

Trap 1: Mismatched OSPF area IDs

Mismatched area IDs would prevent adjacency, but the neighbor state would typically be DOWN or INIT, not EXSTART. EXSTART indicates that the routers are attempting to exchange database description packets but are having issues with master/slave election. Area mismatch is not the cause of EXSTART.

Trap 2: Duplicate router IDs

Duplicate router IDs can cause OSPF issues, but typically they lead to a neighbor state of DOWN or 2-WAY, not EXSTART. In EXSTART, the routers have already discovered each other and are attempting to exchange databases. Duplicate router IDs would prevent adjacency earlier in the process.

Trap 3: Incorrect OSPF hello interval

An incorrect hello interval would prevent the routers from discovering each other, resulting in a neighbor state of DOWN or INIT. It would not allow the adjacency to progress to EXSTART. Therefore, this is not the cause of the EXSTART state.

Study all Troubleshooting common traps →

A
Mismatched OSPF area IDs
Why it fails: Mismatched area IDs would prevent adjacency, but the neighbor state would typically be DOWN or INIT, not EXSTART. EXSTART indicates that the routers are attempting to exchange database description packets but are having issues with master/slave election. Area mismatch is not the cause of EXSTART.
B
MTU mismatch on the interfaces
In OSPF, the EXSTART state is where the master/slave relationship is determined for database exchange. If the MTU on the interfaces does not match, the routers cannot agree on the initial sequence numbers, and the adjacency remains stuck in EXSTART. This is a common cause of OSPF adjacency issues, and the scenario points to this as the likely culprit.
C
Duplicate router IDs
Why it fails: Duplicate router IDs can cause OSPF issues, but typically they lead to a neighbor state of DOWN or 2-WAY, not EXSTART. In EXSTART, the routers have already discovered each other and are attempting to exchange databases. Duplicate router IDs would prevent adjacency earlier in the process.
D
Incorrect OSPF hello interval
Why it fails: An incorrect hello interval would prevent the routers from discovering each other, resulting in a neighbor state of DOWN or INIT. It would not allow the adjacency to progress to EXSTART. Therefore, this is not the cause of the EXSTART state.

Full breakdown with real-world context →

Question 3hardmulti select

Read the full Troubleshooting explanation →

Which THREE actions should be performed during a standard automation failure troubleshooting process?

Trap 1: Update the hardware firmware.

Updates should be planned, not used for troubleshooting.

Trap 2: Perform a factory reset of the firewall.

Extreme and unnecessary.

Study all Troubleshooting common traps →

A
Validate API key permissions for the target object.
Authorization is a frequent source of failures.
B
Verify the API service status on the firewall.
Ensure the endpoint is listening.
C
Review system logs for 'auth' or 'API' errors.
Logs provide the specific reason for failure.
D
Update the hardware firmware.
Why it fails: Updates should be planned, not used for troubleshooting.
E
Perform a factory reset of the firewall.
Why it fails: Extreme and unnecessary.

Full breakdown with real-world context →

Question 4hardmulti select

Read the full Troubleshooting explanation →

Which TWO methods are used to troubleshoot GlobalProtect connectivity issues?

Trap 1: Change the encryption algorithm

Changing the encryption algorithm alters the IPsec or SSL proposal rather than gathering diagnostic evidence, so it cannot troubleshoot GlobalProtect connectivity. It is tempting because adjusting crypto settings is the correct action when a peer rejects the proposed suite during IKE or SSL negotiation, not for general connectivity diagnosis.

Trap 2: Reload the firewall firmware

Reloading firewall firmware reboots the dataplane and interrupts all sessions without isolating the GlobalProtect fault, so it cannot troubleshoot connectivity. It is tempting because a firmware reload is the correct action when the device is unresponsive or running corrupted software, not for diagnosing tunnel or authentication failures.

Trap 3: Restart the management plane

Restarting the management plane disrupts administrative access and does not diagnose tunnel, authentication or routing faults, so it cannot troubleshoot GlobalProtect connectivity. It is tempting because a management-plane restart is a legitimate remedy when the web UI or commit process hangs, not for client connectivity faults.

Study all Troubleshooting common traps →

A
Change the encryption algorithm
Why it fails: Changing the encryption algorithm alters the IPsec or SSL proposal rather than gathering diagnostic evidence, so it cannot troubleshoot GlobalProtect connectivity. It is tempting because adjusting crypto settings is the correct action when a peer rejects the proposed suite during IKE or SSL negotiation, not for general connectivity diagnosis.
B
Reload the firewall firmware
Why it fails: Reloading firewall firmware reboots the dataplane and interrupts all sessions without isolating the GlobalProtect fault, so it cannot troubleshoot connectivity. It is tempting because a firmware reload is the correct action when the device is unresponsive or running corrupted software, not for diagnosing tunnel or authentication failures.
C
Restart the management plane
Why it fails: Restarting the management plane disrupts administrative access and does not diagnose tunnel, authentication or routing faults, so it cannot troubleshoot GlobalProtect connectivity. It is tempting because a management-plane restart is a legitimate remedy when the web UI or commit process hangs, not for client connectivity faults.
D
Check firewall System and GlobalProtect logs
Firewall System and GlobalProtect logs record tunnel negotiation, authentication and gateway-selection events, so they pinpoint where connectivity fails. This satisfies the stem's troubleshooting requirement by exposing the actual failure reason, such as certificate rejection or portal unreachable, rather than merely confirming that a client cannot connect.
E
Check GP client logs
GP client logs record the portal and gateway negotiation sequence, including certificate validation, authentication exchanges and tunnel establishment failures. This directly satisfies the troubleshooting requirement by exposing where connectivity breaks, whether at pre-login, gateway selection or IPsec negotiation, giving the specific error codes needed to isolate the fault.

Full breakdown with real-world context →

Question 5hardmulti select

Review the full OSPF breakdown →

Which TWO commands are useful for troubleshooting OSPF?

Trap 1: show system processes

show system processes lists management-plane daemons and resource usage, revealing nothing about OSPF adjacencies or link states. It is tempting for general platform health checks, where it would be the right command, but OSPF troubleshooting needs show routing protocol ospf neighbour and related routing commands.

Trap 2: show hardware

show hardware reports chassis, interface and component inventory, providing no OSPF adjacency, area or link-state detail. It is tempting for verifying interface up/down status during outages, where it would be correct, but OSPF troubleshooting requires show routing protocol ospf neighbour and show routing protocol ospf commands.

Trap 3: show log routing

show log routing displays routing daemon log entries, which may hint at OSPF events but does not expose neighbour states, link-state database contents or interface timers directly. It is tempting because logs often reveal protocol errors, yet the expected OSPF commands are show routing protocol ospf neighbour and show routing protocol ospf.

Study all Troubleshooting common traps →

A
show system processes
Why it fails: show system processes lists management-plane daemons and resource usage, revealing nothing about OSPF adjacencies or link states. It is tempting for general platform health checks, where it would be the right command, but OSPF troubleshooting needs show routing protocol ospf neighbour and related routing commands.
B
show routing protocol ospf rib
Displaying the OSPF routing information base shows which routes OSPF computed and their paths, letting you verify whether learned routes were installed or rejected. This satisfies the troubleshooting need by distinguishing a routing-table problem from an adjacency or link-state database problem.
C
show hardware
Why it fails: show hardware reports chassis, interface and component inventory, providing no OSPF adjacency, area or link-state detail. It is tempting for verifying interface up/down status during outages, where it would be correct, but OSPF troubleshooting requires show routing protocol ospf neighbour and show routing protocol ospf commands.
D
show routing protocol ospf neighbor
This command lists OSPF neighbour adjacencies with their states, revealing stuck ExStart or Exchange relationships and mismatched areas or timers. It directly satisfies the troubleshooting need by exposing adjacency failures, which is the most common cause of OSPF routes not being installed.
E
show log routing
Why it fails: show log routing displays routing daemon log entries, which may hint at OSPF events but does not expose neighbour states, link-state database contents or interface timers directly. It is tempting because logs often reveal protocol errors, yet the expected OSPF commands are show routing protocol ospf neighbour and show routing protocol ospf.

Full breakdown with real-world context →

Question 6hardmultiple choice

Review the full routing breakdown →

You are troubleshooting GlobalProtect and notice the client cannot reach internal resources. Which routing issue is most likely?

Trap 1: Missing certificate on the gateway

A missing gateway certificate breaks the TLS handshake, so the tunnel never establishes and no internal traffic flows at all; the stem describes a client that connects yet cannot reach resources, which is a routing symptom. Certificate absence is the right diagnosis when GlobalProtect fails at authentication or connection setup.

Trap 2: Missing default route on the client machine

GlobalProtect delivers internal routes to the client through the tunnel's virtual adapter, so a missing default route on the endpoint does not explain failure to reach internal resources; internet-bound traffic would break instead. A missing default route is the correct diagnosis when the client connects but cannot reach external destinations.

Trap 3: Incorrect zone on the tunnel interface

An incorrect zone on the tunnel interface is a policy or security-zone misconfiguration, not a routing issue, so it falls outside the fault class the question asks about. Zone assignment is the correct diagnosis when the tunnel is up and routes exist but security policy silently drops the permitted traffic.

Study all Troubleshooting common traps →

A
Missing certificate on the gateway
Why it fails: A missing gateway certificate breaks the TLS handshake, so the tunnel never establishes and no internal traffic flows at all; the stem describes a client that connects yet cannot reach resources, which is a routing symptom. Certificate absence is the right diagnosis when GlobalProtect fails at authentication or connection setup.
B
Missing default route on the client machine
Why it fails: GlobalProtect delivers internal routes to the client through the tunnel's virtual adapter, so a missing default route on the endpoint does not explain failure to reach internal resources; internet-bound traffic would break instead. A missing default route is the correct diagnosis when the client connects but cannot reach external destinations.
C
Missing route in the virtual router to the internal network
GlobalProtect clients terminate on the firewall, which then forwards traffic to internal networks via its virtual router. Without a route to the internal subnet in that virtual router, return or forward traffic is dropped, so the missing route directly explains the reachability failure.
D
Incorrect zone on the tunnel interface
Why it fails: An incorrect zone on the tunnel interface is a policy or security-zone misconfiguration, not a routing issue, so it falls outside the fault class the question asks about. Zone assignment is the correct diagnosis when the tunnel is up and routes exist but security policy silently drops the permitted traffic.

Full breakdown with real-world context →

Question 7hardmultiple choice

Review the full routing breakdown →

An administrator is troubleshooting a routing issue on a PAN-OS firewall. The firewall has two virtual routers: VR1 and VR2. Interface ethernet1/1 is assigned to VR1, and ethernet1/2 is assigned to VR2. A packet arrives on ethernet1/1 destined for a network reachable via ethernet1/2. How does the firewall determine which virtual router to use for the packet?

Trap 1: The firewall uses the virtual router associated with the egress…

The egress interface's virtual router is not used for the initial routing lookup. Routing decisions are based on the ingress virtual router. The egress interface is determined by the route lookup result. If the route points to an interface in a different VR, the packet may be dropped. So the egress VR does not drive the decision.

Trap 2: The firewall uses the virtual router with the lowest administrative…

Administrative distance is used within a virtual router to select the best route among multiple routing sources. It does not determine which virtual router to use. Virtual router selection is based on ingress interface, not on administrative distance. The firewall does not compare routes across different virtual routers by default.

Trap 3: The firewall uses the virtual router that has a default route…

Having a default route in a virtual router does not dictate its use for a packet. The ingress interface determines the virtual router. If the ingress VR does not have a route to the destination, the packet is dropped, even if another VR has a default route. Default routes are only considered within the context of the ingress virtual router.

Study all Troubleshooting common traps →

A
The firewall uses the virtual router associated with the egress interface to make the routing decision.
Why it fails: The egress interface's virtual router is not used for the initial routing lookup. Routing decisions are based on the ingress virtual router. The egress interface is determined by the route lookup result. If the route points to an interface in a different VR, the packet may be dropped. So the egress VR does not drive the decision.
B
The firewall uses the virtual router with the lowest administrative distance for the destination network.
Why it fails: Administrative distance is used within a virtual router to select the best route among multiple routing sources. It does not determine which virtual router to use. Virtual router selection is based on ingress interface, not on administrative distance. The firewall does not compare routes across different virtual routers by default.
C
The firewall uses the virtual router associated with the ingress interface to make the routing decision.
In PAN-OS, the virtual router for a packet is determined by the ingress interface. The firewall looks up the destination in the routing table of the virtual router to which the ingress interface is assigned. If the route points to an egress interface in a different virtual router, the packet is dropped unless there is a route leaking configuration. So the ingress VR is used for the initial lookup.
D
The firewall uses the virtual router that has a default route configured.
Why it fails: Having a default route in a virtual router does not dictate its use for a packet. The ingress interface determines the virtual router. If the ingress VR does not have a route to the destination, the packet is dropped, even if another VR has a default route. Default routes are only considered within the context of the ingress virtual router.

Full breakdown with real-world context →

Question 8hardmultiple choice

Read the full Troubleshooting explanation →

You are troubleshooting a REST API integration issue where the firewall returns '400 Bad Request'. What should you check first?

Trap 1: The server's internal firewall status.

A 400 response originates from the API endpoint parsing the request, so the server's own firewall state cannot produce it; malformed JSON, headers or parameters must be inspected. Checking local firewall status suits connectivity failures such as refused or dropped connections, not a syntactically invalid request reaching the service.

Trap 2: The network latency between client and firewall.

A 400 Bad Request means the firewall rejected the request as malformed, so latency is irrelevant; the payload, headers, content type or URI syntax must be validated. Latency checks suit diagnosing timeouts or slow responses, where the client waits rather than receiving an immediate client-error rejection.

Trap 3: The API Key expiry date.

An expired API key yields 401 Unauthorised or 403 Forbidden, not 400 Bad Request, because authentication is evaluated separately from request syntax. Checking key expiry is the right first step when the firewall returns authentication or authorisation errors, indicating the credential rather than the payload is at fault.

Study all Troubleshooting common traps →

A
The server's internal firewall status.
Why it fails: A 400 response originates from the API endpoint parsing the request, so the server's own firewall state cannot produce it; malformed JSON, headers or parameters must be inspected. Checking local firewall status suits connectivity failures such as refused or dropped connections, not a syntactically invalid request reaching the service.
B
The request payload syntax.
A 400 Bad Request is a client-side syntax error, so the payload's structure, malformed JSON or XML, invalid field names or missing required parameters must be validated first. Checking payload syntax directly addresses the malformed-request constraint the firewall is rejecting before investigating authentication or endpoint issues.
C
The network latency between client and firewall.
Why it fails: A 400 Bad Request means the firewall rejected the request as malformed, so latency is irrelevant; the payload, headers, content type or URI syntax must be validated. Latency checks suit diagnosing timeouts or slow responses, where the client waits rather than receiving an immediate client-error rejection.
D
The API Key expiry date.
Why it fails: An expired API key yields 401 Unauthorised or 403 Forbidden, not 400 Bad Request, because authentication is evaluated separately from request syntax. Checking key expiry is the right first step when the firewall returns authentication or authorisation errors, indicating the credential rather than the payload is at fault.

Full breakdown with real-world context →

Question 9hardmultiple choice

Read the full Troubleshooting explanation →

A client is receiving a 'Gateway not reachable' error in GlobalProtect. What is a common troubleshooting step?

Trap 1: Increase the tunnel encryption level

Raising tunnel encryption changes the IPsec proposal, which is negotiated only after the client reaches the gateway; it cannot resolve an unreachable gateway. It is tempting because encryption mismatches do break established tunnels, but that produces negotiation or phase failures, not a pre-connection reachability error.

Trap 2: Check the local PC's DHCP settings

DHCP settings only affect IP address assignment; the 'Gateway not reachable' error indicates the client cannot reach the GlobalProtect portal or gateway address, so local addressing is not the fault. It is tempting because DHCP misconfiguration does break connectivity, but that would produce an address or DNS failure instead.

Trap 3: Clear the routing cache on the client

Clearing the routing cache is not a GlobalProtect troubleshooting step, and no such client-side cache exists for this error. It is tempting because stale routes do cause reachability failures in general networking, but the gateway-unreachable condition stems from portal address, certificate or firewall reachability issues.

Study all Troubleshooting common traps →

A
Increase the tunnel encryption level
Why it fails: Raising tunnel encryption changes the IPsec proposal, which is negotiated only after the client reaches the gateway; it cannot resolve an unreachable gateway. It is tempting because encryption mismatches do break established tunnels, but that produces negotiation or phase failures, not a pre-connection reachability error.
B
Check the local PC's DHCP settings
Why it fails: DHCP settings only affect IP address assignment; the 'Gateway not reachable' error indicates the client cannot reach the GlobalProtect portal or gateway address, so local addressing is not the fault. It is tempting because DHCP misconfiguration does break connectivity, but that would produce an address or DNS failure instead.
C
Verify security policies allow traffic to the gateway
GlobalProtect gateway reachability depends on the firewall permitting the portal and gateway traffic, so confirming security policies allow it isolates a policy block from routing or certificate faults. This satisfies the stem's need for a common troubleshooting step when the client reports 'Gateway not reachable'.
D
Clear the routing cache on the client
Why it fails: Clearing the routing cache is not a GlobalProtect troubleshooting step, and no such client-side cache exists for this error. It is tempting because stale routes do cause reachability failures in general networking, but the gateway-unreachable condition stems from portal address, certificate or firewall reachability issues.

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 Troubleshooting sessions

Start a Troubleshooting only practice session

Every question in these sessions is drawn from the Troubleshooting domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Troubleshooting questions →Mixed NGFW-Engineer session

Frequently asked questions

What does the NGFW-Engineer exam test about Troubleshooting?: Troubleshooting 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 Troubleshooting questions in a focused session?: Yes — the session launcher on this page draws every question from the Troubleshooting 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 NGFW-Engineer topics?: Use the topic links above to move to related areas, or go back to the NGFW-Engineer 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 NGFW-Engineer exam covers. They are not copied from any real exam or dump site.

Troubleshooting only

10 questions 20 questions 30 questions 50 questions

Mixed NGFW-Engineer session

Track your progress

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

Study resources

All NGFW-Engineer questions Troubleshooting domain overview NGFW-Engineer 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.

Troubleshooting practice questions

What to know about Troubleshooting

Common Troubleshooting exam traps

Troubleshooting questions

You are troubleshooting a REST API integration where Python scripts are failing to retrieve device information. The API returns a '403 Forbidden' error. What is the most likely cause?

Which THREE actions should be performed during a standard automation failure troubleshooting process?

Which TWO methods are used to troubleshoot GlobalProtect connectivity issues?

Which TWO commands are useful for troubleshooting OSPF?

You are troubleshooting GlobalProtect and notice the client cannot reach internal resources. Which routing issue is most likely?

You are troubleshooting a REST API integration issue where the firewall returns '400 Bad Request'. What should you check first?

A client is receiving a 'Gateway not reachable' error in GlobalProtect. What is a common troubleshooting step?

Track your progress over time

Start a Troubleshooting only practice session

Related NGFW-Engineer topic practice pages

Integration And Automation practice questions

PAN OS Device Setting Configuration practice questions

PAN OS Networking Configuration practice questions

NGFW-Engineer fundamentals practice questions

NGFW-Engineer scenario practice questions

NGFW-Engineer troubleshooting practice questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid