Troubleshooting practice questions

An administrator is configuring security policies on a Palo Alto Networks firewall and wants to ensure best practices for rule organization and management. Which TWO practices are recommended when designing security rules? (Choose two)

Trap 1: Disable logging on all security rules to conserve management plane…

Logging must remain enabled on security rules; logs feed traffic analysis, threat detection and forensic investigation. Disabling logging conserves management-plane CPU, which is why it tempts administrators facing resource pressure, but that saving sacrifices the visibility the firewall exists to provide.

Trap 2: Always use the 'any' source zone to ensure all internal subnets are…

Using 'any' source zone collapses inter-zone and intra-zone distinctions, granting unintended lateral access and defeating zone-based segmentation. It tempts administrators wanting one rule to cover every internal subnet, but zones should be scoped explicitly so policy reflects the intended trust boundaries.

Trap 3: Place broad, permissive rules at the top of the security policy…

Broad permissive rules at the top shadow the specific deny and allow rules beneath them, so later rules never match. Placing them first does reduce evaluation depth, which is the tempting rationale, but rule order should run specific-to-general with implicit deny at the base.

A
Group related security rules into logical rule categories for easier management and auditing.
Grouping related rules into logical categories keeps the rulebase ordered and readable, so administrators can audit, review and troubleshoot policies efficiently. This supports the recommended top-down organisation, reducing shadowed or redundant rules as the policy set grows.
B
Disable logging on all security rules to conserve management plane CPU resources.
Why it fails: Logging must remain enabled on security rules; logs feed traffic analysis, threat detection and forensic investigation. Disabling logging conserves management-plane CPU, which is why it tempts administrators facing resource pressure, but that saving sacrifices the visibility the firewall exists to provide.
C
Always use the 'any' source zone to ensure all internal subnets are covered simultaneously.
Why it fails: Using 'any' source zone collapses inter-zone and intra-zone distinctions, granting unintended lateral access and defeating zone-based segmentation. It tempts administrators wanting one rule to cover every internal subnet, but zones should be scoped explicitly so policy reflects the intended trust boundaries.
D
Use specific Application definitions (App-ID) instead of generic port-based rules wherever feasible.
App-ID identifies applications by their actual traffic signatures rather than port and protocol alone, so rules permit only the intended application. This satisfies the best-practise constraint by reducing overly permissive port-based rules that attackers abuse for lateral movement or unauthorised services.
E
Place broad, permissive rules at the top of the security policy base to speed up rule evaluation.
Why it fails: Broad permissive rules at the top shadow the specific deny and allow rules beneath them, so later rules never match. Placing them first does reduce evaluation depth, which is the tempting rationale, but rule order should run specific-to-general with implicit deny at the base.

Question 2hardmulti select

An administrator notices that the firewall's management plane CPU utilization is consistently at 99%. Which THREE factors or troubleshooting steps should the administrator investigate? (Choose three)

Trap 1: An improperly sized Layer 3 forwarding table causing next-hop…

Layer 3 forwarding and next-hop re-synthesis occur on the data plane's forwarding ASICs and CPU, leaving management plane utilisation untouched. It is tempting because an undersized forwarding table genuinely causes packet drops and re-synthesis, so it would be the correct investigation if the symptom were data plane throughput loss rather than 99% management CPU.

Trap 2: GlobalProtect Gateway SSL VPN data tunnel encryption processing.

SSL VPN data tunnel encryption is processed by the data plane's session and decryption hardware, not the management plane, so it cannot drive management CPU to 99%. It is tempting because GlobalProtect is a headline firewall feature, and heavy tunnel encryption would be the right suspect if data plane throughput, not management responsiveness, were degraded.

A
Excessive XML API requests or frequent script-based configuration pushes.
Excessive XML API calls or script-driven configuration pushes load the management plane directly, since that CPU handles parsing and commit operations rather than dataplane traffic. This satisfies the stem's constraint of sustained 99% management-plane utilisation, distinguishing control-plane processing from forwarding load.
B
An improperly sized Layer 3 forwarding table causing next-hop packet re-synthesis on the data plane.
Why it fails: Layer 3 forwarding and next-hop re-synthesis occur on the data plane's forwarding ASICs and CPU, leaving management plane utilisation untouched. It is tempting because an undersized forwarding table genuinely causes packet drops and re-synthesis, so it would be the correct investigation if the symptom were data plane throughput loss rather than 99% management CPU.
C
High volume of logging queries, traffic log exports, or Panorama log forwarding activity.
Heavy logging queries, log exports, and Panorama log forwarding all consume management plane CPU, so sustained 99% utilisation points to logging overhead. This satisfies the requirement to investigate a genuine contributing factor, since log processing runs on the management plane rather than the dataplane.
D
Large or excessively frequent External Dynamic List (EDL) downloads saturating management plane retrieval threads.
EDL retrieval runs on the management plane, so oversized or overly frequent downloads consume its retrieval threads and drive CPU to saturation. Investigating list size and refresh interval directly addresses the management plane bottleneck described in the stem.
E
GlobalProtect Gateway SSL VPN data tunnel encryption processing.
Why it fails: SSL VPN data tunnel encryption is processed by the data plane's session and decryption hardware, not the management plane, so it cannot drive management CPU to 99%. It is tempting because GlobalProtect is a headline firewall feature, and heavy tunnel encryption would be the right suspect if data plane throughput, not management responsiveness, were degraded.

Open the full BGP breakdown →

Question 3hardmultiple choice

An administrator is troubleshooting a BGP routing peer connection between the Palo Alto Networks firewall and an external provider router. The BGP session is stuck in the 'Connect' state. Inspection of system logs indicates TCP port 179 packets sent by the firewall are being transmitted, but no SYN-ACK is received. Which troubleshooting step or feature verification should be performed first?

Trap 1: Reconfigure the Virtual Wire interface pair to handle BGP…

Virtual Wire interfaces forward frames transparently at layer 2 and do not encapsulate or decapsulate BGP; the Connect state with no SYN-ACK indicates a TCP reachability or firewall-policy problem on port 179. Virtual Wire is tempting for inline inspection deployments, but it cannot resolve a blocked TCP handshake.

Trap 2: Restart the Management server process using the CLI command 'debug…

Restarting the management server affects only the firewall's web UI and configuration daemon, not the dataplane BGP process or TCP 179 handling. It is tempting because management-plane restarts often clear stuck GUI sessions, and would be right if the management interface itself were unresponsive rather than the routing peer.

Trap 3: Convert the BGP peer to OSPFv3 protocol.

The Connect state with no SYN-ACK indicates the TCP handshake to port 179 is failing, so the first check is reachability and filtering of TCP 179, not changing routing protocol. It is tempting because OSPFv3 is also a dynamic routing protocol, and it would be correct if the requirement were IPv6 interior routing rather than BGP peering.

A
Verify that a Security policy rule with application 'bgp' (or service tcp-179) from the external zone to 'zone: 'to-firewall'' permits control plane traffic, or check Zone Protection / Management Profile settings.
A BGP session stuck in Connect with SYNs sent but no SYN-ACK indicates the firewall's own policy is dropping inbound TCP/179. Verifying a Security policy rule permitting application bgp from the external zone to the to-firewall zone confirms control-plane traffic is allowed.
B
Reconfigure the Virtual Wire interface pair to handle BGP encapsulation headers.
Why it fails: Virtual Wire interfaces forward frames transparently at layer 2 and do not encapsulate or decapsulate BGP; the Connect state with no SYN-ACK indicates a TCP reachability or firewall-policy problem on port 179. Virtual Wire is tempting for inline inspection deployments, but it cannot resolve a blocked TCP handshake.
C
Restart the Management server process using the CLI command 'debug software restart management-server'.
Why it fails: Restarting the management server affects only the firewall's web UI and configuration daemon, not the dataplane BGP process or TCP 179 handling. It is tempting because management-plane restarts often clear stuck GUI sessions, and would be right if the management interface itself were unresponsive rather than the routing peer.
D
Convert the BGP peer to OSPFv3 protocol.
Why it fails: The Connect state with no SYN-ACK indicates the TCP handshake to port 179 is failing, so the first check is reachability and filtering of TCP 179, not changing routing protocol. It is tempting because OSPFv3 is also a dynamic routing protocol, and it would be correct if the requirement were IPv6 interior routing rather than BGP peering.

Question 4mediummultiple choice

A security administrator is troubleshooting an issue where internal users cannot reach a specific external website, and the traffic is being dropped by the firewall. The administrator suspects a Threat Prevention profile is blocking the response as a command-and-control callback. Where should the administrator look to verify the exact threat signature ID and packet capture that triggered the block?

Trap 1: Policies > Security

The Security policy area configures which Threat Prevention profile applies to traffic, but it does not retain the signature ID or packet capture of an individual block event. It is tempting because this is where you would confirm or adjust the profile itself, which is the right place to change blocking behaviour.

Trap 2: Network > Network Profiles > Zones

Zone objects define interfaces and traffic segmentation; they hold no threat signature IDs or packet captures. It is tempting because zones are where firewall policy is scoped, and would be the correct place to verify whether traffic is even reaching the inspection engine before a profile evaluates it.

Trap 3: Monitor > Logs > Traffic

Traffic logs record session-level allow and deny decisions with source, destination and port, but not the threat signature ID or associated packet capture. It is tempting because traffic logs are the natural first stop for connectivity drops, and would be correct for confirming whether the firewall dropped the session at all.

A
Monitor > Logs > Threat
Monitor > Logs > Threat records each Threat Prevention block with its signature ID, severity, and the associated packet capture, directly satisfying the need to verify which signature dropped the response. Filtering by the destination website and C2 category isolates the exact entry, confirming whether the callback verdict was a false positive.
B
Policies > Security
Why it fails: The Security policy area configures which Threat Prevention profile applies to traffic, but it does not retain the signature ID or packet capture of an individual block event. It is tempting because this is where you would confirm or adjust the profile itself, which is the right place to change blocking behaviour.
C
Network > Network Profiles > Zones
Why it fails: Zone objects define interfaces and traffic segmentation; they hold no threat signature IDs or packet captures. It is tempting because zones are where firewall policy is scoped, and would be the correct place to verify whether traffic is even reaching the inspection engine before a profile evaluates it.
D
Monitor > Logs > Traffic
Why it fails: Traffic logs record session-level allow and deny decisions with source, destination and port, but not the threat signature ID or associated packet capture. It is tempting because traffic logs are the natural first stop for connectivity drops, and would be correct for confirming whether the firewall dropped the session at all.

Read the full VPN explanation →

Question 5hardmultiple choice

An administrator is configuring a secure IPsec VPN tunnel between an on-premises Palo Alto Networks firewall and a Prisma Access Remote Networks mobile gateway. During negotiation, Phase 2 fails. Where should the administrator check to view detailed IKE and IPsec negotiation error messages?

Trap 1: Review the AWS VPC Flow Logs in the Amazon CloudWatch console.

Incorrect. VPC Flow Logs record IP traffic metadata, not IPsec cryptographic negotiation errors.

Trap 2: Navigate to Prisma Cloud Compute > Monitor > Audit logs.

Incorrect. Prisma Cloud Compute logs container runtime events, not firewall IPsec tunnels.

Trap 3: Open the WildFire submission report for the crypto module hash.

Incorrect. WildFire analyzes malware files.

A
Review the AWS VPC Flow Logs in the Amazon CloudWatch console.
Why it fails: Incorrect. VPC Flow Logs record IP traffic metadata, not IPsec cryptographic negotiation errors.
B
Run the CLI command `tail follow yes mp-log ikemgr.log` or check the System and GlobalProtect logs in Panorama/Firewall.
The `ikemgr.log` records IKE daemon activity, including Phase 2 (IPsec SA) negotiation failures, so `tail follow yes mp-log ikemgr.log` exposes detailed error messages such as proxy-ID or encryption mismatch. Panorama's System logs aggregate these events centrally, satisfying the requirement to view detailed IKE and IPsec negotiation errors.
C
Navigate to Prisma Cloud Compute > Monitor > Audit logs.
Why it fails: Incorrect. Prisma Cloud Compute logs container runtime events, not firewall IPsec tunnels.
D
Open the WildFire submission report for the crypto module hash.
Why it fails: Incorrect. WildFire analyzes malware files.

Question 6mediummulti select

Which THREE diagnostic or troubleshooting steps can be performed using the 'cytool' command-line utility on a local endpoint? (Choose three)

Trap 1: Configuring enterprise LDAP domain controller replication schedules.

cytool operates on the local endpoint's own agent configuration and diagnostics; it cannot reach directory services to alter enterprise LDAP domain controller replication schedules, which are configured on the domain controllers themselves. It is tempting because cytool does expose identity-related settings locally, but enterprise-wide directory replication is outside its scope.

Trap 2: Modifying global firewall NAT routing tables on the core switch.

cytool runs on a local endpoint and cannot modify NAT routing tables on core network switches, which are configured on the switches themselves. It is tempting because cytool reports local network connectivity and firewall state, but changing core infrastructure routing is a network-device administration task, not endpoint diagnostics.

A
Generating support logs and diagnostic dumps ('cytool support dump').
The support dump subcommand packages agent logs, configuration and diagnostic data into an archive for offline analysis, satisfying the stem's requirement for a local troubleshooting step. It captures endpoint state without needing a remote console, which is exactly what on-box diagnostics demand.
B
Checking protection module states ('cytool protection query').
'cytool protection query' reports which protection modules are enabled or disabled on the endpoint, letting an analyst confirm the security posture. It satisfies the diagnostic requirement of checking module states locally via the command-line utility.
C
Configuring enterprise LDAP domain controller replication schedules.
Why it fails: cytool operates on the local endpoint's own agent configuration and diagnostics; it cannot reach directory services to alter enterprise LDAP domain controller replication schedules, which are configured on the domain controllers themselves. It is tempting because cytool does expose identity-related settings locally, but enterprise-wide directory replication is outside its scope.
D
Querying overall agent status and operational health ('cytool query status').
The query status subcommand reports the local agent's running state, version and health indicators, fulfilling the stem's need for an on-endpoint diagnostic action. It confirms whether the agent is functioning before deeper troubleshooting, which is precisely the operational-health check the scenario requires.
E
Modifying global firewall NAT routing tables on the core switch.
Why it fails: cytool runs on a local endpoint and cannot modify NAT routing tables on core network switches, which are configured on the switches themselves. It is tempting because cytool reports local network connectivity and firewall state, but changing core infrastructure routing is a network-device administration task, not endpoint diagnostics.

Read the full DNS explanation →

Question 7mediummulti select

An administrator is troubleshooting a scenario where internal clients cannot resolve external domain names through the firewall configured as a DNS proxy. Which TWO settings should be verified on the firewall? (Choose two)

Trap 1: Ensure captive portal redirection is enabled on the loopback…

Captive portal redirection governs user authentication on the loopback interface, not DNS proxy forwarding. It is tempting because captive portals do intercept client traffic, but they handle HTTP/HTTPS authentication, not name resolution. The DNS proxy requires a valid DNS server profile and security policy permitting UDP/TCP port 53 to external resolvers.

Trap 2: Verify that BGP routing is enabled on all Layer 2 trust interfaces.

BGP is a Layer 3 dynamic routing protocol and has no bearing on DNS proxy resolution; Layer 2 trust interfaces do not run it. It is tempting when troubleshooting routing failures, and would be correct if clients could not reach external networks at all.

Trap 3: Check that the GlobalProtect portal certificate is installed in the…

The GlobalProtect portal certificate secures VPN authentication between endpoints and the portal; it plays no part in DNS proxy resolution. It is tempting because certificate trust failures do break connectivity, but only for GlobalProtect tunnels. DNS proxy troubleshooting requires verifying the DNS server profile and the security policy allowing port 53 traffic.

A
Ensure captive portal redirection is enabled on the loopback address.
Why it fails: Captive portal redirection governs user authentication on the loopback interface, not DNS proxy forwarding. It is tempting because captive portals do intercept client traffic, but they handle HTTP/HTTPS authentication, not name resolution. The DNS proxy requires a valid DNS server profile and security policy permitting UDP/TCP port 53 to external resolvers.
B
Verify that the DNS Proxy object has valid primary and secondary external DNS server IP addresses configured.
The DNS proxy forwards queries to upstream resolvers, so invalid or missing primary and secondary external DNS server addresses cause resolution failures for internal clients. Verifying these configured IPs confirms the proxy has reachable forwarders for external domain lookups.
C
Verify that BGP routing is enabled on all Layer 2 trust interfaces.
Why it fails: BGP is a Layer 3 dynamic routing protocol and has no bearing on DNS proxy resolution; Layer 2 trust interfaces do not run it. It is tempting when troubleshooting routing failures, and would be correct if clients could not reach external networks at all.
D
Check that the GlobalProtect portal certificate is installed in the trusted root store.
Why it fails: The GlobalProtect portal certificate secures VPN authentication between endpoints and the portal; it plays no part in DNS proxy resolution. It is tempting because certificate trust failures do break connectivity, but only for GlobalProtect tunnels. DNS proxy troubleshooting requires verifying the DNS server profile and the security policy allowing port 53 traffic.
E
Ensure the interface receiving client DNS requests has the DNS Proxy enabled in its Network Profile settings.
DNS proxy must be enabled on the specific interface receiving client queries; otherwise the firewall will not intercept or forward those requests, so external names fail to resolve. Verifying this Network Profile setting satisfies the stem's constraint of troubleshooting the DNS proxy path.

Question 8mediummultiple choice

A network administrator is troubleshooting why an internal application is unable to communicate with an external API over a non-standard TCP port. The firewall's security policy allows the IP addresses and port, but traffic is being dropped by threat prevention. Upon checking logs, the administrator sees a threat ID associated with a vulnerability signature. What is the most appropriate way to resolve a false positive safely?

Trap 1: Disable the Vulnerability Protection profile globally across all…

Disabling the profile globally removes vulnerability inspection for every security rule, leaving all traffic unprotected rather than addressing the single false-positive signature. Global disablement suits emergency containment during an active outbreak, where halting all matching traffic outweighs inspection loss — not routine false-positive tuning.

Trap 2: Configure an Application Override policy for the custom API port

Application Override bypasses signature inspection for the port, but the stem requires resolving a false positive while retaining threat protection; it also cannot distinguish legitimate API traffic from exploits on that port. Application Override is intended for custom applications whose traffic a standard App-ID misclassifies, not for suppressing a vulnerability signature.

Trap 3: Delete the threat signature from the firewall's local database cache

Deleting the signature removes detection of the actual vulnerability for every host, not just this false positive, leaving the network exposed. The safe fix is an exception scoped to the specific source, destination and application. Deleting signatures suits retiring a genuinely obsolete or superseded threat ID, not resolving a false positive.

A
Disable the Vulnerability Protection profile globally across all security rules
Why it fails: Disabling the profile globally removes vulnerability inspection for every security rule, leaving all traffic unprotected rather than addressing the single false-positive signature. Global disablement suits emergency containment during an active outbreak, where halting all matching traffic outweighs inspection loss — not routine false-positive tuning.
B
Create a Vulnerability Protection Exception for the specific threat ID, optionally restricting it to the source or destination IP
A Vulnerability Protection Exception for that specific threat ID disables the signature's action for the matching traffic, clearing the false positive without weakening the broader security policy. Restricting it to the source or destination IP narrows scope, avoiding blanket exposure.
C
Configure an Application Override policy for the custom API port
Why it fails: Application Override bypasses signature inspection for the port, but the stem requires resolving a false positive while retaining threat protection; it also cannot distinguish legitimate API traffic from exploits on that port. Application Override is intended for custom applications whose traffic a standard App-ID misclassifies, not for suppressing a vulnerability signature.
D
Delete the threat signature from the firewall's local database cache
Why it fails: Deleting the signature removes detection of the actual vulnerability for every host, not just this false positive, leaving the network exposed. The safe fix is an exception scoped to the specific source, destination and application. Deleting signatures suits retiring a genuinely obsolete or superseded threat ID, not resolving a false positive.

Question 9easymultiple choice

An administrator needs to temporarily disable the Cortex XDR agent on an endpoint for troubleshooting purposes. What mechanism is used to authorize this action locally using the command line?

Trap 1: A local administrator password configured during OS installation.

Cortex XDR requires a per-endpoint uninstall or disable password generated by the management console, not the OS account password; the local admin credential grants no authority over the agent's protection service. It tempts because local admin rights normally control installed software, and would suffice for stopping ordinary Windows services.

Trap 2: A registry override key set by group policy.

Cortex XDR agent local disabling is authorised by a password hash stored on the endpoint, not a group policy registry override. Registry overrides are tempting because group policy does configure agent settings centrally, and they suit fleet-wide configuration management, but temporary local troubleshooting needs the uninstall or disable password entered via the command line.

Trap 3: A network firewall bypass token.

No such token exists; the agent's local disable is authorised by a console-generated password tied to the endpoint, which the firewall cannot supply. A bypass token tempts because firewalls do use tokens to permit traffic past filtering, but that authorises network flows, not endpoint agent state.

A
An Anti-Tamper password generated from the Cortex XDR management console.
The Anti-Tamper password, generated in the Cortex XDR management console, authorises local command-line disabling of the agent. It satisfies the stem's requirement for local authorisation during troubleshooting, because the endpoint validates this password against its stored hash, permitting the temporary stop without a management-console connection.
B
A local administrator password configured during OS installation.
Why it fails: Cortex XDR requires a per-endpoint uninstall or disable password generated by the management console, not the OS account password; the local admin credential grants no authority over the agent's protection service. It tempts because local admin rights normally control installed software, and would suffice for stopping ordinary Windows services.
C
A registry override key set by group policy.
Why it fails: Cortex XDR agent local disabling is authorised by a password hash stored on the endpoint, not a group policy registry override. Registry overrides are tempting because group policy does configure agent settings centrally, and they suit fleet-wide configuration management, but temporary local troubleshooting needs the uninstall or disable password entered via the command line.
D
A network firewall bypass token.
Why it fails: No such token exists; the agent's local disable is authorised by a console-generated password tied to the endpoint, which the firewall cannot supply. A bypass token tempts because firewalls do use tokens to permit traffic past filtering, but that authorises network flows, not endpoint agent state.