Hard Difficulty Questions

The address object must be a member of a static address group to be included in a dynamic group.

Why it fails: Dynamic groups use tags; membership in a static group is not required.

The security rule must specify the source zone explicitly.

Why it fails: The source zone is defined in the security rule separately; the address group is a source address, not zone.

The dynamic address group filter uses 'andd' which is a valid operator in older PAN-OS versions.

Why it fails: 'andd' is a typo; only 'and' is valid.

The dynamic address group only updates its membership after a system reboot.

Why it fails: Dynamic address groups update after commit or during policy evaluation; reboot is not required.

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.

The traffic will be allowed if the user uses HTTP instead.

Why it fails: The question is about HTTPS; it will be denied.

The traffic will be allowed because the rule has log-start enabled.

Why it fails: Logging does not affect allow/deny.

The traffic will be allowed because the source and destination zones match.

Why it fails: Application must match as well.

The address objects are not properly committed, so the tags are not applied.

Why it fails: If the address objects were not committed, the tags would not be applied at all, and the dynamic group would likely be empty. However, the scenario indicates that some servers are being allowed, which means the group is populated. The issue is that it includes servers with only one tag, not that it is empty. Therefore, a commit issue is not the cause.

The dynamic address group filter uses an OR condition instead of AND.

Why it fails: In PAN-OS dynamic address groups, the filter expression uses logical operators. If the filter is written as 'WebServer' or 'Production', it would use OR, but the administrator specified 'WebServer' and 'Production', which implies AND. The filter syntax requires explicit operators; if the administrator used a space or comma, it might be interpreted as OR. However, the scenario states the filter is 'WebServer' and 'Production', which is likely intended as AND. The issue is more likely with the tag application or filter syntax.

The address objects have been tagged with both tags, but the dynamic group filter is incorrectly using a wildcard.

Why it fails: If the filter used a wildcard, it might match tags that contain the substring, but the scenario does not mention wildcards. The filter is specified as 'WebServer' and 'Production', which are exact tag names. Using a wildcard would be a different configuration. The problem of including servers with only one tag suggests the filter is not enforcing the AND condition properly, not a wildcard issue.

The HA2 link is down or misconfigured

Why it fails: HA2 link failure would break state synchronisation, but the passive firewall was upgraded to 10.1 while the active remains on 10.0; PAN-OS requires matching versions for HA synchronisation. HA2 misconfiguration tempts because it commonly causes sync failures, yet here the version mismatch is the direct cause.

The HA keepalive timer is misconfigured

Why it fails: Keepalive timers govern heartbeat failure detection, not configuration synchronisation between peers. The passive firewall runs PAN-OS 10.1 while the active runs 10.0, and mismatched versions prevent HA sync. Timer misconfiguration tempts because it causes HA problems, but it would not produce this version-specific failure.

The passive firewall has preemption enabled

Why it fails: PAN-OS requires matching major versions for HA configuration synchronisation, so a 10.0 active peer cannot sync with a 10.1 passive peer regardless of preemption. Preemption only governs which firewall assumes the active role after failover, making it the right setting to tune when controlling failback order, not version compatibility.

The security rule uses application 'ssl' but not 'web-browsing' for the traffic.

Why it fails: The application 'ssl' correctly identifies the encrypted web traffic; 'web-browsing' would be unnecessary as it is a subapplication.

The firewall is missing the latest content updates for WildFire.

Why it fails: Even with latest updates, if WildFire is not enabled in the profile, it won't submit unknown files.

The decryption exclusion list includes the domain of the malware source.

Why it fails: The domain is not in the financial services category, so it is decrypted.

The security rules were modified.

Why it fails: Security rule changes affect whether traffic is permitted or denied, not whether App-ID classifies an application correctly. This tempts because rule edits often follow upgrades, but it would be the answer if traffic were blocked despite accurate identification rather than misidentified.

The application database was rolled back.

Why it fails: Rolling back the application database would restore older signatures, but the scenario describes an upgrade, so the database advanced rather than reverted. This would be correct if an administrator had deliberately downgraded content and then observed stale or missing App-ID mappings.

The firewall needs a reboot.

Why it fails: A reboot is not required for App-ID content updates; the firewall applies new signatures dynamically. This tempts because reboots resolve many transient faults, but it would be correct only if the stem described a hung process or failed content installation, neither of which is stated.

SSL decryption is not enabled for the custom application.

Why it fails: Decryption is not required for App-ID.

The custom application needs to be added to the 'ssl' application group.

Why it fails: Groups are not required.

The application override was not committed.

Why it fails: Assuming it was committed.

The 'web-browsing' application does not include HTTP.

Why it fails: It does.

A custom application must be created for port 8080.

Why it fails: No, web-browsing works on any port.

App-ID cannot identify HTTP over non-standard ports.

Why it fails: App-ID can identify HTTP on any port.

The application is not correctly identified because the SSH server uses a non-standard port.

Why it fails: Non-standard SSH ports would affect every Internal subnet equally, yet other subnets connect successfully, so application identification cannot explain the subnet-specific failure. App-ID port customisation is genuinely required when services run off standard ports, but nothing in the stem indicates that.

There is a deny rule placed above the allow rule that matches the new subnet but not the other subnets.

Why it fails: A deny rule above the allow rule would block the new subnet only if it matched it, but the stem gives no evidence of such a rule; the described symptom follows a zone-mapping change. Deny rules above allows are a legitimate design for carving exceptions out of broad permits, so this would fit if the stem mentioned an explicit block.

The rule's source address object is incorrectly defined as '10.0.0.0/8' but the new subnet is not actually within that range.

Why it fails: The administrator has already confirmed the new subnet's addresses fall inside 10.0.0.0/8, so an addressing mismatch contradicts the stated facts. Verifying that an address object truly contains a subnet is valid troubleshooting, and would be the answer if containment were unconfirmed.

Ensure that the HA2 interfaces are also connected and configured correctly

Why it fails: HA2 is for data synchronization, not for control plane communication. HA formation relies on HA1.

Change the HA2 IP addresses to be on the same subnet as HA1

Why it fails: HA1 and HA2 should be on different subnets to avoid conflicts.

Enable HA ping on the HA1 interface to test connectivity

Why it fails: HA ping is a monitoring feature, not a prerequisite for HA formation.

The 'Shared' device group is not included in the device group hierarchy for the regional device groups

Why it fails: This is incorrect. The 'Shared' device group is automatically inherited by all firewalls managed by Panorama, regardless of whether regional device groups are nested under it. Hierarchy is not required for shared policy inheritance.

Regional administrators created local policies in their own device groups with higher order than shared policies

Why it fails: This is incorrect. Local policies with higher priority can override shared policies on the firewall, but they do not prevent the firewall from receiving the shared policies. The issue is that shared policies are not being received at all.

The template stack does not include the shared template

Why it fails: This is incorrect. The template stack issue would affect template settings (e.g., network settings), not device group policies. Shared policies are within device groups, not templates.

Change the service to TCP/443 and allow all applications

Why it fails: Allowing all applications on TCP/443 bypasses App-ID enforcement, so the hacking category is no longer identified and the URL Filtering block cannot apply, weakening security. It is tempting because it guarantees the site loads, and would be correct if the requirement were to permit all HTTPS traffic regardless of application.

Remove the URL Filtering profile from the security rule

Why it fails: Removing the URL Filtering profile from the security rule would allow all hacking sites, which does not maintain security.

Change the URL Filtering action for 'hacking' category to 'allow'

Why it fails: Changing the URL Filtering action for 'hacking' to 'allow' would permit all websites in that category, not just the specific one, which weakens security.

The security policy rule is missing the 'ftp-data' application, which is required for file transfers.

Why it fails: The 'ftp' application includes the control channel and automatically allows the data channel. There is no separate 'ftp-data' application that needs to be explicitly allowed. The firewall's App-ID engine dynamically opens data ports. Thus, this option is incorrect.

The service 'application-default' only allows TCP port 21, so passive mode data ports are blocked.

Why it fails: The 'application-default' service for 'ftp' includes TCP port 21 for the control channel. However, the firewall's App-ID dynamically allows data ports for FTP. The service definition alone does not block passive mode. The issue is more complex, often involving NAT or inspection settings. Thus, this option is incorrect.

The application 'ftp' does not include the dynamic ports used in passive mode, so a separate rule is needed.

Why it fails: Palo Alto Networks firewalls use App-ID to detect FTP and automatically open the required data ports for both active and passive modes. A separate rule is not needed. The issue is likely elsewhere, such as a missing security profile or misconfiguration. Therefore, this option is incorrect.

The security policy is configured to allow SSL, but the decryption policy is not configured to decrypt SSL traffic.

Why it fails: The exhibit shows POL-1 has action 'forward-proxy', which means decryption is enabled in the security policy. However, the issue may be elsewhere.

The destination IP 192.168.1.100 is not in the decryption policy's destination list.

Why it fails: POL-1 has destination 192.168.1.0/24, which includes 192.168.1.100.

The firewall is not receiving the SSL handshake because the session is already established.

Why it fails: The session is in ACTIVE state and the firewall sees the SSL application, so it receives the handshake.

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.

Configure a NAT rule to translate the syslog source IP to the ethernet1/2 IP, and set the syslog server in Device > Server Profiles > Syslog.

Why it fails: NAT rules apply to transit traffic, not to management plane traffic. Syslog messages are generated by the firewall itself and use the interface's IP as source. NAT is not required to send syslog out a specific interface; routing and Interface Management Profiles are the correct mechanisms.

Set the syslog server in Device > Server Profiles > Syslog and enable 'Use Management Interface' for syslog.

Why it fails: The 'Use Management Interface' option, if available, forces syslog to use the management interface, not ethernet1/2. The requirement is to use ethernet1/2, so this option would not achieve the goal. Routing and Interface Management Profiles are needed instead.

Create a security policy rule allowing syslog traffic from the firewall to 172.16.1.100, and set the syslog server in Device > Server Profiles > Syslog.

Why it fails: Security policy rules do not apply to management plane traffic such as syslog. Syslog is generated by the management plane and sent out the interface determined by routing and Interface Management Profiles. Therefore, a security rule would not direct syslog traffic through ethernet1/2.

Configure a decryption policy rule with action 'No Decrypt' for TLS 1.0 traffic.

Why it fails: Bypasses decryption but does not report the TLS version.

Use a Security policy rule to block TLS 1.0 traffic.

Why it fails: Block is too aggressive; need alert first.

Configure a decryption policy rule with action 'Decrypt' and enable 'TLS Version Check' with action 'block'.

Why it fails: Block would prevent connections, not just report.

The firewall is rejecting many sessions due to certificate errors.

Why it fails: Only 12 errors in the last hour, not 'many'.

The decryption policy is not being hit because of low policy hits.

Why it fails: Policy hits are 1800 total, indicating active usage.

The current decryption session count is at its peak.

Why it fails: Current is 523, peak is 1024, so not at peak.

The firewall will block the connection and generate an alert.

Why it fails: The firewall may block if configured, but default action is to generate an untrusted certificate.

The firewall will decrypt the traffic using its own certificate and re-encrypt with the partner's certificate.

Why it fails: The firewall uses its own certificate to sign the server's certificate, not the partner's.

The firewall will automatically trust the self-signed certificate and pass traffic without decryption.

Why it fails: The firewall does not automatically trust self-signed certificates.