Refer to the Exhibit Practice Questions

DNS proxy is running

Why it fails: DNS proxy resolves names for clients and has no bearing on the firewall's own system clock, so it cannot explain the incorrect time. It is tempting because DNS proxy appears in the same services list as NTP, but only NTP servers synchronise the device clock.

Management service is down

Why it fails: Management service downtime blocks administrator logins and configuration changes, but it does not stop the dataplane from forwarding or the firewall from syncing time with its configured NTP servers. It is tempting because management-plane outages do cause stale dashboards, yet NTP runs independently of that service.

SNMP is running

Why it fails: SNMP provides monitoring and trap delivery; it does not set or synchronise the firewall's system time. It is tempting because SNMP is commonly enabled alongside NTP in the management services list, yet only an NTP server address corrects clock drift.

Syslog is running

Why it fails: Syslog only exports log messages to a remote collector; it neither supplies nor adjusts the firewall's clock. It is tempting because syslog timestamps look time-related, but the actual clock source is NTP, so a running syslog daemon cannot explain drift.

Allow the traffic because rule 1 matches and allows all web traffic.

Why it fails: Rule 1 matches the source zone and address but its application is web-browsing, not social-networking; PAN-OS matches on application, so rule 1 does not apply. An allow-web-browsing rule would permit traffic when the session's App-ID resolves to web-browsing.

Allow the traffic because rule 3 allows all traffic.

Why it fails: Rule 3's allow-all sits below the social-networking deny, and PAN-OS evaluates security rules top-down, stopping at the first match, so the deny takes effect. An allow-all rule would permit the traffic only if it preceded the deny.

Deny the traffic because no rule allows social-networking.

Why it fails: The exhibit's rules are evaluated in order, and a later rule explicitly permits social-networking from 192.168.1.10; the firewall therefore allows the session rather than falling through to an implicit deny. Implicit deny applies only when no rule matches, which is not the case here.

It is a QoS rule that prioritizes the traffic.

Why it fails: QoS rules classify and shape traffic via QoS profiles; they do not permit or deny sessions. Allow_Outbound is a security policy rule governing whether outbound sessions are allowed. QoS would be correct where bandwidth guarantees or traffic prioritisation are required.

It is a NAT rule that translates the source IP.

Why it fails: NAT rules perform source or destination address translation and are configured separately from security policy. Allow_Outbound permits or blocks sessions rather than translating addresses. A NAT rule would be the answer where source IP hiding or address translation is the stated requirement.

It is a decryption rule that decrypts the traffic.

Why it fails: Allow_Outbound sits in the security policy rulebase, so it governs whether sessions are permitted or denied, not whether TLS is decrypted. Decryption rules are configured separately under Policies > Decryption, where a rule specifies the certificate and decryption profile. That separate rulebase is where you would look to inspect encrypted traffic.

The firewall has been recently rebooted

Why it fails: Uptime is 2 hours, but that does not explain drops.

System CPU is too high

Why it fails: High CPU would appear as elevated CPU utilisation in the exhibit; if the displayed CPU remains low while sessions drop, CPU is not the constraint. CPU is the correct diagnosis when the management plane shows sustained near-maximum processor load.

The session limit is being reached

Why it fails: The exhibit's session counts and resource graphs must be read directly; a session limit produces a specific counter at its maximum, not the CPU or memory pattern shown. Session limits are the cause when the session table is exhausted, which the exhibit does not indicate.

Data Filtering

Why it fails: Data Filtering inspects file content and patterns to block sensitive data transfers; it does not resolve source IP addresses to directory usernames. User-ID performs that mapping, which populates the log's 'user' field. Data Filtering would be correct when the requirement is preventing leakage of credit card or personal data.

Captive Portal

Why it fails: Captive Portal authenticates users through a web login page before granting network access, so it populates user information only for guest or portal-authenticated sessions. User-ID, which maps IP addresses to directory users, is the feature that adds the 'user' field to traffic logs.

GlobalProtect

Why it fails: GlobalProtect provides VPN remote access and endpoint posture checks, not user-to-IP mapping for logs. The 'user' field comes from User-ID, which maps directory users to source IPs. GlobalProtect would be correct when the requirement is secure remote access with host information profiles.

The security rule is misconfigured because it lacks an application field.

Why it fails: A rule lacking an application field matches on other criteria and would not itself produce an incomplete application value; incomplete is a session state, not a rule error. It tempts because misconfigured rules are a common cause of blocked traffic, but here the block is a symptom, not the cause.

The firewall does not have an App-ID signature for the website.

Why it fails: App-ID identifies applications from traffic patterns regardless of port, so a missing signature yields unknown-tcp, not incomplete; incomplete means the firewall saw too few packets to classify. It tempts because signature gaps do cause unknown application results, but that is a different log value.

SSL decryption is not enabled, so App-ID cannot identify HTTPS traffic.

Why it fails: Without SSL decryption, App-ID still identifies HTTPS applications via server certificate and SNI, so traffic is not left incomplete for that reason alone. It tempts because decryption does improve App-ID coverage, and it is the right answer when encrypted sessions show unknown-tcp.

The application web-browsing should not be in the rule

Why it fails: The rule matches on service ports, not application identification, so removing web-browsing changes nothing about HTTPS being permitted. Application filters are tempting because App-ID gives granular control. They are the right tool when policy must distinguish applications sharing the same port, such as blocking one SaaS app over 443.

The rule action should be deny

Why it fails: Changing the action to deny would block both HTTP and HTTPS, contradicting the intent to permit HTTP while blocking HTTPS. Deny actions are tempting because they immediately stop traffic. A deny rule is correct when the requirement is to drop all matching traffic outright, not to differentiate by protocol within a service group.

The source IP should be an address group

Why it fails: The source is a single host, so an address group adds no filtering benefit and cannot separate HTTP from HTTPS. Address groups are tempting for scaling rules across many hosts. They are correct when multiple source addresses share identical policy, which is not the issue here.

The SSL session cache size is too small.

Why it fails: Cache size affects performance and session reuse, not decryption success; failures stem from certificate or trust issues, such as untrusted issuers or unsupported ciphers. It is tempting because cache exhaustion produces errors under load, and enlarging it would be correct when sessions are dropped during high-throughput decryption.

SSL Forward Proxy is not enabled.

Why it fails: Without SSL Forward Proxy enabled, no decryption occurs at all, so failures would not be logged; the exhibit shows attempts failing, meaning the proxy is active. It is tempting because disabling the feature removes errors, and it would be correct where decryption is unwanted entirely.

Non-HTTP traffic is being decrypted.

Why it fails: Decryption policies match only supported protocols such as SSL and SSH; non-HTTP traffic is not decrypted by the forward proxy, so it cannot generate these failures. It is tempting because protocol mismatches do cause errors, and it would be correct if the exhibit showed unsupported traffic hitting a decryption rule.

The firewall does not have a certificate installed for SSH decryption.

Why it fails: SSH decryption does not use certificates; the firewall proxies the session and performs its own key exchange, so a missing certificate cannot cause this error. It is tempting because certificate installation is genuinely required for SSL forward proxy decryption, making it the correct fix when TLS, not SSH, decryption fails.

The SSH session is using a cipher that is not supported by the firewall's decryption engine.

Why it fails: SSH decryption on Palo Alto firewalls relies on the firewall's own key exchange rather than certificates, and unsupported ciphers are a genuine limitation, but the logged error stems from the decryption profile's configuration, not cipher negotiation alone. It is tempting because cipher mismatch is a real cause of SSH decryption failures in other scenarios.

The decryption policy is misconfigured because the service is set to 'any' instead of 'ssh'.

Why it fails: Setting the service to 'any' still matches SSH traffic, so it does not by itself break decryption; the error arises from the decryption profile's restrictions on the SSH session. It is tempting because overly broad service definitions are a common policy mistake, and narrowing to 'ssh' is correct practise for precision.

ethernet1/1

Why it fails: ethernet1/1 is an interface name, not an IP address, so it cannot be a default gateway. The exhibit's default route lists a next-hop IP on that interface. Naming the egress interface would be correct when asked which interface forwards traffic, not which gateway address.

10.0.0.0

Why it fails: 10.0.0.0 is a network address, not a usable gateway; a firewall's default route points to a host address on a connected subnet. It is tempting because it appears in the routing table as the destination prefix, but the next-hop field holds the actual gateway.

0.0.0.0

Why it fails: A default gateway of 0.0.0.0 is the wildcard route, not an assigned address; the exhibit shows the firewall's actual next-hop IP on its management or data interface. It is tempting because 0.0.0.0/0 denotes the default route in a routing table, but that is the destination prefix, not the gateway itself.

The 'strict' profile is misconfigured

Why it fails: The strict profile governs certificate validation and unsupported cipher handling, not whether the rule decrypts at all. It is tempting because profile errors surface as decryption failures, but a misconfigured profile affects how traffic is decrypted, not whether the policy rule matches and acts on it.

The Decrypt-Web rule has a profile that blocks decryption

Why it fails: A decryption profile cannot block decryption; profiles control certificate checks, unsupported protocols and cipher handling after decryption is selected. The rule's action field determines decrypt versus no-decrypt, so a no-decrypt action or a preceding match is the likely cause. Profiles are the right place to enforce session controls on traffic you have already chosen to decrypt.

The source is set to 'any' in the Decrypt-Web rule

Why it fails: A source of any matches all traffic, which broadens rather than narrows the rule, so it cannot prevent decryption. It is tempting because overly broad match criteria look suspicious, but decryption failure stems from the rule's action or the preceding rule, not from source scope.

The firewall allows ping traffic through all interfaces.

Why it fails: A management profile applies to the interface's own administrative services, so it cannot permit ping across every interface. It is tempting because ping is listed among management-profile protocols, but that setting governs responses to the firewall itself, not transit ICMP through the device.

The management profile allows SSH access.

Why it fails: The management profile governs administrative access to the firewall itself, not transit traffic. It is tempting because management profiles do control protocols like SSH and HTTPS, but the exhibit concerns a security policy's application or service settings, which determine forwarded traffic.

The firewall cannot ping others.

Why it fails: A management profile's ping setting affects only whether the firewall responds to pings on its own interfaces, not whether it can initiate pings elsewhere. It is tempting because ping appears in management profiles, but outbound ping depends on the firewall's own outbound policy and source interface.

The server's certificate is expired

Why it fails: An expired server certificate causes a certificate-validation failure, but the firewall's decryption failure typically indicates it could not complete the handshake or decrypt the session, not that validation rejected expiry. It is tempting because expiry is a frequent TLS fault, but it would be correct when the log shows a certificate-expired validation error.

The decryption profile rejects self-signed certificates

Why it fails: A decryption profile's block settings for untrusted issuers produce a decryption failure only if that profile is attached and the certificate chain is untrusted; the log alone does not establish this. It is tempting because self-signed certificates are commonly blocked, but it would be correct when the profile explicitly rejects untrusted issuers.

The client's system time is behind

Why it fails: Client clock skew breaks certificate validity windows, producing validation errors rather than a firewall decryption failure. It is tempting because time drift is a known TLS cause, but it would be correct when the client reports certificate-not-yet-valid or expired errors, not when the firewall cannot decrypt the session.

Reset the firewall to factory defaults to ensure a clean upgrade

Why it fails: Factory resetting erases configuration, logs and licences without addressing the upgrade path; PAN-OS requires installing the base image and each intermediate maintenance release before the target version. A reset is used to recover a corrupted configuration or redeploy a device, not to prepare an upgrade.

Reboot the firewall to apply pending updates

Why it fails: Rebooting applies only already-installed packages; no upgrade package has been downloaded or staged, so a reboot changes nothing. It is tempting because reboots are required after certain PAN-OS installations, but that step follows installation, not precedes it.

Directly install the PAN-OS 9.1.7 package

Why it fails: The package must first be downloaded to the firewall.

Reset the connection.

Why it fails: A reset action terminates the session by sending TCP RST packets, but the exhibit's log shows the firewall blocked the URL through URL filtering, not a reset. Reset would be correct where a security profile configured to reset-client-and-server applies; here the URL category block is the actual action.

Blocked the URL.

Why it fails: No URL filtering block shown.

Denied the traffic.

Why it fails: A deny action appears in the log, but the exhibit shows the firewall reset the session rather than silently dropping it, so 'denied' misstates the mechanism. Deny is correct when the firewall drops packets without a reset; here the reset action distinguishes it from a plain deny.