Scenario practice questions

The application 'webapp' is not allowed due to an application override.

Why it fails: An application override forces traffic to a specified App-ID rather than blocking it, so it would not deny 'webapp' when the rule allows that application. It is tempting because overrides change App-ID classification, and it would be correct if traffic were being matched to the wrong application.

SSL decryption is not enabled.

Why it fails: SSL decryption affects visibility into encrypted sessions, but the policy already permits 'webapp' by App-ID, so uploads are not blocked for that reason. It is tempting because decryption is needed for Content-ID inspection, and it would be correct if the application were unidentified due to encrypted traffic.

App-ID is not identifying the application correctly.

Why it fails: App-ID correctly identifying 'webapp' would permit the traffic, so misidentification is not the likely cause when the rule already names that custom application. It is tempting because App-ID underpins policy matching, and it would be correct if the application were being classified as unknown-tcp or a different App-ID.

The antivirus signatures are outdated.

Why it fails: Outdated signatures leave known threats undetected, but the stem’s profiles already cover those vectors; the actual gap is traffic bypassing inspection entirely, such as applications excluded from decryption or profiles applied only to allow rules. Signature updates are the correct fix when new malware variants evade otherwise correctly scoped, decrypted traffic.

The security profiles are not attached to any security rule.

Why it fails: Profiles only inspect traffic when referenced by a security rule; unattached profiles are never evaluated, so malware passes uninspected. It is tempting because the profiles exist and appear configured, but Palo Alto Networks applies profiles per-rule, so an unbound profile has no effect on traffic.

The profile groups are applied in the wrong order.

Why it fails: Profile groups are containers for security profiles, not ordered stages, so no sequence exists to misconfigure. The tempting association is policy rule ordering, where Palo Alto evaluates rules top-down and a permissive rule above a block rule lets traffic bypass inspection — but that concerns rules, not the profile group itself.

The security policy is set to deny due to an implicit deny rule.

Why it fails: Flood protection profiles drop traffic only when configured thresholds are exceeded, and the stem gives no evidence of a flood; the implicit deny rule sits at the end of the rulebase and is not triggered while a matching allow rule exists. Flood protection would be the cause if SYN or ICMP rates breached the profile's limits.

The security policy has a logging profile attached that is blocking traffic.

Why it fails: Logging profiles only record session details; they never block traffic. They are tempting because profiles are configured alongside security policies, but the stem states Flood Protection is enabled on the internal zone, so threshold-based flood drops, not logging, explain the denial.

The security policy has a schedule configured that is currently outside the allowed time.

Why it fails: A schedule only permits or denies traffic at defined times; flood protection drops sessions exceeding zone thresholds, which matches the symptom. Schedules are tempting because they also deny otherwise-permitted traffic, but the stem specifies Flood Protection is enabled, making threshold-based drops the cause.

HA1 interface

Why it fails: HA1 is the dedicated high-availability synchronisation link between firewall peers, carrying state and configuration data, not administrative sessions. It is tempting because HA1 is a separate physical interface that isolates its traffic, and it would be correct when designing the heartbeat path between two firewalls in an active-passive pair.

VLAN interface

Why it fails: A VLAN interface is a Layer 3 construct that terminates traffic on a tagged VLAN; it does not itself provide the dedicated out-of-band management path the scenario requires. It is tempting because VLAN interfaces do isolate management traffic logically, and would be correct where a routed subinterface on a physical port is the intended design.

Ethernet 1/1

Why it fails: Ethernet 1/1 is a dataplane interface that forwards production traffic; assigning management access to it places administrative traffic on the same segment as user data, defeating the isolation requirement. It is tempting because it is a physical port, but a dedicated management interface is needed instead.

Decryption Mirror

Why it fails: Decryption Mirror copies decrypted traffic to a monitoring interface; it does not decrypt traffic inline for inspection, so the firewall cannot enforce policy on the inbound HTTPS session. It suits feeding decrypted packets to a passive analysis tool, whereas inbound server decryption requires a forward proxy or inbound SSL decryption policy.

Outbound (Forward Proxy) Decryption

Why it fails: Outbound forward proxy decryption re-signs sessions initiated by internal clients, so it cannot decrypt inbound connections arriving at the web server. It is tempting because the firewall already runs forward proxy for outbound traffic, but inbound inspection requires an inbound decryption policy with the server's certificate.

SSH Proxy

Why it fails: SSH Proxy applies to Secure Shell sessions on port 22, not HTTPS/TLS on 443, so it cannot decrypt inbound web traffic. It is tempting as another proxy-based inspection feature, but it is the correct choice only when auditing or tunnelling SSH connections, not TLS web server traffic.

Link monitoring is disabled.

Why it fails: Configuration synchronisation in an active/passive pair runs over the HA control link independently of link monitoring, so disabling link monitoring does not stop config sync. It is tempting because link monitoring affects failover behaviour, and would be the cause if the passive firewall failed to detect a monitored interface failure.

The passive firewall is not configured as a peer.

Why it fails: Peer configuration is not a prerequisite for HA synchronisation; the passive device synchronises once HA links and the active peer are correctly established. It tempts because peer relationships matter in HA topologies, but the actual cause here is a broken HA control or data link.

The firewalls are different models.

Why it fails: Although different models can be used in some HA configurations, the PAN-OS version must match. However, the question states that the passive firewall does not synchronize configuration changes, and the most likely cause is that configuration synchronization is not enabled, not a model mismatch.

Create separate device groups for each firewall and configure identical policies manually.

Why it fails: Separate device groups with manually duplicated policies create two divergent rule sets that drift apart, defeating the shared-rules requirement. It is tempting because device groups scope policy per firewall, and this would fit firewalls needing genuinely different rule sets.

Use templates to define security policies and assign to both firewalls.

Why it fails: Templates push device and network configuration, not security policy; rules placed there never reach the policy rulebase. It is tempting because templates handle per-firewall interface differences, and they would be correct for deploying interface or zone settings.

Use the Shared policy and override for interfaces.

Why it fails: Shared policy applies rules globally, but interface overrides only adjust interface-level settings, not the per-firewall interface configurations the scenario requires. It is tempting because Shared is the natural home for common rules, and it would fit firewalls sharing identical interfaces.

The destination NAT is causing asymmetric routing.

Why it fails: Destination NAT alters the translated destination address, but the stem describes a permit rule already matching source and destination, so NAT is not the cause. It is tempting because NAT causes asymmetric routing, and would be correct if return traffic bypassed the firewall.

The rule is too far down in the rulebase and a previous implicit deny is blocking.

Why it fails: PAN-OS evaluates rules top-down, so a matching permit above the deny would already have allowed the traffic; there is no implicit deny mid-rulebase. It is tempting because rule ordering matters, and would be correct if an explicit deny sat above the permit.

The application override is misconfigured.

Why it fails: Application override changes App-ID classification for specific traffic; it does not deny traffic matching a permit rule's source and destination. It is tempting because App-ID mismatches cause unexpected blocks, and would be correct if the application were being identified as the wrong one.

The route via 10.0.0.3 on ethernet1/4

Why it fails: Incorrect: Metric 20 is higher than metric 10.

The route via 10.0.0.4 on ethernet1/5

Why it fails: Incorrect: OSPF has higher preference (30).

All three routes are used in ECMP

Why it fails: Incorrect: Preferences differ, so ECMP does not apply.

The firewall is not connected to the cloud for App-ID updates.

Why it fails: App-ID updates are pulled from Palo Alto Networks update servers, not a cloud connection, so this cannot explain the block. It is tempting because App-ID signatures do require periodic updates, and stale signatures would be the correct diagnosis if the application itself were unrecognised rather than a sub-application mismatch.

Decryption is not enabled for Google Drive traffic.

Why it fails: Without decryption, the firewall cannot inspect the TLS-encrypted upload session, so App-ID may identify the application but not the file-transfer function, and the base rule's action does not permit the upload. It is tempting because decryption is required for encrypted traffic, and would be correct where policy depends on inspecting HTTPS content.

An application override is configured for Google Drive.

Why it fails: An application override forces Google Drive traffic onto a custom application or port, bypassing the App-ID signature that the google-drive-base rule matches, so the allow rule never applies. It is tempting because overrides exist to handle custom or non-standard applications, and would be correct for an internally hosted app App-ID misclassifies.

Zone Protection profile is set to 'Log at Session Start'

Why it fails: Zone Protection profiles apply flood, reconnaissance and packet-based attack thresholds at the ingress zone; they do not control per-rule traffic logging. The stem points to a security policy rule's logging action, so the Log at Session Start setting on the rule itself is what must be verified. Zone Protection would be relevant when tuning flood or scan detection thresholds.

The Log Forwarding profile is not applied

Why it fails: A Log Forwarding profile only routes already-generated logs to external destinations; it does not determine whether the firewall writes a Traffic log entry. The rule's own log setting controls that. Forwarding profiles would be correct when sending logs to a SIEM or syslog server.

Disable Server Response Inspection on the rule

Why it fails: Server Response Inspection affects content inspection of server replies, not whether sessions appear in Traffic logs. Logging is governed by the rule's log setting and log forwarding. Disabling it would be relevant when troubleshooting application-layer inspection issues, not missing log entries.

FQDN

Why it fails: An FQDN address object resolves a fully qualified domain name to IP addresses. It is not suitable for defining a static range of IP addresses because it relies on DNS resolution and does not allow specifying a start and end IP. This object type is used when the IP addresses may change dynamically based on DNS.

Dynamic

Why it fails: A dynamic address object is a member of a Dynamic Address Group and is populated based on tags. It does not allow manual specification of an IP range; instead, it is used for environments where IP addresses change frequently and are registered via tags. This does not meet the requirement of a fixed range.

IP Netmask

Why it fails: An IP Netmask object is used to define a subnet using a network address and a subnet mask, for example 10.1.1.0/24. It cannot represent an arbitrary range like 10.1.1.10 to 10.1.1.20 because that range does not align to a single subnet boundary. Therefore, this type would not accurately match only the intended addresses.

Dynamic address group with a tag-based filter

Why it fails: A dynamic address group uses tags to group registered IP addresses, but it does not resolve FQDNs. It relies on tags applied by other processes, such as User-ID or external sources. This would not automatically track the IP addresses of a domain name. Therefore, it does not meet the requirement.

Static address object with a single IP address

Why it fails: A static address object uses a fixed IP address that does not change automatically. If the IP addresses of the FQDN change, the administrator would need to manually update the object. This fails the requirement for automatic updates. Static objects are not suitable for dynamic FQDN resolution.

External Dynamic List (EDL) referencing a URL

Why it fails: An External Dynamic List imports IP addresses from an external server, but it requires the administrator to host a list at a URL. It does not automatically resolve an FQDN to its current IP addresses. The EDL must be manually updated or scripted to reflect DNS changes. This adds complexity and does not directly use DNS resolution.

SSL Decryption profile

Why it fails: An SSL Decryption profile defines how the firewall handles decryption, such as blocking expired certificates or untrusted issuers. It does not identify applications from certificates when traffic remains encrypted. The scenario asks for a Content-ID feature that can still control the application without decryption, so a decryption profile is not the mechanism that performs identification.

File Blocking profile

Why it fails: A File Blocking profile controls the transfer of files based on file type and direction, but it requires the firewall to see the file contents. Without decryption, the firewall cannot inspect the file payload to enforce the profile. Therefore, it cannot identify or control the SaaS application based on the server certificate in this scenario.

Data Filtering profile

Why it fails: A Data Filtering profile scans traffic for patterns such as credit card numbers or social security numbers. It operates on decrypted payloads and cannot inspect encrypted traffic. Since the traffic is not decrypted, the Data Filtering profile will not see the data patterns, so it cannot identify or control the application as required.

A static route in VR-A pointing to the SNMP, syslog, and SMTP servers

Why it fails: Adding static routes to VR-A would only help if the services were already egressing VR-A. The requirement is to use VR-B, and VR-A's routing table does not influence which virtual router a management service selects for its source.

A Policy-Based Forwarding (PBF) rule matching the firewall's own management traffic

Why it fails: Policy-Based Forwarding applies to transit traffic evaluated against security policy, not to firewall-originated management-plane traffic such as SNMP traps or syslog. PBF rules cannot intercept or redirect the firewall's own service traffic, so they do not meet this need.

The Management Interface's default gateway under Device > Setup > Interfaces

Why it fails: The management interface has its own dedicated routing table separate from dataplane virtual routers. Setting its default gateway only affects traffic originating from the MGT port itself and cannot steer service traffic out of a dataplane virtual router such as VR-B, so it fails here.

File Blocking profile that blocks the 'any' file type in the upload direction.

Why it fails: File Blocking profiles control file transfers, not data within HTTP POST requests. Blocking all file uploads would not prevent a user from typing a credit card number into a web form and submitting it. This approach does not address the requirement and would be ineffective.

Vulnerability Protection profile that blocks HTTP POST requests containing numeric patterns.

Why it fails: Vulnerability Protection profiles detect and block exploits and vulnerabilities, not sensitive data. They do not have the capability to identify credit card numbers in HTTP POST data. Using this profile would not meet the requirement and could cause false positives on legitimate traffic.

Antivirus security profile with a custom signature for credit card numbers.

Why it fails: Antivirus profiles are designed to detect malware, not sensitive data patterns. Custom signatures in Antivirus are for threats, not for credit card numbers. This feature cannot inspect for and block credit card numbers in web traffic, so it is incorrect for this scenario.

Continue

Why it fails: Continue is not an action in a Data Filtering profile. The profile actions are limited to Alert and Block. 'Continue' might be confused with the 'Allow' action in Security policies, but it is not applicable here. The administrator cannot configure a Data Filtering profile to 'Continue' when sensitive data is detected; they must choose to either alert or block.

Reset Client

Why it fails: Reset Client is an action available in some security profiles, such as Vulnerability Protection, but it is not a standard action in a Data Filtering profile. Data Filtering profiles typically offer Alert and Block actions. Reset Client would terminate the client-side connection, but it is not used for data filtering. Therefore, it is not a valid choice for this scenario.

Allow

Why it fails: Allow is not a valid action within a Data Filtering profile. Data Filtering profiles are designed to detect and respond to sensitive data patterns; they do not have an 'allow' action because the default behavior is to permit traffic unless a match triggers a configured action. The administrator would not use 'Allow' to block data; instead, they would use 'Block' or 'Alert'.