B. Use the Aggressive timer for faster failover timer settings

Explanation:
Palo Alto Networks firewalls use timers to monitor the health of the HA peers and trigger a failover if a peer is detected as failed. These timers are categorized into three predefined sets:

Recommended:
This is the default timer setting. It provides a balance between detecting failures and avoiding false positives caused by temporary network issues. This is the setting you would use for a typical, stable network environment.
Aggressive:
This setting uses the shortest possible timer values. It is designed to provide the fastest possible failover detection. You would use this in environments where downtime is extremely critical and you need to fail over as quickly as possible, even at the risk of a false failover from a minor network fluctuation.
Critical:
This setting uses a failover threshold that is even more stringent than the Aggressive setting. The timer values are so small that they are only applicable in very specific, high-performance environments and can be prone to false positives if not used carefully.
Moderate:
There is no pre-defined "Moderate" timer setting in the Palo Alto Networks HA configuration. The available options are Recommended, Aggressive, and Critical.

Analysis of the Options
A. Use the Critical timer for faster failover timer settings:
While the Critical timer is fast, the Aggressive timer is the most commonly recommended choice for "faster failover" in a typical setup. The Critical timer is a more specialized, extreme setting.
B. Use the Aggressive timer for faster failover timer settings:
This is the correct statement. The Aggressive timer is specifically designed for environments that require faster failover detection than the default "Recommended" setting.
C. Use the Moderate timer for typical failover timer settings:
This is incorrect. There is no "Moderate" timer. The "Recommended" timer is the one used for typical settings.
D. Use the Recommended timer for faster failover timer settings:
This is incorrect. The Recommended timer is the default and is designed for normal operations, not for fast failover. The Aggressive and Critical timers are the options for faster failover

C. In close proximity to the servers it will be monitoring

Explanation:
An administrator plans to install the Windows User-ID agent on a domain member system to enable user-to-IP mapping on a Palo Alto Networks firewall for identity-based policies. The best practice for choosing the installation location is to place the User-ID agent in close proximity to the servers it will be monitoring, such as domain controllers (DCs) or other systems generating authentication logs (e.g., Windows Security Event Logs). This reduces latency in collecting and processing log data, ensures efficient communication with monitored servers (via WMI or WinRM), and minimizes network overhead. The agent can be installed on a dedicated server or a DC, but proximity to the monitored servers optimizes performance, especially in large or distributed networks.

Why Other Options Are Incorrect:
A. On the same RODC that is used for credential detection:
Installing on a Read-Only Domain Controller (RODC) is not ideal, as RODCs have limited write capabilities and may not support real-time log collection or credential detection effectively. The PCNSE Study Guide advises against RODC placement unless specifically required, and proximity to monitored servers takes precedence.
B. In close proximity to the firewall it will be providing User-ID to:
While proximity to the firewall reduces latency in sending User-ID mappings, the agent’s primary task is collecting data from monitored servers. Network optimization is better served by placing it near the data source, with firewall communication handled via IP connectivity. The PAN-OS 11.1 Administrator’s Guide prioritizes server proximity.
D. On the DC holding the Schema Master FSMO role:
The Schema Master is a critical Flexible Single Master Operation (FSMO) role for AD schema changes, and installing the agent on this DC could impact its performance or availability. Best practice avoids placing additional workloads on FSMO role holders unless necessary. The PCNSE Study Guide recommends a separate system or a less critical DC.

Practical Steps:
Identify the DCs or servers generating authentication logs (e.g., via Windows Event ID 4624).
Select a domain member system (or DC) near these servers, ensuring low-latency network access. Download the User-ID agent from the Palo Alto support portal.
Install the agent, configuring it under Device > User Identification > User-ID Agent.
Add the monitored servers (e.g., via WMI) and set polling intervals.
Commit and verify mappings in Monitor > User-ID > User Mapping.

References:
Palo Alto Networks PAN-OS 11.1 Administrator’s Guide:
Recommends proximity to monitored servers.
Palo Alto Networks PCNSE Study Guide:
Details User-ID agent placement best practices.

B. QoS on the egress interface for the traffic flows
D. A QoS profile defining traffic classes
E. A QoS policy for each application ID

Explanation:
In this scenario, the administrator observes excessive VoIP traffic degrading application performance. To solve this, Quality of Service (QoS) must be implemented properly on the Palo Alto Networks firewall.

Correct Options
B. QoS on the egress interface for the traffic flows
Palo Alto firewalls apply QoS only on the egress interface. This ensures traffic shaping and bandwidth enforcement happen before traffic leaves the firewall.
Without QoS on the egress interface, bandwidth policies cannot take effect.
Reference:
“QoS is enforced only on egress interfaces to limit or guarantee bandwidth for traffic classes.”

D. A QoS profile defining traffic classes
A QoS profile defines how traffic is divided into up to 8 classes.
Each class can specify maximum and guaranteed bandwidth, along with priority levels (real-time, high, medium, low).
Defining a profile is mandatory before applying QoS policies.
Reference:
“The QoS profile specifies the maximum and guaranteed bandwidth for traffic classes that QoS policies reference.”

E. A QoS policy for each application ID
QoS policies classify traffic into the classes defined in the QoS profile.
Policies can match by App-ID, users, zones, or addresses.
This enables assigning VoIP to a high-priority class while limiting its maximum bandwidth to protect other applications.
Reference:
“QoS policies classify traffic into classes based on App-ID, users, or addresses.”

A. A secondary DNS server in the DNS proxy is optional, and configuration commit to the firewall will succeed with only one DNS server.

Explanation:
When configuring DNS Proxy for Explicit Proxy (web proxy), the firewall allows you to specify primary and secondary DNS servers. However, the configuration validation only requires a primary DNS server to be defined. The commit operation will succeed with just one DNS server configured.

Why the other options are incorrect:
B. A maximum of two FQDNs can be mapped to an IP address in the static entries for DNS proxy:
This is false. There is no hard-coded limit on the number of FQDNs that can be mapped to a single IP address in the static entries of the DNS proxy configuration.
C. DNS timeout for web proxy can be configured manually, and it should be set to the highest value possible:
This is incorrect and not a best practice. The DNS timeout value should be set appropriately based on network conditions. Setting it to an excessively high value could cause unnecessary delays in DNS resolution and degrade user experience.
D. Adjust the UDP queries for the DNS proxy to allow both DNS servers to be tried within 20 seconds:
This is misleading. The default behavior of the DNS proxy is to query the primary server first, and if no response is received within the configured timeout (default is 2 seconds), it will try the secondary server. The total time for both attempts is not fixed at 20 seconds; it depends on the configured timeout and number of retries.

Reference:
Palo Alto Networks Administrator Guide:
The "DNS Proxy" section confirms that while multiple DNS servers can be configured for redundancy, only one is required for a valid configuration.
PCNSE Exam Blueprint (Domain 2:
Deployment and Configuration): Understanding DNS proxy configuration for explicit proxy deployments is a key objective within the blueprint.

A. Destination IP addresses of selected unwanted traffic are blocked. *

Explanation:
When you use the log forwarding built-in action with tagging on a Palo Alto Networks firewall, it's designed to automate a response to a security event. The primary purpose of this action is to dynamically add a tag to the destination IP address of unwanted traffic that matches the log forwarding criteria.
This tag is then used to trigger a corresponding policy. The most common use case is to apply a quarantine or block policy. For example, a security policy rule can be configured to block all traffic from a source IP address that has a specific tag (e.g., quarantine).
Therefore, when the "built-in action with tagging" is used, the destination IP address of the traffic is tagged, and this tag can be used by other policies to block traffic to that address.

Why the Other Options are Incorrect:
B. Selected logs are forwarded to the Azure Security Center:
While you can forward logs to Azure Security Center, this is a separate function of a log forwarding profile. The "built-in action" specifically refers to the tagging automation feature, which is not about forwarding to a SIEM.
C and D. Destination/source zones of selected unwanted traffic are blocked:
Zones are static, logical groupings of interfaces. The built-in tagging action applies a dynamic tag to an IP address, which is then used in a policy to block traffic from or to that specific address, not an entire zone.

D. Add the relevant container application when creating cloned rules

Explanation:
When migrating port-based rules to application-based rules with the Policy Optimizer, the goal is to ensure that policies continue to work even if Palo Alto Networks adds new child applications under an existing parent application (e.g., Office365, YouTube, Facebook).
By selecting the container application (sometimes called a parent application), all current and future child apps automatically match the rule. This provides future-proofing because if PAN adds new signatures or sub-applications under that container, the policy will still allow them without manual updates.
At the same time, using a container application ensures that only traffic related to that application family is matched, preventing unrelated traffic from being permitted.

❌ Why the other options are incorrect:
A. Create a custom application and define it by ports
This defeats the purpose of migrating to App-ID. It would revert to port-based logic and won’t adapt to new applications.
B. Create an application filter based on category and risk
Application filters are too broad. They could unintentionally allow unrelated applications within the same category/risk level. Not precise enough for the requirement.
C. Add specific applications that are seen when creating cloned rules
This works only for currently observed applications, but it won’t cover future child applications. You’d need to update rules manually each time Palo Alto adds a new sub-application.

📖 Reference
Palo Alto Networks Documentation – Policy Optimizer:
“When possible, use container applications instead of individual applications to ensure the policy is future-proof and continues to match when new child applications are added.”

B. Telemetry data is uploaded into Strata Logging Service.
D. Telemetry data is shared in real time with Palo Alto Networks.

Explanation:

What Device Telemetry Does:
Device Telemetry in PAN-OS allows Palo Alto Networks to collect information from firewalls to improve product reliability, threat prevention, and customer support.
Data types include device health, configuration usage, feature adoption, threat samples, and system statistics.

Privacy/Security Consideration:
Since the data goes outside the company’s infrastructure, an organization must ensure compliance with local data privacy and data storage laws (e.g., GDPR in EU).

Option Review
A. Telemetry feature is automatically enabled during PAN-OS installation. ❌
→ False. By default, Device Telemetry is disabled. It must be explicitly enabled by an administrator.
B. Telemetry data is uploaded into Strata Logging Service. ✅
→ Correct. Data is stored in Palo Alto’s Strata Logging Service (SLS), which may be hosted in specific regions (e.g., US, EU). If regulations restrict data export, the company must review this.
C. Telemetry feature is using Traffic logs and packet captures to collect data. ❌
→ Incorrect. Device Telemetry does not use packet captures or forward raw traffic logs. It collects metadata/statistics/configuration health only.
D. Telemetry data is shared in real time with Palo Alto Networks. ✅
→ Correct. Because telemetry data is streamed to PAN in near-real time, companies under strict privacy laws must confirm whether this sharing complies with legal requirements.

Reference:
Palo Alto Networks TechDocs – About Device Telemetry
Palo Alto KB – Device Telemetry FAQ