Select Two (Multi-Select) Questions

Whether logging is enabled on the rule.

Why it fails: Logging is for visibility, not for blocking decision.

Whether SSL decryption is enabled for the traffic.

Why it fails: Decryption is for inspection, not a direct cause of blocking.

Simpler configuration for traditional protocols like HTTP and FTP

Why it fails: While Application-Based Security Policies identify traffic by application signatures and decryption, a Port-Based Policy relies on static L4 port numbers, which HTTP and FTP can easily use without application awareness. This option is tempting because for simple, well-known protocols, a port-based rule is indeed quicker to configure and troubleshoot. However, the question asks for benefits of application-based policy, which provides granular control over application functions—such as blocking specific FTP commands—that port-based rules cannot enforce.

Easier to allow applications that use dynamic ports

Why it fails: App-ID identifies the application regardless of the port it uses, so dynamic-port applications are matched without opening wide port ranges. This is a genuine benefit, but the question asks for two, and this option is not among the accepted pair; the expected answers concern application identification and policy granularity rather than dynamic ports specifically.

Increased throughput because firewall does not need to inspect ports

Why it fails: Application-based policies still inspect every packet's ports and payload via App-ID; throughput is governed by firewall processing capacity, not port inspection. It is tempting because port-based rules are coarse, but the correct benefit is identifying applications regardless of port, protocol or evasion technique, not raw performance.

EDLs have a fixed refresh interval that cannot be changed.

Why it fails: The refresh interval is configurable.

EDLs must be manually updated by an administrator.

Why it fails: EDLs are automatically refreshed from an external source.

EDLs allow the administrator to add individual IPs directly via the GUI.

Why it fails: EDLs are read-only in the GUI; IPs cannot be added manually.

Assign an IP address to the virtual wire

Why it fails: A virtual wire operates as a Layer 2 bump-in-the-wire, binding two interfaces into a transparent pair; assigning an IP address would make it a Layer 3 interface and break that transparency. It is tempting because interfaces commonly hold addresses, but vwire pairs deliberately forward traffic without participating in routing.

Create a security policy allowing traffic on the virtual wire

Why it fails: Security policies are applied to zones, not directly to vwires; vwire interfaces are assigned to zones where policies apply.

URL filtering

Why it fails: App-ID identifies applications by inspecting payload signatures, protocol decoders and behavioural heuristics, not by URL categories. URL filtering is a separate security profile that permits or blocks web traffic after App-ID has already classified it, so it cannot serve as an identification method here.

Source port number

Why it fails: App-ID classifies applications using protocol and payload signatures, plus TLS decryption where needed; source port is ephemeral and carries no application identity. Port-based identification is what legacy firewalls did, and it is the correct method only when classifying by service port, not application.

Source IP address

Why it fails: App-ID classifies traffic through application signatures, protocol decoding and session behaviour, not by packet headers. Source IP address is used in policy rules to match zones or addresses once an application is known, so it cannot identify which application generated the session.

Server

Why it fails: Server is not a PAN-OS security profile group; the defaults are strict, default and best-practice. It tempts because PAN-OS security profiles include categories such as antivirus, anti-spyware, vulnerability, URL filtering, file blocking, wildfire analysis and data filtering, and server-related protections exist within them, but no group is named Server.

Custom

Why it fails: Custom is a user-created container, not one of PAN-OS's predefined security profile groups. The defaults are strict, default and best-practice. It tempts because administrators do create custom groups to bundle profiles, but the question asks specifically for the built-in default groups shipped with the platform.

NTLM

Why it fails: NTLM is not supported for management authentication.

OAuth

Why it fails: OAuth is not a native authentication method for PAN-OS management.

Kerberos

Why it fails: Kerberos is not supported for management authentication.

Enable logging on all rules for maximum visibility.

Why it fails: Logging every rule floods the traffic log with allowed sessions, consuming storage and obscuring genuine threats; best practice logs at session end on rules that matter. Enabling logging on all rules would be correct only where full audit capture is mandated, such as a regulated enclave.

Use a single 'allow all' rule to simplify management.

Why it fails: A blanket allow-all rule grants every application and user unrestricted access, defeating the least-privilege model that App-ID and zone-based policy enforcement depend on. It is tempting because it eliminates rule-management effort, and it would suit a lab or trusted backplane segment where granular inspection is deliberately not required.

Disable unused rules instead of removing them.

Why it fails: Disabling leaves the rule in the rulebase, consuming policy evaluation and obscuring the security posture; best practise is to remove rules that are no longer required. Disabling is tempting because it preserves configuration for quick rollback, and it would be correct for a rule temporarily suspended during troubleshooting or a seasonal change window.

DNS resolution for the Panorama hostname

Why it fails: IP can be used directly; DNS is not required.

A DHCP server to assign an IP to the management interface

Why it fails: Management IP is typically static.

IPsec Decryption

Why it fails: IPsec decryption applies to tunnel-encapsulated traffic terminating on the firewall, not to SSL/TLS sessions, which require the firewall to hold the server certificate and private key for forward proxy decryption. It is tempting because IPsec also encrypts payloads, and would be correct for inspecting site-to-site VPN traffic.

SSH Proxy

Why it fails: SSH Proxy decrypts outbound SSH sessions, not SSL/TLS traffic, so it cannot inspect HTTPS flows. SSL Forward Proxy and SSL Inbound Inspection are the valid decryption methods. SSH Proxy is chosen when auditing tunnelled SSH command traffic rather than web TLS.

Decryption Mirror

Why it fails: Decryption Mirror copies decrypted traffic to a tapped interface for external capture; it does not itself decrypt traffic for inspection by the firewall's security profiles. It would be correct when feeding cleartext to a third-party analysis appliance rather than enforcing policy inline.

Set the syslog server to use TCP port 514.

Why it fails: Port and protocol are optional; default is UDP 514.

Specify the syslog facility code in the log forwarding profile.

Why it fails: Facility code is optional and defaults to a standard value.

Block the common ports used by the application.

Why it fails: Blocking the known ports fails because the application shifts to other ports, and port-based rules cannot identify it. App-ID classifies the application itself, so a single deny rule covers every port. Port blocking suits legacy fixed-port services where no application identification exists.

Disable App-ID on the zone to prevent inspection.

Why it fails: Disabling App-ID stops the firewall inspecting traffic, so no application can be identified or blocked at all. App-ID is what lets one rule match an application regardless of port. Disabling inspection suits troubleshooting or trusted high-throughput zones, not enforcement.

Create a security rule allowing the application but with a limit.

Why it fails: An allow rule with a limit still permits the application's traffic, so nothing is blocked; rate limiting only caps session counts. It would suit throttling a bandwidth-heavy but permitted application. Blocking requires a deny rule matching the application's App-ID, which identifies it across every port it uses.

Allow all TCP traffic on port 53.

Why it fails: TCP DNS can also be used for tunneling.

Enable logging on all DNS traffic for analysis.

Why it fails: Logging does not prevent tunneling.

Block all UDP traffic on port 53.

Why it fails: This would block legitimate DNS and cause outages.

App-ID is only effective for well-known commercial applications.

Why it fails: App-ID recognises thousands of applications, including custom, internally developed and encrypted ones, using signatures, decoders and heuristics rather than a commercial-only catalogue. Restricting it to well-known commercial applications is tempting because signature coverage is deepest there, but custom App-ID exists precisely for bespoke traffic.

App-ID primarily identifies applications based on port numbers.

Why it fails: App-ID identifies applications by signature, protocol decoder, heuristics and behavioural analysis, deliberately moving beyond port-based classification because applications tunnel over standard ports. Port numbers are tempting since legacy firewalls used them, but App-ID's purpose is to defeat port-hopping and evasive traffic.

App-ID requires at least 10 packets to identify an application.

Why it fails: App-ID identifies applications from the first packet by matching signatures, protocol decoders, heuristics and behavioural patterns, so no ten-packet threshold exists. The ten-packet figure is tempting because some heuristic or behavioural identification needs several packets, but that is not a general App-ID requirement.

URL Filtering

Why it fails: URL Filtering classifies web destinations by category and reputation; it inspects neither file payloads nor protocol exploits, so it cannot block malware delivery. It is tempting because malicious sites distribute malware, and URL Filtering is the right profile when policy must restrict browsing to approved categories.

File Blocking

Why it fails: File Blocking controls file transfers by type, not malware signatures or exploit behaviour, so it cannot inspect payloads for threats. It is tempting because blocking executables and archives sounds protective, and it is correct when policy must prevent specific file types leaving the network.

Use the CLI command 'request system backup config schedule'

Why it fails: Incorrect: No such CLI command exists.

Set a recurring cron job via the firewall's built-in cron

Why it fails: Incorrect: The firewall does not expose cron for user-defined jobs.

Review the system resources to check CPU usage.

Why it fails: CPU usage reflects device health and dataplane load, not whether a specific session matched a security policy rule. It is tempting during troubleshooting because resource exhaustion can cause drops, but system resources would be the right check when traffic is broadly failing rather than one website being unreachable.

Look at the Threat log for any malware detections.

Why it fails: The Threat log records signatures, antivirus and vulnerability events after traffic is allowed, so it cannot confirm whether the policy rule matched the session. It is tempting because a blocked website feels security-related, but Threat logs are the correct place when traffic passes the policy and a threat inspection action drops it.

Examine the URL filtering profile applied to the policy.

Why it fails: A URL filtering profile inspects HTTP request URLs for category or custom blocking, not whether the security policy rule matched the session. It is tempting because the symptom involves a specific website, but URL filtering would be the right check when the policy already permits traffic and a category block is suspected.

A valid Panorama license

Why it fails: License is needed for Panorama, not a prerequisite for the firewall to be managed.

Panorama plugin installed on the firewall

Why it fails: Plugin is optional, not required.

HTTP

Why it fails: HTTP is insecure and often disabled to enforce HTTPS.

Telnet

Why it fails: Telnet is insecure and rarely used, typically disabled.

Create dynamic updates to rules

Why it fails: Hit counts inform analysis and rule ordering decisions; they do not themselves generate or push dynamic rule updates, which require external automation or the Dynamic Address Group mechanism. Hit counts are used to identify unused or heavily matched rules for manual tuning, not to rewrite rules automatically.

Determine rule shadowing

Why it fails: Hit counts reveal which rules never match, but shadowing is determined by comparing rule criteria and order, not counters. A shadowed rule simply shows zero hits, which is ambiguous with a genuinely unused rule, so hit counts alone cannot confirm shadowing; they are used to flag rules for manual review.