Palo Alto Scenario-Based Questions — 8 Production Fires, Solved Step by Step

① Read the fire like a doctor — the 5-step ladder

Think of a good doctor at an OPD. A patient walks in with fever; the doctor doesn't guess a medicine. She orders tests in order — temperature, blood test, X-ray — and lets evidence pick the diagnosis. Palo Alto troubleshooting is the same OPD discipline. The user complaint is the symptom; the tests are the traffic log, the session table, the policy tester and the global counters. Engineers who fail interviews are the ones who guess the medicine.

Every scenario in this lesson is solved by the same 5-step ladder. Learn it once, reuse it forever:

1. Traffic log first — Monitor → Logs → Traffic, filter on the source. Read three columns: action, application, session end reason.
2. Session table second — show session all filter source x.x.x.x, then show session id N. Byte counts don't lie.
3. Policy tester third — test security-policy-match proves which rule WOULD match, without sending a packet.
4. Global counters fourth — show counter global … delta yes catches drops that never reach any log.
5. Fix, then verify from the log — never from the config screen.

Step 3 is the one interviewers love, because it has a syntax trap. protocol takes the IP protocol number — TCP is 6, UDP is 17 — not the word "tcp":

> test security-policy-match from trust to untrust source 10.40.14.197
  destination 203.0.113.50 destination-port 443 protocol 6

"Allow-Web-Out; index: 4" {
    from trust;
    source 10.40.14.0/24;
    to untrust;
    destination any;
    application/service [ ssl web-browsing ];
    action allow;
    terminal yes;
}

And when the logs stay suspiciously empty, step 4 catches the silent drops:

> show counter global filter severity drop delta yes

Global counters:
Elapsed time since last sampling: 5.21 seconds
name                value   rate  severity  category  aspect   description
flow_policy_deny     1432    274  drop      flow      session  Session setup: denied by policy

The four log words that tell you everything

The application column speaks a tiny language. Tap each card — these four words answer "is it the firewall or not?" faster than any packet capture:

② Policy says allow, the app still dies

This family of fires has one root: on a Palo Alto, the App-ID engine — not the port — decides what a flow is. Engineers arriving from ASA/FTD-land keep building port rules, and the firewall keeps politely refusing.

That is the trap that catches even 20-year veterans: the telnet test. On an App-ID rule the firewall must let the 3-way handshake plus a few packets through — otherwise App-ID has nothing to read. So telnet connects, logs say insufficient-data, the change ticket gets closed as "port open"… and the real application still dies the next morning.

The third fire in this family is the App-ID shift you watched in Live demo 1. A session starts as ssl or web-browsing, then shifts to the real app (google-base, ms-office365) once more payload arrives — and every shift re-tests policy. If no rule allows the newly-named app, the session that "worked for 5 seconds" dies with session end policy-deny. The user swears it works, then breaks; both are true.

③ The return path is the killer

Order biryani on Swiggy and give the wrong callback number — the delivery boy reaches your gate, but the confirmation call goes nowhere and the order times out. Half of all "firewall is blocking us" tickets are exactly this: the request reaches the server, but the reply has no route back through the firewall. The firewall logged allow, did its job, and still gets blamed.

Two rules of the house before the scenario. First, the NAT golden rule: a NAT rule is written with pre-NAT zones and addresses, but the security rule that permits the flow uses the post-NAT zone with the pre-NAT destination IP. It is the single most-asked Palo Alto interview gotcha in India — usually dressed up as U-turn NAT. Second: byte counts don't lie.

> show session id 240752

Session          240752
        c2s flow:
                source:      172.16.40.21 [trust]
                dst:         10.20.8.40
                proto:       6
        state:   INIT      type:    FLOW
        total byte count(c2s)        :       74
        total byte count(s2c)        :       0      <-- the reply never came home

GlobalProtect — "connected, but nothing works"

Remote-access tickets are the same fires with a tunnel wrapped around them. The key fact almost nobody reads in the docs: GlobalProtect uses exactly two data ports — TCP 443 (portal, gateway, SSL tunnel) and UDP 4501 (IPSec as ESP-in-UDP, no IKE at all). The client always tries IPSec first and silently falls back to SSL.

④ When the platform itself fails — HA, change nights and CVE mornings

The hardest scenario questions aren't about traffic at all. They're about the firewall as a patient: the HA pair that betrays you, the content update that changes everything while "nothing changed", and the morning a 9.3 CVE drops before your patch exists.

Fire 1 — "the primary recovered… but stayed passive"

Fire 2 — "nothing changed, everything broke"

A real P1 from the community: at 2 AM a scheduled content update activated a new App-ID called citrix-director. From that moment, traffic that had always classified as ms-sql matched the new app instead — and every rule that allowed only ms-sql silently dropped the bank's database traffic. Zero config change. The config audit proved nothing was touched — because the thing that changed was the App-ID database, not the config. The vendor shipped a corrected content release the same day; the immediate fix is request content downgrade install previous.

Same family: a commit that fails with 'tiktok' is not a valid reference on a box nobody touched — the config references an App-ID that the installed content version doesn't contain. Content state is config state. Review new App-IDs before each install, and stage content on a small firewall first.

Fire 3 — decryption breaks one app, and only one

After enabling SSL decryption, most traffic is fine but one app dies with Received fatal alert CertificateUnknown from client. The trap: this single log line has at least three distinct causes — an incomplete certificate chain (only an intermediate in the cert store), certificate pinning (the app needs a Decryption Exclusion, matched on SNI or CN), and in 2024 a genuine PAN-OS bug with Chromium's oversized post-quantum ClientHello. TLS 1.3 raises the stakes: certificate info is encrypted in-handshake, so the firewall can no longer auto-add exclusions the way it did on TLS 1.2. Check Monitor → Logs → Decryption with (err_index eq Certificate) before touching any certificate.

Fire 4 — the CVE drops before your patch exists

May 2026, real timeline: CVE-2026-0300 — a buffer overflow in the User-ID Authentication (Captive) Portal. CVSS 9.3, unauthenticated root RCE, exploited in the wild, listed in CISA KEV — and patches rolled out branch-by-branch over two weeks. If your branch's fix isn't out, "wait for the patch" is not an answer. The defensible move is layered mitigation tonight: restrict the portal to trusted zones, disable response pages on untrusted L3 interfaces, enable Threat ID 510019, audit exposure of TCP 6081/6082 — then patch the moment your build ships. Same month, CVE-2026-0257 (GlobalProtect auth-override cookie bypass) was re-scored 4.7 → 7.8 after live exploitation: severity is not static, and "we deprioritized it last week" is how breaches start.

The exam connection — what changed in 2025-26

PCNSE retired on July 31, 2025. The flagship firewall cert is now the NGFW-Engineer (Specialist level): ~75 questions, 90 minutes, pass mark 860/1000, domains weighted 40% networking + 40% device settings + 20% integration & automation. The stems read exactly like this lesson — "an engineer deploys X but Y fails; which configuration should be verified first?" — and India L2 panels drill the same six themes: policy-but-blocked, U-turn NAT, decryption side-effects, HA failover, packet flow, and Panorama push order (pre-rules → local → post-rules). Prep once, pass both.