Scenario practice questions

debug system dump

Why it fails: debug system dump writes a core dump of a process for crash analysis, not the consolidated configuration, logs and diagnostics archive TAC requests. It is the correct tool when a process has faulted and engineering needs memory-state evidence, not for routine performance diagnostics.

show system resources

Why it fails: show system resources reports live CPU, memory and session counters, giving a snapshot of current load rather than bundling configuration, logs and diagnostics into an archive for TAC. It is the right command for a quick performance check during triage, not for producing the comprehensive support file.

show log system

Why it fails: show log system displays system log entries only, omitting configuration, statistics and core files that TAC requires. It is used to inspect recent event messages when troubleshooting a specific fault, not to generate the consolidated support bundle that captures the full device state.

Reboot both firewalls simultaneously to reset the HA state.

Why it fails: Rebooting is a temporary workaround but does not prevent recurrence; the configuration issue remains.

Disable link speed and duplex settings on the HA interfaces to force a failover.

Why it fails: Changing link settings can cause interface instability and is not a recommended method to resolve HA state issues.

Set the HA mode to 'active/active' to allow both firewalls to process traffic.

Why it fails: Active/active mode is not appropriate for this situation and would not resolve the split active issue; it requires different configuration.

The firewall's DNS settings

Why it fails: DNS settings on the firewall affect name resolution, not routing or forwarding of traffic to an IP-addressed internal server that other networks already reach. It is tempting because DNS failures do cause connection errors, and checking DNS would be right if users reached the server by hostname and resolution was failing.

The server's SSL certificate

Why it fails: An SSL certificate governs TLS negotiation for HTTPS sessions; it cannot block traffic when the security policy already permits it and other networks reach the server. It is tempting because certificate errors do break HTTPS access, and checking the certificate would be right if browsers showed trust warnings after connectivity succeeded.

The interface management profile

Why it fails: An interface management profile controls which administrative services, such as ping, SSH and HTTPS, respond on that interface; it does not govern dataplane forwarding of user traffic. It is tempting because it affects reachability testing, and it would be correct if pings or management access to the firewall interface itself failed.

show session info

Why it fails: This command shows active sessions but does not directly indicate performance bottlenecks.

show log traffic

Why it fails: This command shows traffic logs, which are for historical analysis, not real-time bottleneck identification.

Both firewalls have the same priority; the tie is broken by serial number, but due to simultaneous reboot, both came up as active. The solution is to reboot one firewall.

Why it fails: Equal priority is resolved by serial number, and simultaneous reboot does not make both peers active; rebooting one firewall does not correct the underlying election fault. Priority tie-breaking is relevant when configuring deterministic failover, but the actual cause is the HA timers and preemption behaviour during concurrent startup.

The HA configuration is set to active/active mode instead of active/passive.

Why it fails: Active/active mode would show both peers active, but the pair is configured active/passive, so this misreads the configuration rather than the reboot sequence. Active/active suits environments needing both devices forwarding simultaneously; here the fault lies in HA election after simultaneous startup, not in the mode setting.

The heartbeat interfaces are not configured on each firewall.

Why it fails: Missing heartbeat interfaces would prevent HA peering entirely, leaving peers in a non-functional or initial state rather than both reporting active. Heartbeat configuration matters when establishing HA links, but here the peers clearly communicate, so the split-brain stems from election timing after simultaneous reboot, not absent heartbeats.

Decryption Broker

Why it fails: Decryption Broker is not a standard Palo Alto Networks feature.

SSL Termination

Why it fails: SSL Termination is not a separate decryption scenario; it is part of inbound inspection.

SSH Proxy

Why it fails: SSH Proxy is not a decryption scenario; it handles non-SSL traffic.

The application is not recognized by the firewall and is treated as unknown

Why it fails: Unknown applications are handled by the rule's unknown-tcp, unknown-udp and unknown-p2p settings, producing an 'unknown application' or 'insufficient data' verdict, not application mismatch. Mismatch means the firewall identified a different application than the rule allows. Treating traffic as unknown would be correct when App-ID cannot identify the session.

The security rule is not configured to allow any application

Why it fails: An empty application field in the rule means any application is permitted, so it cannot produce an application-mismatch denial. Application mismatch arises when the identified application differs from the one the rule specifies. Leaving the application unset would be correct when the rule should permit all applications regardless of identification.

The firewall's SSL decryption is misconfigured

Why it fails: SSL decryption failures produce their own log reasons, such as decryption errors or certificate issues; 'application mismatch' means App-ID identified traffic differing from the policy's expected application. Decryption is tempting because encrypted sessions can hide the true application, but that yields decryption errors, not this specific denial reason.

User-ID

Why it fails: User-ID is the technology that maps IP addresses to users and groups, enabling policies based on user identity. It does not identify applications. In this scenario, the problem is application identification, not user mapping. User-ID would be relevant if policies were based on users and the mapping was failing, but the stem specifically mentions that no application is identified. Therefore, User-ID is not the component responsible for application identification.

Content-ID

Why it fails: Content-ID is responsible for inspecting the content of allowed traffic for threats, URLs, and files. It operates after App-ID has identified the application and the security policy allows the session. In this scenario, the issue is that no application is identified, so Content-ID would not yet be engaged. Content-ID includes threat prevention, URL filtering, and file blocking. While Content-ID is critical for security, it is not the component that identifies the application itself.

SSL Decryption

Why it fails: SSL Decryption is a feature that decrypts SSL/TLS traffic to allow App-ID and Content-ID to inspect encrypted sessions. While it can enable application identification for encrypted traffic, it is not the component that performs the identification itself. In this scenario, the traffic might be unencrypted or the issue could be unrelated to encryption. The core component that identifies applications is App-ID, not SSL Decryption. SSL Decryption is an enabler, not the identifier.

The rule should be at the top of the rulebase

Why it fails: Rule position affects evaluation order, not certificate trust; the firewall still presents its forward-trust certificate, so users see warnings unless that CA certificate is installed on clients. It is tempting because ordering matters for shadowed rules, and placing a decryption rule above a no-decrypt rule would be correct when a broader rule pre-empts it.

The destination address should be specific

Why it fails: Destination scope controls which servers are decrypted, not whether clients trust the firewall's certificate; certificate warnings arise from the forward-trust CA not being installed on the endpoints. It is tempting because narrowing destinations is good practice, and it would be correct when a rule must exclude specific sites from decryption.

The application should be web-browsing

Why it fails: Application identification does not determine whether the firewall presents a trusted certificate; web-browsing is already the correct match for HTTPS traffic. It is tempting because application filters commonly cause decryption rules to be skipped, and specifying web-browsing would be right when a rule must match only browser traffic rather than all applications.

Session owner is set to 'primary' on both firewalls.

Why it fails: Session owner is for flow control, not HA state.

Preemptive mode is enabled on both firewalls.

Why it fails: Preemptive mode only affects failback behavior, not the initial state.

Both firewalls have different PAN-OS versions.

Why it fails: Version mismatch would prevent configuration sync, but both would still show as standbys or one active.

Run 'show running resource-monitor' to check if the firewall is under resource stress.

Why it fails: Resource monitoring shows CPU, memory, and session utilization but does not explain why individual sessions are discarded. Discards are typically due to policy or application identification issues, not resource exhaustion. This command is more appropriate for performance troubleshooting.

Run 'show counter global filter severity drop' to identify the global counters that are incrementing.

Why it fails: While global counters can indicate drops, they do not provide session-specific discard reasons. The engineer needs per-session details, which are available in 'show session id'. Global counters are useful for aggregate drop analysis but not for pinpointing why a particular session was discarded.

Run 'debug dataplane packet-diag set filter match destination 10.1.1.50' to capture packets and analyze them.

Why it fails: Packet capture can show whether packets are received and forwarded, but it does not directly reveal the firewall's internal reason for discarding a session. The discard reason is logged and viewable via session details. Packet analysis is more time-consuming and less direct for this purpose.

Destination NAT (DNAT)

Why it fails: Destination NAT translates the destination IP address of incoming packets, typically used to publish internal servers to the internet. The scenario requires translating private source addresses to a public address for outbound traffic, which is source NAT. DNAT would not achieve the required address translation for outbound connections and would instead alter the destination, breaking connectivity.

U-Turn NAT

Why it fails: U-Turn NAT is used when internal users need to access an internal server via its public IP address, causing traffic to hairpin on the firewall. This scenario does not involve internal users accessing internal resources via public addresses; it involves outbound internet access. U-Turn NAT would not provide the required translation for outbound traffic and would complicate the configuration unnecessarily.

No NAT; use a security policy to allow outbound traffic

Why it fails: Without NAT, private IP addresses would be sent to the internet, where they are not routable. A security policy alone cannot translate addresses; it only permits or denies traffic. The requirement explicitly states that private addresses must be translated to a public address, so NAT is mandatory. Omitting NAT would result in dropped packets at the ISP or upstream router.

The firewall's App-ID database is outdated and does not have the signature for the application.

Why it fails: An outdated App-ID database could cause misidentification, but the application is known and uses HTTP, so it is likely already in the database. The more common cause is that the application's traffic pattern resembles web-browsing. Updating the database may not resolve the issue if the signature is already present. This option is less likely than the correct answer.

The application's traffic is being tunneled over HTTP and the firewall cannot distinguish it from web-browsing.

Why it fails: If the application is tunneled over HTTP, the firewall might initially see it as web-browsing, but App-ID should eventually detect the tunneled application if signatures exist. However, the scenario states it's a known application using HTTP, not necessarily tunneled. This option is plausible but not the most direct cause; misidentification often occurs when the application uses standard HTTP without unique signatures.

The firewall is configured with an Application Override for HTTP that forces all HTTP traffic to be identified as web-browsing.

Why it fails: An Application Override for HTTP would force all HTTP traffic to be identified as web-browsing, but the scenario does not mention such a configuration. This option is incorrect because it assumes a specific misconfiguration that is not stated. While possible, it is less likely than the natural behavior of App-ID when no unique signature exists.

The traffic will be allowed, but the firewall will still perform application identification and threat inspection if a profile is later added to the rule.

Why it fails: While the firewall always performs application identification regardless of profiles, threat inspection (such as antivirus or anti-spyware) only occurs if security profiles are attached to the rule. Without profiles, no threat inspection is performed, so this statement is misleading for the described scenario.

The traffic will be blocked by default because security profiles are mandatory for all allow rules.

Why it fails: Security profiles are not mandatory for allow rules. A security policy rule can be configured to allow traffic without any security profiles, and the traffic will be permitted. The firewall does not block traffic solely because profiles are missing; the action is determined by the rule's action setting.

The traffic will be allowed, but the firewall will automatically apply the default security profiles from the 'default' security profile group.

Why it fails: There is no automatic application of a default security profile group. Security profiles must be explicitly attached to a security policy rule. Without explicit attachment, no threat inspection occurs. The firewall does not have a built-in default profile group that is automatically applied.

SSL Decryption

Why it fails: SSL Decryption decrypts SSL/TLS traffic to allow inspection by App-ID and Content-ID. It does not detect threats itself. Without SSL decryption, encrypted threats may go undetected, but SSL decryption is an enabler, not the threat detection engine. In this scenario, the administrator needs to enable threat prevention, which is provided by Content-ID. SSL Decryption would be relevant if the traffic were encrypted, but it is not the feature that detects threats.

App-ID

Why it fails: App-ID identifies applications but does not detect threats. It is used to enforce security policies based on applications, users, and content. While App-ID is a prerequisite for threat inspection, it does not itself detect viruses or spyware. In this scenario, the administrator needs threat prevention, which is provided by Content-ID. App-ID would be used to identify the application, but the threat detection is handled by a different component.

User-ID

Why it fails: User-ID maps IP addresses to users and groups, enabling policies based on user identity. It does not detect threats. While User-ID can be used in conjunction with threat prevention to create user-specific policies, it is not the feature that detects viruses or spyware. In this scenario, the administrator needs to enable threat prevention, which is a function of Content-ID, not User-ID.