A. DHCPv6 Client with Prefix Delegation

Explanation:
PAN-OS 11.0 introduced several enhancements for IPv6 support, with DHCPv6 Client with Prefix Delegation being a key feature. This allows the firewall to:

Act as a DHCPv6 client to obtain an IPv6 address from an ISP.
Receive a delegated IPv6 prefix from the ISP to assign addresses to internal networks.
Fully support IPv6 connectivity and routing in dual-stack or IPv6-only environments.

Why the Other Options Are Incorrect:
B. OSPF:
OSPFv3 (for IPv6) was supported in PAN-OS prior to version 11.0. It is not a new feature in 11.0.
C. DHCP Server:
The firewall's DHCP server has supported IPv6 (DHCPv6) for address assignment in earlier versions. This is not new to 11.0.
D. IKEv1:
IKEv1 has supported IPv6 for IPsec VPNs in previous PAN-OS versions. It is not a new feature in 11.0.

Reference:
PAN-OS 11.0 release notes highlight DHCPv6 Client with Prefix Delegation as a new feature to enhance IPv6 deployment capabilities, particularly for internet-facing interfaces and internal subnet addressing.

A. Enable NAT Traversal on Site B firewall
D. Match IKE version on both firewalls.

Explanation:
When configuring a VPN tunnel with a dynamic peer, specific settings must be matched on both sides of the connection to ensure successful negotiation.

A. Enable NAT Traversal on Site B firewall: NAT traversal (NAT-T) is essential when one or both endpoints have a dynamic public IP address and might be behind a NAT device. The Site A firewall uses a DHCP-assigned address, which means its address can change. If the Site B firewall is behind a NAT device or if the connection passes through one, enabling NAT-T ensures that the VPN packets can correctly traverse the NAT boundary. Without this, the connection will likely fail.
D. Match IKE version on both firewalls: The IKE Gateway configuration for Site A shows IKEv1 only mode. For a successful tunnel, the remote peer (Site B) must also be configured to use IKEv1. If Site B is set to IKEv2 or a different mode, the IKE negotiation will fail. Matching the IKE version is a fundamental requirement for any IPSec tunnel setup.

Why the Other Options Are Incorrect
B. Configure Local Identification on Site A firewall:
The provided image of the Site A configuration already shows that the Local Identification is configured as FQDN (email address) with the value user@acme.com. No change is needed for this setting.
C. Disable passive mode on Site A firewall:
The "Passive Mode" option on the Site A configuration is currently disabled (unchecked). Passive mode would cause the firewall to only listen for incoming connections and not initiate the connection itself. Since Site A has a dynamic IP address, it must be the initiator of the tunnel, so disabling passive mode is the correct setting. Therefore, this option does not require a change.

A. Resource Protection

Explanation:
In a Palo Alto Networks firewall, a DoS Protection Profile is used to mitigate Denial of Service (DoS) attacks by applying specific protections to network traffic. The question focuses on identifying which DoS Protection Profile specifically detects and prevents session exhaustion attacks targeting specific destinations. Session exhaustion attacks aim to overwhelm a target’s resources by flooding it with excessive sessions (e.g., TCP or UDP connections), depleting its session table. The Resource Protection profile is designed to address this by limiting the number of concurrent sessions to specific destinations, making it the correct choice.

Correct Answer
A. Resource Protection:
The Resource Protection profile (configured under Objects > Security Profiles > DoS Protection > Resource Protection) detects and prevents session exhaustion attacks by limiting the maximum number of concurrent sessions to a specific destination IP or subnet. It uses classified protection, which applies to specific source or destination addresses defined in the DoS Protection rule. By setting a session limit (e.g., 10,000 concurrent sessions), the firewall blocks additional sessions to the target when the threshold is reached, mitigating attacks like TCP SYN floods or UDP floods aimed at exhausting session resources.
Example:
A DoS Protection rule with Resource Protection set to limit 5,000 concurrent sessions to a server’s IP prevents session exhaustion by dropping excess connections.

Why Other Options Are Incorrect
B. TCP Port Scan Protection:
TCP Port Scan Protection is part of Reconnaissance Protection in a Zone Protection Profile, not a DoS Protection Profile. It detects and blocks port scans (e.g., attempts to probe multiple TCP ports), not session exhaustion attacks. It focuses on reconnaissance behavior, not resource limits.
C. Packet Based Attack Protection:
Packet Based Attack Protection (in Zone Protection Profiles, under Packet Based Attack Protection) filters malformed or anomalous packets (e.g., invalid TCP flags, ICMP fragments) to prevent DoS attacks. While it mitigates certain flood attacks (e.g., SYN floods via SYN Random Early Drop), it operates at the zone level, not for specific destinations, and does not focus on session limits.
D. Packet Buffer Protection:
Packet Buffer Protection (in Zone Protection Profiles, under Packet Buffer Protection) prevents DoS attacks by protecting the firewall’s packet buffers from being overwhelmed by high-rate traffic from a single source. It is an aggregate protection mechanism, not specific to destinations, and focuses on buffer utilization rather than session exhaustion.

Technical Details
Resource Protection Configuration:
Navigate to Objects > Security Profiles > DoS Protection, create a profile, and under Resource Protection, set Max Concurrent Sessions (e.g., 10,000).
Apply the profile to a DoS Protection rule (Policies > DoS Protection) with a specific destination IP/subnet.
CLI: set profiles dos-protection resource-protection max-concurrent-sessions .
Application: Use Classified DoS Protection rules to target specific destinations, unlike Aggregate rules for broader zones.
Monitoring: Check session limits via Monitor > Logs > DoS Protection or CLI (show dos-protection rule statistics).
Best Practice: Combine with Zone Protection for layered defense but use Resource Protection for destination-specific session limits.

PCNSE Relevance
The PCNSE exam tests your ability to configure DoS Protection Profiles to mitigate specific attack types, such as session exhaustion. Understanding the role of Resource Protection in classified DoS rules is critical for targeted protection scenarios.

References:
Palo Alto Networks Documentation (PAN-OS Admin Guide):
Details Resource Protection for session exhaustion in DoS Protection Profiles.
Palo Alto Networks Knowledge Base (Article ID: 000042345):
Explains Packet Based Attack Protection and Packet Buffer Protection in Zone Protection Profiles.

A. Panorama provides information about system resources of the managed devices in the Managed Device > Health menu.

Explanation:

Panorama offers Health Monitoring of managed devices:
From Panorama GUI → Managed Devices → Health, administrators can view:
CPU usage
Memory usage
Disk usage
Session count
Other key system metrics
This allows administrators to proactively troubleshoot high CPU or resource-related issues without needing to log into each firewall individually.

❌ Why the Other Options Are Wrong
B. Firewalls send SNMP traps to Panorama when resource exhaustion is detected…
→ Incorrect. Firewalls can send SNMP traps, but to an SNMP server, not to Panorama. Panorama does not act as an SNMP trap receiver.
C. Panorama monitors all firewalls using SNMP…
→ Incorrect. Panorama does not use SNMP to monitor firewalls. It collects health/status data directly via management communication with firewalls.
D. Panorama provides visibility of all logs but not resource utilization…
→ Incorrect. Panorama provides both log visibility and health monitoring (CPU, memory, etc.) under the Managed Devices > Health section.

📘 Reference:
From Palo Alto Networks Docs:
“Panorama provides device health information (CPU, memory, disk usage, and sessions) for each managed firewall in the Managed Devices > Health menu.”

B. HIP profiles are configured but not added to security rules in the data center firewall
C. User ID is not enabled in the Zone where the users are coming from in the data center firewall.

Explanation:
If HIP match logs are visible on the edge firewall but not on the data center firewall, the issue is likely due to missing policy enforcement or lack of user mapping. Two key reasons explain this behavior:

✅ B. HIP profiles are configured but not added to security rules in the data center firewall
HIP match logs are only generated when traffic matches a security rule that includes a HIP profile. If the data center firewall has HIP profiles defined but does not apply them to any security rules, the firewall will not evaluate HIP data, and no match logs will be created.
“HIP profiles must be applied to security rules on the data center firewall to enforce access restrictions based on the received HIP reports.”
✅ C. User ID is not enabled in the Zone where the users are coming from in the data center firewall
HIP enforcement relies on User-ID mappings to associate traffic with authenticated users. If User-ID is not enabled on the zone where GlobalProtect users enter the data center firewall, the firewall cannot correlate HIP data with user sessions, and HIP-based policies will not trigger.
“User-ID must be enabled on the zone where the users are located in the data center firewall.”

❌ Why Other Options Are Incorrect:
A. Log Forwarding Profile is configured but not added to security rules in the data center firewall
This affects log forwarding, not log generation. HIP match logs won’t be created unless the traffic hits a rule with a HIP profile.
D. HIP Match log forwarding is not configured under Log Settings in the device tab
This controls whether HIP logs are forwarded, not whether they are generated. The issue here is log absence, not forwarding.

References:
Palo Alto Networks Knowledge Base: HIP Match Logs Are Not Generated When HIP Match Fails

D. The forward trust certificate has not been signed by the self-singed root CA certificate.

Explanation:

In a Palo Alto Networks SSL Forward Proxy decryption setup, there are three important certificate components involved:

1. Self-signed Root CA Certificate – Used to sign all forward trust and forward untrust certificates.
2. Forward Trust Certificate – Used by the firewall to sign certificates for trusted sites that it intercepts and decrypts.
3. Forward Untrust Certificate – Used by the firewall to sign certificates for untrusted sites.

To avoid browser warnings during decryption:

Clients must trust the root CA certificate.
The forward trust and forward untrust certificates must be signed by the root CA certificate.

In the scenario:

The administrator installed the self-signed root CA in all clients — ✔️ correct step.
But users are still receiving warnings when visiting SSL sites — 🚫 problem.

The most likely cause is that the firewall is using a forward trust certificate that is not signed by the root CA, so browsers don’t recognize the certificate chain and display "unsecured website" warnings.

❌ Why the other options are incorrect:

A. The forward untrust certificate doesn’t need to be trusted by clients because it’s meant to signal untrusted sites. This wouldn’t cause warnings for all sites.
B. Clients don’t need the forward trust certificate installed — they just need to trust the root CA that signed it.
C. Having the same CN on multiple certificates isn’t recommended but won’t directly cause SSL warnings unless there's a trust chain issue.

🔍 Reference:

Palo Alto Networks Documentation:
Configure SSL Forward Proxy
Generate a Certificate

C. Exceptions lab

Explanation:
To determine what action the firewall will take for a specific CVE (Common Vulnerabilities and Exposures), the administrator should navigate to the Exceptions tab within the Vulnerability Protection profile. This tab provides granular visibility into individual threat signatures, including those mapped to CVEs, and allows the administrator to view or override the default action (e.g., alert, drop, block).
From there, selecting “Show all signatures” enables filtering by CVE ID, threat name, or severity. The action column will display what the firewall is configured to do when that specific CVE signature is triggered.
This is confirmed in Palo Alto’s Threat Signature Exception documentation.

❌ Why the other options are incorrect
A. The profile rule action:
This shows the general action for the rule (e.g., alert or block), but not per-CVE granularity. It doesn’t reveal what happens for a specific CVE signature.
B. CVE column:
This column helps identify which CVE a threat signature maps to, but it doesn’t show the firewall’s configured action. It’s informational only.
D. The profile rule threat name:
Like the CVE column, this helps locate the signature but doesn’t show or control the action taken. You must go to the Exceptions tab to see or change the action.