Troubleshooting Scenario Questions

Policies > Management

Why it fails: Policies > Management holds administrative access and authentication settings, not signature update scheduling. It is tempting because management-plane policy governs device administration, and would be correct when configuring administrator roles, authentication profiles or management interface access restrictions.

Device > Setup > Management > Software

Why it fails: Signature installation scheduling lives under Device > Setup > Management > Content-ID, not Software, which holds PAN-OS image versions. The Software pane is tempting because it also manages update timing, but it governs firewall firmware upgrades rather than Antivirus and WildFire content installation.

Objects > Certificates

Why it fails: Certificates stores trust anchors and device certificates, so it holds no signature installation schedule. It is tempting because certificate revocation and CRL updates are also timed tasks, but content update installation is configured under Device > Setup > Management > Content-ID instead.

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.

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.

Configure a correlation rule in the Cortex XDR management console that uses the MITRE ATT&CK technique T1059.001 and applies a global allowlist for the service account.

Why it fails: Correlation rules in Cortex XDR are typically used to combine multiple events into a single alert, but they do not offer the same granular command-line pattern matching and per-rule exclusions as BIOC rules. A global allowlist would affect all rules, potentially suppressing other malicious activity from that account, and the technique-based approach alone lacks the specific -EncodedCommand condition.

Deploy a custom Cortex XDR agent script that monitors PowerShell execution and sends an alert to the management console, excluding the service account via a local configuration file.

Why it fails: Cortex XDR does not support deploying arbitrary custom agent scripts for detection logic; the agent is controlled by the management console and built-in capabilities. Writing a local script would be unsupported, difficult to manage at scale, and would not integrate with Cortex XDR's alerting and response workflows. The proper method is to use the built-in rule engine.

Use the Cortex XDR Query Builder to schedule an XQL query that searches for the PowerShell command line and filters out the service account, then set it to generate an alert.

Why it fails: While XQL queries can search for specific command-line patterns and filter out accounts, they are designed for hunting and reporting, not for real-time detection with automatic alert generation. Scheduled queries can create alerts, but they lack the native behavioral rule logic and immediate response capabilities of BIOC rules, making them less suitable for continuous detection.

Automated quarantine of infected container workloads in public cloud Kubernetes clusters.

Why it fails: Container quarantine is a runtime security action performed by cloud workload protection platforms, not remote-user experience monitoring. It is tempting because Prisma Cloud also offers container defences, but ADEM measures endpoint and hop-level performance. ADEM provides metrics such as Wi-Fi signal quality and SaaS application response times.

Direct decryption and viewing of private banking user passwords traversing HTTPS sessions.

Why it fails: ADEM correlates endpoint, network and application telemetry to locate performance degradation; it never decrypts user credentials. HTTPS inspection for password visibility is a data-loss-prevention or lawful-intercept function, not a DEM troubleshooting metric, and would breach privacy requirements.

Automated firmware flashing for branch office switch hardware.

Why it fails: ADEM reports synthetic and real-user metrics such as hop-by-hop path visibility, Wi-Fi signal quality and application response times; it does not manage switch firmware. Firmware flashing belongs to network device management tooling, so it cannot diagnose a remote user's application performance.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Change the alert severity threshold to high.

Why it fails: Changing the alert severity threshold affects which alerts are generated or prioritized, but it does not control whether they are automatically closed. The issue is not about alert generation but about the response workflow that led to auto-closure. Adjusting severity thresholds would not enforce human review before closure.

Disable automatic updates for the Cortex XDR agent.

Why it fails: Disabling automatic updates for the Cortex XDR agent affects the agent's software version and security content updates, not the incident response workflow. It has no impact on whether alerts are auto-closed and could introduce security risks by preventing the agent from receiving critical updates. This action is unrelated to the requirement.

Adjust the alert exclusion rules to prevent auto-closure.

Why it fails: Alert exclusion rules are used to suppress alerts based on specific criteria, not to control auto-closure behavior. Modifying exclusions would prevent certain alerts from being generated at all, which is not the goal. The team wants alerts to be generated but not automatically resolved, so exclusion rules are the wrong mechanism.

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.

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.

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.

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.

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.

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.

Add the browser executable path to the OS exclusions list in Cortex XDR.

Why it fails: OS exclusions suppress Cortex XDR agent activity for the listed executable entirely, including malware and exploit detection, rather than narrowing the offending exploit protection rule. It is tempting because exclusions are the standard remedy for repeated false positives, and would be correct when a trusted application must be exempted from agent scanning.

Disable memory protection features globally in the agent settings profile.

Why it fails: Disabling memory protection globally removes exploit mitigation across every endpoint, exceeding the troubleshooting scope and leaving the estate exposed. It is tempting as a quick way to confirm whether memory-based exploit rules cause the crash, and would be the correct choice only when a known false positive affects all endpoints and no granular exclusion exists.

Enable Agent Self-Protection to prevent local interference.

Why it fails: Agent Self-Protection guards the Cortex XDR agent's own processes and files from tampering; it does not alter which exploit protection modules inspect the crashing plugin. It is tempting because it hardens the agent against local interference, which would be the right choice when malware or users attempt to stop or modify the agent itself.

The agent stops enforcing all security policies and only resumes protection after reconnecting to the console.

Why it fails: The agent is designed to remain autonomous and continues enforcing its last-applied policies even without console connectivity. Halting all enforcement would create a dangerous blind spot precisely when endpoints may be targeted. The agent keeps local protection running, so this statement misrepresents how the endpoint behaves during a connectivity outage.

The agent uninstalls itself automatically after a fixed offline timeout to prevent stale configurations.

Why it fails: Agents do not self-uninstall when they lose connectivity. Automatic removal would leave endpoints completely unprotected and would be trivially abusable by an attacker who simply blocks network access. The agent persists and continues running, so this statement describes behavior that does not occur in Cortex XDR deployments.

The agent forwards all events to a local syslog server because the console is unreachable.

Why it fails: The agent buffers events locally while disconnected and forwards them to the Cortex XDR service once connectivity returns; it does not redirect telemetry to a syslog server. Syslog forwarding is not an automatic fallback mechanism. This option mischaracterizes both where events are stored and how they are eventually delivered to the management console.