D. not-applicable

Explanation:

Why:
The log shows Action: deny and Session End Reason: policy-deny. When traffic is blocked by policy before App-ID can inspect payload, the firewall can’t identify an application and logs it as not-applicable. This is exactly how PAN-OS behaves when a session is denied on the first packet(s)—no app match is attempted, so the Application field is not-applicable.

Why the others are wrong
A. Incomplete → Used when the TCP 3-way handshake didn’t complete or completed with no identifiable data; typically seen on allowed sessions that later age out/reset, not on immediate policy denies.
B. unknown-tcp → Requires a completed handshake and payload that doesn’t match any App-ID; again, not a policy-deny on first packet.
C. Insufficient-data→ Handshake finished and there was some data, but not enough to identify an app; not the case for a policy-denied sess

D. It enhances security by actively blocking access to potentially insecure sites with expired certificates or untrusted issuers.

Explanation:
The scenario involves a decryption policy with an action set to "No Decryption," paired with a decryption profile configured according to best practices on a Palo Alto Networks firewall. The question asks what protections this policy provides to the enterprise. Let’s analyze the configuration and evaluate the options.

Configuration Context:
Decryption Policy with "No Decryption": This action indicates that the firewall will not decrypt the SSL/TLS traffic matching this policy. Instead, it will allow the traffic to pass through without inspection of the encrypted payload. However, the firewall still evaluates the SSL/TLS handshake and certificate details against the associated decryption profile.
Decryption Profile: A decryption profile defines rules for handling SSL/TLS sessions, such as certificate validation, supported protocols, and ciphers. Best practices for a decryption profile typically include:
Enforcing strict certificate validation (e.g., checking for expired certificates, untrusted issuers, or revoked certificates via CRL/OCSP).
Blocking sessions that fail these checks.
Limiting supported TLS versions and ciphers to enhance security.
Impact: Even with "No Decryption," the firewall can still provide security by enforcing certificate-based controls defined in the decryption profile, rather than allowing all traffic blindly.

Why D. It enhances security by actively blocking access to potentially insecure sites with expired certificates or untrusted issuers?
Purpose:When the decryption action is set to "No Decryption," the firewall does not decrypt the traffic but still inspects the SSL/TLS handshake. The decryption profile, configured to best practices, includes rules to validate certificates. If a certificate is expired, issued by an untrusted Certificate Authority (CA), or otherwise invalid, the firewall can block the session based on the profile’s settings (e.g., "Block" action for failed certificate checks).
Protection Mechanism:
The profile checks the certificate chain, expiration dates, and trust status against the firewall’s trusted CA list.
If the certificate fails validation, the session is blocked, preventing access to insecure or potentially malicious sites.
Best Practice Alignment: A well-configured decryption profile includes options like "Block sessions with expired certificates" and "Block sessions with untrusted issuers," which are active even with "No Decryption."
Reference: Palo Alto Networks documentation states, "Even with No Decryption, the firewall can enforce certificate validation rules from the decryption profile to block insecure connections."

Why Not the Other Options?
A. It allows for complete visibility into certificate data, ensuring secure connections to all websites:
Explanation: "No Decryption" means the firewall does not inspect the encrypted payload or provide visibility into the content of the traffic. While it can see certificate data during the handshake, it does not ensure secure connections to all websites; it only blocks insecure ones based on certificate validation.
Why Incorrect: This overstates the visibility and security assurance, as decryption is not performed.
B. It ensures that the firewall checks its certificate store, enabling sessions with trusted self-signed certificates even when an alternative trust anchor exists:
Explanation: The firewall checks certificates against its trusted CA store, but "No Decryption" does not inherently allow sessions with self-signed certificates unless they are explicitly trusted (added to the firewall’s certificate store). If an alternative trust anchor exists and is untrusted, the session would be blocked, not enabled.
Why Incorrect: This misrepresents the behavior; self-signed certificates are blocked unless pre-trusted, and the focus is on blocking, not enabling.
C. It encrypts all certificate information to maintain privacy and compliance with local regulations:
Explanation: "No Decryption" does not encrypt certificate information; the certificates are already encrypted in the SSL/TLS handshake and visible to the firewall during validation. The policy does not alter or encrypt data; it passes traffic without inspection.
Why Incorrect: This is factually incorrect, as the policy does not perform encryption.

Additional Context:
Decryption Policy Types: Options include "Decrypt" (full inspection), "No Decryption" (pass-through with validation), and "Decrypt & Forward Proxy" (for outbound traffic). "No Decryption" is often used for traffic where decryption is impractical (e.g., performance constraints) but still requires security checks.
Best Practice Configuration:
Enable "Block sessions with expired certificates" and "Block sessions with untrusted issuers" in the decryption profile.
Use a Forward Trust certificate or external CA for trusted sites.
Exclude high-risk traffic from decryption only after validating certificates.

Monitoring:
Check Monitor > Logs > Threat for blocked sessions due to certificate issues. PCNSE Exam Relevance: This question tests your understanding of decryption policies and profiles, a key topic in the PCNSE exam. It requires knowledge of how "No Decryption" interacts with certificate validation.

Conclusion:
A decryption policy with an action of "No Decryption" and a best-practices decryption profile enhances security by actively blocking access to potentially insecure sites with expired certificates or untrusted issuers, leveraging certificate validation without decrypting the traffic.

References:
Palo Alto Networks Documentation: Decryption Policy Configuration
Palo Alto Networks Documentation: Decryption Profile Best Practices
ExamTopics PCNSE Discussion: Decryption and Certificate Validation

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

B. Change the Group IDs in the High Availability settings to be different from the other firewall pair on the same subnet.

Explanation:
When multiple HA firewall pairs exist in the same subnet, and they share the same HA Group ID, Palo Alto Networks firewalls will generate identical virtual MAC addresses for their interfaces. This leads to MAC address conflicts, causing misrouting or packet drops in upstream devices.

To resolve this, the administrator should:
Change the HA Group ID on one of the firewall pairs.
This causes the firewall to generate a unique virtual MAC address, eliminating the conflict.
This is a documented behavior in Palo Alto Networks' HA architecture:
“Virtual MAC addresses are generated based on the HA Group ID. If multiple HA clusters use the same Group ID, the same MAC address is generated.”

❌ Why Other Options Are Incorrect:
A. Configure a floating IP between the firewall pairs Floating IPs are used for failover, not MAC address resolution. They don’t affect virtual MAC generation.
C. Change the interface type from L3 to VLAN Interface type changes don’t resolve MAC conflicts caused by HA virtual MAC logic.
D. Run CLI command: set network interface vlan arp This is not a valid or relevant command for resolving HA MAC conflicts.

Reference:
Palo Alto Networks Knowledge Base – HA MAC Address Conflict Resolution
Let me know if you want help verifying current Group IDs or planning a safe HA reconfiguration.

A. Use the Scheduled Config Push to schedule Commit to Panorama and also Push to Devices.

Explanation:
Panorama provides a Scheduled Config Push feature.

With it, you can:
Commit to Panorama (save changes to Panorama’s running config), and
Push to Devices (send the committed Panorama config down to managed firewalls).
You can schedule both actions to happen automatically at a specified time (e.g., end of day).
That exactly matches the requirement: ensure all Panorama configuration is committed and pushed to devices at a certain time.

❌ Why the other options are wrong:
B. Scheduled Config Push + API call
Overcomplicates it. Panorama already supports scheduled commit and push natively—no API scripting needed.
C. Scheduled Config Export + API call
Config Export only saves/exports the config to a file; it doesn’t commit or push to devices. Wrong feature.
D. Scheduled Config Export to commit and push
Same issue—Config Export is about saving, not applying configs.

📖 Reference:
Palo Alto TechDocs – Schedule a Config Push

A. Add SSL and web-browsing applications to the same rule.

Explanation:
In PAN-OS, every application has a set of dependencies and implicit uses. For GlobalProtect, the application:

Depends on SSL
→ must be explicitly allowed in the same rule
Implicitly uses web-browsing
→ does not require explicit allowance, but including it avoids misclassification delays during App-ID identification

To ensure full functionality and proper App-ID resolution, both SSL and web-browsing should be added to the same rule. This guarantees that the firewall can correctly identify and allow GlobalProtect traffic without delay or drop.

❌ Why the Other Options Are Incorrect:
B. Add web-browsing application to the same rule
→ Misses the required SSL dependency. GlobalProtect won’t work without SSL explicitly allowed.
C. Add SSL application to the same rule
→ Misses the implicit web-browsing usage. While technically functional, it may delay App-ID resolution.
D. SSL and web-browsing must both be explicitly allowed
→ Misleading. Only SSL is a dependency; web-browsing is implicitly used and doesn’t require explicit allowance unless you want to optimize App-ID recognition.

Reference:
Palo Alto Networks – What is Application Dependency
PCNSE Dependency Resolution Guide

B. To allow traffic between zones in different virtual systems while the traffic is leaving the appliance

Explanation:
In a multi-virtual system (vsys) environment, each vsys is a separate security domain with its own interfaces, zones, and policies. By design, vsys do not share internal state or have direct internal pathways for traffic. Therefore:
For traffic to flow from a zone in one vsys to a zone in another vsys, it must be routed out of the firewall (e.g., via a physical or VLAN interface) and then back in through another interface.
External zones are configured to represent these "outside" networks (e.g., a transit VLAN) that carry traffic between vsys. They are called "external" because the traffic leaves the physical appliance.
This approach ensures that inter-vsys traffic is subjected to the same security policies (e.g., security, NAT, decryption) as any other traffic traversing the firewall, maintaining security and visibility.

Why the other options are incorrect:
A. To allow traffic between zones in different virtual systems without the traffic leaving the appliance:
This is false. Traffic between vsys must leave the appliance; there is no internal switching between vsys.
C. External zones are required because the same external zone can be used on different virtual systems:
While the same external zone name (e.g., "inter-vsys") can be configured in multiple vsys, this is not the primary reason. The key requirement is the need for traffic to exit and re-enter the firewall.
D. Multiple external zones are required in each virtual system to allow communications between virtual systems:
Only one external zone per vsys is typically needed for inter-vsys communication (e.g., a dedicated "inter-vsys" zone). Multiple zones are not required.

Reference:
Palo Alto Networks Administrator Guide:
The "Virtual Systems" chapter explains that inter-vsys traffic requires external zones because traffic must exit and re-enter the firewall. It details configuring zones for transit networks. PCNSE Exam Blueprint (Domain 1: Architecture and Core Concepts):
Understanding virtual system isolation and inter-vsys communication is a key architectural concept.