C. HTTPS

Explanation:
GlobalProtect Clientless VPN is designed to allow users to securely access internal web applications without installing the GlobalProtect agent. It works by proxying traffic through the firewall using a browser-based interface.

The protocol it natively supports is:
HTTPS — because Clientless VPN is web-based and only proxies web applications that use secure HTTP.
📚 Reference:
Palo Alto Networks – Configure Clientless VPN

❌ Why Other Options Are Wrong:
A. HTP:
Typo — not a valid protocol.
B. SSH:
Not supported natively via Clientless VPN.
D. RDP:
Requires the full GlobalProtect agent or other remote access tools — not supported via Clientless VPN.

D. Novell eDirectory, Microsoft Exchange, and Microsoft Active Directory

Explanation:
When deploying User-ID through server monitoring, Palo Alto Networks supports monitoring login events from several directory service platforms to map users to IP addresses. The supported platforms include:

Microsoft Active Directory (AD):
The most common source for User-ID mapping. The firewall or User-ID agent monitors security event logs on domain controllers to capture login events (e.g., Kerberos ticket grants, logon success).
Microsoft Exchange:
Can be monitored for client access logs, which provide additional user-IP mapping data. Useful when users access email services and AD logs are insufficient.
Novell eDirectory:
Supported via the User-ID agent, which can monitor eDirectory logs for login events. This enables integration in environments using non-Microsoft directory services.
These platforms are explicitly listed in Palo Alto’s User-ID Server Monitoring documentation.

❌ Why the other options are incorrect
A & C (Red Hat Linux):
Linux systems like Red Hat are not directly supported for server monitoring via User-ID. You can use syslog-based methods to collect login events, but not via the server monitoring feature.
B (Microsoft Terminal Server):
Terminal Server support is handled via TS Agent, not server monitoring. It’s a separate mechanism for mapping users in multi-user environments.

B. High Risk

Explanation:
SSL decryption is resource-intensive, so it should be deployed strategically to maximize security ROI. The High Risk category includes sites known for malware, phishing, command-and-control (C2) activity, and other malicious content. Decrypting traffic to these sites first allows the firewall to:
Inspect encrypted threats that would otherwise evade detection.
Block dangerous traffic before it causes harm.
Prioritize limited decryption resources on the highest-risk traffic.
This approach aligns with Palo Alto Networks' best practices for phased decryption rollout, starting with the most critical threats.

Why the other options are incorrect:
A. Online Storage and Backup:
While this category may contain threats, it is not the highest priority. Decrypting storage traffic can raise privacy concerns and may be subject to compliance restrictions. C. Health and Medicine: This category is often sensitive due to privacy regulations (e.g., HIPAA). Decrypting it without careful consideration may violate compliance requirements.
D. Financial Services:
This category is critical for security but often uses certificate pinning or is highly sensitive to user privacy. Decrypting financial traffic can break applications or trigger legal issues if not handled cautiously.

Reference:
Palo Alto Networks Best Practices for SSL Decryption:
Recommends starting decryption with the High Risk category to quickly reduce the attack surface.
PCNSE Exam Blueprint (Domain 3:
Security Policies and Profiles): Understanding decryption strategies and prioritization is key for effective security policy design.

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

B. A private key
D. A certificate authority (CA) certificate

Explanation

🔹1: Recall what a Forward Trust Certificate is
In SSL Forward Proxy, the firewall intercepts TLS sessions, decrypts traffic, and re-signs the server’s certificate with its own Forward Trust Certificate.
For the client to accept this re-signed cert:
The firewall must act as a certificate authority (CA) (so it can generate and sign server certs on the fly).
That certificate must have a private key (so the firewall can actually sign new certs).
Clients must trust this CA (so you import it into browsers/endpoints).

🔹2: Evaluate Options
A. A subject alternative name (SAN)
❌ Not required on the forward trust cert. SANs matter for end-entity server certs, not for the CA signing cert.
B. A private key
✅ Required — without a private key, the firewall cannot dynamically sign certificates.
C. A server certificate
❌ Wrong — it’s not a single server cert; it must be a CA cert used for signing.
D. A certificate authority (CA) certificate
✅ Correct — the forward trust cert must be a CA cert so the firewall can generate child certificates.

🔹 Key Takeaway (PCNSE)
Forward Trust Cert = CA cert + private key → used to sign trusted server certs during SSL Forward Proxy.
Forward Untrust Cert = CA cert + private key → used to re-sign untrusted/invalid server certs.

📖 Reference:
Palo Alto Networks — Configure SSL Forward Proxy

D. Legal compliance regulations and acceptable usage policies

Explanation:
Deploying SSL Forward Proxy (Decryption) is a powerful security measure, but it also has significant legal and privacy implications. The firewall will essentially act as a "Man-in-the-Middle" (MiTM), terminating and inspecting encrypted traffic that users believe is private between their browser and the website.

Before implementing such a technology, it is absolutely critical to review this with leadership and legal counsel for the following reasons:

Legal Compliance: Many regions and countries have strict data privacy laws (such as GDPR, CCPA, etc.) that govern the monitoring of user communications. Intercepting user traffic, even for security purposes, may be restricted or require specific disclosures.

Acceptable Use Policy (AUP): The organization's AUP must explicitly state that network traffic, including encrypted traffic, is subject to monitoring for security and compliance purposes. Employees should be made aware of this practice. Without a clear AUP, decryption could lead to legal challenges from employees.

User Notification: Leadership must decide on a policy for user notification. While often not legally required to obtain individual consent in a corporate environment, it is a best practice to inform users that their traffic is being decrypted and inspected.
Reviewing these points with leadership ensures the deployment is not only technically sound but also legally defensible and aligned with the organization's ethical standards.

Why the other options are incorrect:
A. Browser-supported cipher documentation & B. Cipher documentation supported by the endpoint operating system:
These are important technical considerations for the engineer. They need to ensure the firewall uses ciphers that the clients (browsers and OS) support to avoid breaking legitimate applications. However, these are implementation details that do not require leadership review.

C. URL risk-based category distinctions:
This is a configuration detail for the Decryption policy. An engineer would use URL categories to decide which traffic to decrypt (e.g., decrypt "Financial Services" but not "Healthcare"). This is a technical and policy-configuration decision, not a high-level leadership discussion about legality and user privacy.

Reference:
The Palo Alto Networks Decryption Administrator's Guide and the PCNSE study materials heavily emphasize the legal and privacy considerations as a primary step before deploying decryption. It is a foundational best practice to get organizational buy-in and ensure compliance with local laws.

C. It supports the X-Authenticated-User (XAU) header, which contains the authenticated username in the outgoing request.
D. Explicit proxy allows for easier troubleshooting, since the client browser is aware of the existence of the proxy.

Explanation:
In PAN-OS 11.0, the explicit proxy method offers several operational and diagnostic advantages over the transparent proxy method:

C.XAU header support
Explicit proxy supports the X-Authenticated-User (XAU) header, which embeds the authenticated username in outbound HTTP requests. This enables downstream systems (e.g., logging platforms, web servers) to identify users without relying on IP-based mapping. Transparent proxy does not support XAU headers.
D. Easier troubleshooting
Because the client browser is explicitly configured to use the proxy, it is aware of the proxy’s presence. This makes troubleshooting simpler—errors like proxy authentication failures or unreachable destinations are surfaced directly in the browser, rather than silently intercepted as in transparent mode.

❌ Why the other options are incorrect
A. No client configuration is required for explicit proxy
This is false. Explicit proxy does require client-side configuration (e.g., PAC file, browser settings, or GPO). Transparent proxy is the one that avoids client configuration.
B. Interception of non-standard HTTPS ports
This capability is not exclusive to explicit proxy. Transparent proxy can also intercept non-standard ports if properly configured with DNAT and loopback interfaces. This option is misleading.

🔗 References:
PAN-OS 11.0 Web Proxy Configuration Guide
PCNSE Comparison of Proxy Methods