Refer to the Exhibit Practice Questions

The session was terminated by a firewall policy.

Why it fails: Aged-out means the session exceeded its configured timeout and was removed from the session table, not terminated by a security rule. Policy termination appears as a deny or policy end reason. Aged-out is the expected reason for idle long-lived sessions, such as periodic health checks with no further packets.

The session was forcibly closed by an administrator.

Why it fails: Administrator closure is logged with a distinct reason such as admin-reset, reflecting a manual clear session command. Aged-out arises automatically when the session ages past its timeout. Administrator reset would be the correct reason when troubleshooting sessions deliberately cleared from the firewall.

The session ended due to a TCP FIN/RST from the client.

Why it fails: A TCP FIN or RST from either endpoint is recorded as a tcp-fin or tcp-rst session end reason, because PAN-OS logs the actual teardown packet. Aged-out instead reflects timeout expiry with no teardown observed. FIN/RST is the correct reason when an application closes its connection cleanly.

A threat prevention profile detected and blocked the session

Why it fails: Threat prevention blocks appear as threat log entries with a specific signature or profile action, not as a security policy rule match; 'deny-rule' indicates policy denial. Threat prevention is tempting because it drops malicious sessions, but its verdicts are recorded separately from rule-based denies.

The traffic was blocked because the application is not allowed

Why it fails: The log matched 'deny-rule', a security policy rule, so the drop stems from policy action rather than application identification; App-ID enforcement would appear under an allow rule with an application-based block. Application control is tempting because it filters traffic by App-ID, but that mechanism is not what a deny-rule match indicates.

The destination URL is categorized as prohibited

Why it fails: URL categorisation applies to web filtering profiles, not to a security policy rule named 'deny-rule'; the log shows a rule match, so categorisation is not the cause. URL filtering is tempting because it blocks prohibited destinations on port 443, but it operates through a filtering profile, not a deny rule.

Loss of HA1 heartbeat from the peer

Why it fails: The log shows the failover was triggered by a different event, such as a link or path monitoring failure, not by loss of the HA1 heartbeat. HA1 heartbeat loss is tempting because it is the control-plane link between peers, and its failure would indeed trigger failover in a scenario where the peer becomes unreachable.

A link failure on ethernet1/1

Why it fails: The log indicates the failover was caused by a different condition, such as HA1 heartbeat loss or path monitoring, rather than a link failure on ethernet1/1. Link failure monitoring is tempting because it is a common trigger, and would be correct if the log showed the interface going down.

An administrator manually triggered a failover

Why it fails: A manual failover appears in logs as an administrative action, not as a monitored-path or link failure event. It is tempting because administrators do trigger failovers, but the exhibit's log entries would show a specific monitored condition such as link down or path monitoring failure instead.

TLS 1.0

Why it fails: TLS 1.0 is allowed with 'allow-block' (allowed but block list?)

TLS 1.3

Why it fails: TLS 1.3 is not mentioned in the profile.

TLS 1.2

Why it fails: TLS 1.2 is allowed.

The firewall is overloaded and cannot handle more decryption sessions.

Why it fails: Resource exhaustion causes session drops or decryption failures, and the firewall would log those as errors rather than bypasses. Bypass is a policy outcome: matching traffic is excluded from inspection by design, so overload does not increment the bypassed-session counter.

The decryption certificate is not trusted by clients.

Why it fails: An untrusted decryption certificate causes browser warnings or failed forward-proxy decryption, which appear as decryption errors, not as sessions bypassing the firewall entirely. Bypass counters increment when traffic matches a no-decrypt policy or the firewall cannot process the session.

There is a network connectivity issue between firewall and servers.

Why it fails: Connectivity loss between firewall and servers would produce denied or dropped sessions, and the firewall would still create session entries for the attempted flows. Bypassed sessions are those the firewall deliberately excludes from inspection, so a reachability fault does not explain the counter.

Sessions are logged only if the session duration exceeds a threshold.

Why it fails: No duration threshold exists in PAN-OS logging; log-start and log-end are independent toggles, and neither generates a record based on session length. Duration-based logging is tempting as a way to reduce volume, but the firewall simply honours the two toggles, producing only the end entry when log-end is enabled.

Sessions are logged to Panorama immediately when the session starts.

Why it fails: Log-start 'no' suppresses the session-start entry entirely, so nothing is generated at session initiation regardless of the forwarding profile. Log forwarding is tempting because it does export logs to Panorama, but it only forwards records the firewall actually creates, and no start record exists here.

Sessions are logged to Panorama only when the session ends.

Why it fails: With log-end also set to 'no', the firewall generates no traffic log at session close, so nothing reaches Panorama then. End-of-session logging is tempting because log-end normally produces the summary record, but here both toggles are disabled and only the forwarding profile remains, which forwards nothing.

Add an external storage device to the firewall

Why it fails: Adding external storage does not immediately free up space on the *already full* `/opt/panlogs` partition. The firewall's logging mechanism needs to be configured to utilise new storage, and existing logs are not automatically migrated. This option is tempting because external storage is crucial for long-term log retention and expanding overall log capacity. It would be the correct choice if the goal was to prevent future disk full issues by offloading *new* logs or for archiving, rather than addressing an immediate space shortage on an internal partition.

Delete configuration files from /opt/pancfg

Why it fails: Configuration files in /opt/pancfg are tiny relative to logs and deleting them risks losing committed configuration, while the 92% pressure sits on /opt/panlogs. Clearing /opt/pancfg is the right move only when that partition itself is full and logs are already offloaded.

Delete the /opt/panlogs directory and recreate it

Why it fails: Removing /opt/panlogs destroys the log data the administrator must preserve and can break the logging daemon, so it cannot free space safely. Recreating the directory is only valid after logs are exported and the partition is genuinely corrupt, not merely full.

The firewall will stop passing traffic until the license is renewed.

Why it fails: An expired URL Filtering licence disables only that subscription's inspection; the firewall continues passing traffic under existing security policy rules. It is tempting because licence expiry sounds catastrophic, but halting all traffic would be the behaviour of an expired support entitlement or a failed content update, not URL Filtering alone.

URL Filtering will stop working immediately until a new license is installed.

Why it fails: Expired URL Filtering does not stop working instantly; PAN-OS continues using the existing cached URL database for a grace period before enforcement ceases. It is tempting because licence expiry implies immediate loss of function, but the correct behaviour involves this temporary continuation, not instant failure.

The firewall will automatically fall back to a basic URL category list.

Why it fails: Palo Alto Networks provides no basic fallback category list; once the URL Filtering licence expires, the subscription ceases functioning entirely. It is tempting because other vendors degrade gracefully to cached or reduced databases, but PAN-OS does not implement such a fallback for this subscription.

The traffic is blocked because the source-user is 'unknown'.

Why it fails: A source-user 'unknown' match does not itself block traffic; the firewall treats it as an identity state that can be matched by policy, and blocking depends on the rule action. It is tempting because unknown identity feels like a denial condition, but User-ID unknown is a matchable value, not an implicit deny.

The traffic is allowed without authentication because the source-user is 'unknown'.

Why it fails: A security policy rule matching source-user 'unknown' still requires the user to authenticate before the rule permits traffic; Palo Alto Networks resolves unknown users through User-ID, not by granting access. It is tempting because 'unknown' sounds like no identity match, but that value exists precisely so policies can force authentication rather than bypass it.

The user is redirected to the captive portal.

Why it fails: Captive portal redirect occurs only when a policy rule or authentication profile explicitly enables captive portal for unmatched users; an unknown source-user alone does not trigger redirection. It is tempting because captive portal is the mechanism for identifying unknown users, but it must be configured as an authentication enforcement action, not assumed.

HA2 heartbeat link is down, preventing the passive from detecting the active's failure.

Why it fails: The HA2 link carries synchronisation traffic, not heartbeats; a failed HA2 causes configuration drift between peers rather than preventing the passive from learning the active has gone away. It is tempting because HA2 outages are a common HA fault, but heartbeat and failover detection run over HA1.

The fail-holdup timer is set to 0, causing immediate failover but not triggered.

Why it fails: A zero fail-holdup timer shortens how long the passive waits before promoting itself, so it cannot explain a failover that never occurred. It is tempting because tuning this timer is a legitimate way to speed up HA transitions in an active/passive pair, but it addresses failover timing, not the trigger condition the stem describes.

Path monitoring is disabled so the passive does not monitor connectivity to the upstream router.

Why it fails: Path monitoring runs on the active firewall to watch upstream reachability; disabling it affects the active's own link-failure detection, not the passive's behaviour. It is tempting because path monitoring is genuinely the feature used to fail over on upstream link loss, but the stem's exhibit points to a different cause.

LDAP server profile

Why it fails: An LDAP server profile binds to a directory for credential or group lookup, whereas a SAML authentication profile authenticates via a SAML identity provider, not LDAP. It is tempting because LDAP profiles are commonly paired with authentication profiles for group mapping, and would be correct if the profile authenticated users directly against the directory.

RADIUS server

Why it fails: A RADIUS server provides authentication against a RADIUS database, which the SAML authentication profile does not query; SAML profiles reference an identity provider via a SAML server entry. It is tempting because RADIUS is the standard choice for 802.1X and captive-portal user authentication, and would be correct if the profile were RADIUS-based rather than SAML.

Kerberos realm

Why it fails: A Kerberos realm authenticates users against Active Directory via Kerberos tickets, which a SAML authentication profile does not use; SAML profiles require a SAML identity provider server entry. It is tempting because Kerberos realms are configured for User-ID and web-form authentication against AD, and would be correct for those methods instead.

Rule 2 does not have a service set to application-default, so it cannot match the traffic.

Why it fails: Application-default only auto-selects the standard ports for the identified application; it does not determine whether a rule matches. The deny stems from rule order or the security profile, not the service definition. Application-default is genuinely useful when you want the firewall to infer ports from the App-ID rather than specifying them manually.

The traffic is from trust to trust, matching rule 4, but still denied.

Why it fails: A trust-to-trust rule matching the session does not guarantee permit; the rule's action, application, service or user criteria may still deny it, or a later rule may match first. Trust-to-trust is tempting because intrazone traffic is often implicitly allowed, but that assumption does not override explicit deny actions.

The traffic requires a specific service other than application-default.

Why it fails: Application-default already permits the ports the application declares, so HTTPS to a website would match without a custom service. Specifying a service is correct when traffic uses non-standard ports, but here it would not explain a deny when the default already covers 443.

The HA group-id is not unique in the network

Why it fails: Group-id uniqueness does not affect link monitoring.

HA2 link is down preventing failover

Why it fails: HA2 down does not prevent failover; session sync may be affected.

Path monitoring interval is set too high, causing delayed failover

Why it fails: Path monitoring does not affect link monitoring failover.

The source NAT rule is missing, so the private IP cannot reach the internet.

Why it fails: Source NAT affects address translation, not policy evaluation; a policy-deny drop means no rule matched the session as evaluated. It is tempting because missing NAT commonly breaks internet-bound traffic, and would be correct if the session showed a routing or translation failure rather than an explicit policy denial.

The SSL application is not correctly identified because the traffic is encrypted.

Why it fails: Encrypted traffic still matches App-ID on the SSL application, so identification is not the blocker; policy-deny indicates no rule permitted the session. It is tempting because App-ID depends on decryption for some applications, and would be correct if the log showed an unknown-tcp or insufficient-data application rather than a policy denial.

The firewall is configured to block SSL sessions that use weak ciphers.

Why it fails: Weak-cipher decryption failures appear as decryption or threat log entries, not policy-deny; the firewall denies before cipher inspection. It is tempting because SSL decryption blocks do stop TLS sessions, and would be correct if the drop reason referenced decryption rather than security policy evaluation.

rule4

Why it fails: Rule4 is a deny-all, but rule2 matches first.

rule3

Why it fails: Rule3 only applies if the user is specifically 'user1'.

rule1

Why it fails: Rule1 only allows web-browsing (HTTP), not SSL.