NGFW-ENGINEER Practice Questions

Ansible's primary function in managing Palo Alto Networks NGFWs is to automate configuration and operational tasks. It uses YAML-based playbooks to define the desired state of the firewall, enabling administrators to programmatically push policy updates, manage network objects, and configure system settings. This "Infrastructure as Code" approach is especially valuable in hybrid cloud environments, as it ensures consistent and repeatable configurations across both on-premises and cloud-based firewalls, reducing manual errors and increasing operational agility.

A. Ansible is a command-line automation engine, not a web interface. Web-based management is provided by Panorama or the firewall's native GUI.

B. Centralized logging is a function of tools like Panorama, Cortex Data Lake, or a Security Information and Event Management (SIEM) system, not Ansible.

C. The NGFW itself manages dynamic updates for threat databases by connecting directly to Palo Alto Networks' update services, a process independent of Ansible.

1. Palo Alto Networks Official Documentation: The "Ansible for PAN-OS" documentation explicitly states its purpose: "The PAN-OS Ansible collection allows you to automate the configuration and operational tasks for Palo Alto Networks next-generation firewalls." This includes managing policies

objects

and device settings.

Source: Palo Alto Networks

"Ansible for PAN-OS

" Developer Documentation. (Refer to the introduction and module descriptions for panossecurityrule

panosaddressobject

etc.). Available at: https://paloaltonetworks.github.io/pan-os-ansible/

2. Ansible by Red Hat Official Documentation: The documentation for the paloaltonetworks.panos collection details its use for configuration management. It describes modules for tasks such as configuring security rules

NAT policies

and network interfaces

all executed via playbooks.

Source: Ansible Documentation

"paloaltonetworks.panos collection." (Refer to the collection overview and module index). Available at: https://docs.ansible.com/ansible/latest/collections/paloaltonetworks/panos/index.html

3. Palo Alto Networks Technical Documentation: The PAN-OS Administrator's Guide discusses automation capabilities and often references the REST API

which is the underlying mechanism that the Ansible modules use to programmatically configure the firewall.

Source: Palo Alto Networks

"PAN-OS® Administrator’s Guide

" Version 10.2

Chapter: "Automated Correlation Engine." (While not directly about Ansible

it describes the API framework that enables such automation tools).

Palo Alto Networks documents list the only hardware platforms that can enable the Advanced Routing Engine (ARE): PA-3200, PA-5200, PA-5400, PA-5450, PA-400, PA-800, VM-Series and CN-Series firewalls.

Option C contains four models that fall wholly inside those supported families—PA-3260 (PA-3200 series), PA-5410 (PA-5400 series), PA-850 (PA-800 series) and PA-460 (PA-400 series)—so every model in the option is eligible for ARE. All other answer sets include at least one platform explicitly excluded from support, making them invalid.

A. PA-7080 belongs to the PA-7000 series, which documentation states is not supported for ARE.

B. “PA-455” and “PA-1410” are either non-existent or outside the listed PA-400/800/5400 families that support ARE.

D. PA-7050 (PA-7000 series) is not supported for ARE; therefore the whole set is invalid despite other valid models.

1. Palo Alto Networks

“PAN-OS 11.0 Advanced Routing Administrator’s Guide

” Table ‘Supported Platforms for Advanced Routing

’ p. 7.

2. Palo Alto Networks

“PAN-OS 11.0 Release Notes

” section ‘Advanced Routing Engine Support by Model

’ pp. 36-37.

3. Palo Alto Networks TechDocs

“Advanced Routing > System Requirements

” https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/advanced-routing/advanced-routing-engine/advanced-routing-overview (accessed 2025-11-06).

Palo Alto Networks firewalls enforce security policies based on traffic moving between security zones. For an IPSec tunnel, two distinct types of traffic must be considered: the control plane traffic (IKE, ESP) that builds the tunnel, and the data plane traffic that passes through it.

The data plane traffic, which is the user data being protected, typically travels between an internal zone (e.g., trust) and the zone containing the tunnel interface (e.g., a dedicated vpn zone or the untrust zone). Because this traffic crosses zones, it is subject to the interzone-default security rule, which has a default action of deny. Therefore, explicit security rules must be created to allow this traffic. To permit sessions to be initiated from both sides of the tunnel, separate, directional rules are required.

A. A single security rule is directional and only allows traffic initiation from the specified source zone to the destination zone. A second rule is required for return-initiated traffic.

B. The firewall's control plane implicitly allows IKE and ESP packets destined for the firewall itself to establish the tunnel; they are not processed against the intrazone-default allow policy for this purpose.

1. Palo Alto Networks PAN-OS® Administrator's Guide 10.2

"Security Policy

" Page 1031. The guide describes the two default security rules: intrazone-default (allow) and interzone-default (deny). This supports the principle that traffic between zones

such as from a trust zone to a vpn zone

is denied by default

which is the concept behind option D.

2. Palo Alto Networks PAN-OS® Administrator's Guide 10.2

"Define Security Policy for the IPSec Tunnel

" Page 588. This section explicitly states

"To allow traffic to flow through the VPN tunnel

you must configure a security policy rule." The examples provided consistently show separate rules for allowing traffic in each direction (e.g.

from LAN to VPN

and from VPN to LAN)

which directly supports option C.

3. Palo Alto Networks PAN-OS® Administrator's Guide 10.2

"How Does the Firewall Process IPSec Packets?

" Page 554. This section clarifies

"The firewall allows IKE and IPSec traffic to and from the interfaces that are configured as IPSec tunnel endpoints; you do not need to create Security policy rules to allow this traffic." This directly refutes the premise of option B.

In a Palo Alto Networks multi-VSYS environment, traffic cannot pass between virtual systems unless they are explicitly configured to be visible to one another. This is a fundamental security and administrative control. Even with correctly configured external zones, virtual routers, inter-VR static routes, and security policies, the data plane will not forward packets between the VSYS contexts if this visibility is not established. The "Visible Vsys" configuration creates the necessary logical link that allows one VSYS to recognize another as a valid destination for traffic.

A. A transit VSYS is a valid network design for centralizing services, but it is not a mandatory requirement for direct inter-VSYS communication.

C. The zone type "External" is what designates it for inter-VSYS traffic; there is no separate "allow inter-VSYS traffic" checkbox within the zone configuration itself.

D. Security policies are processed within the context of each VSYS. The question states policies are already in place to allow traffic to the external zones within each respective VSYS.

1. Palo Alto Networks PAN-OS® Administrator’s Guide 10.2

"Virtual Systems

" section "Configure Inter-VSYS Routing." The guide outlines the required steps

stating explicitly in Step 5: "For traffic to pass between virtual systems

you must make each virtual system visible to the other. Select a virtual system and in the Visible Vsys field

Add the virtual systems that you want to be able to exchange traffic with the selected virtual system." (p. 1098).

2. Palo Alto Networks PAN-OS® Administrator’s Guide 10.2

"Virtual Systems

" section "Inter-VSYS Traffic." This section details the traffic flow

which depends on the VSYS visibility setting. It explains

"When the firewall receives a packet

it performs a route lookup to determine the egress interface and zone. If the egress interface belongs to another virtual system

the firewall forwards the packet to that virtual system for policy evaluation..." This forwarding action is contingent on the visibility being configured. (p. 1096).

The recommended procedure for upgrading an active/passive High Availability (HA) pair with minimal service disruption is a sequential process that leverages the HA failover mechanism. The process begins by suspending the currently active firewall, which triggers a graceful, controlled failover to the passive peer. Once the passive peer takes over the active role and is handling traffic, the now-passive (originally active) firewall can be safely upgraded and rebooted. After verifying its operation, a second controlled failover is performed to make the newly upgraded firewall active. Finally, the remaining firewall is upgraded. This method ensures that one firewall is always online and processing traffic, limiting downtime to the brief transition period during each failover.

B: Shutting down the active firewall is a hard stop, not a graceful failover, and is more disruptive than suspending the device for a controlled transition.

C: Isolating and upgrading both firewalls offline causes a complete service outage, which is the opposite of minimizing disruption in a highly sensitive environment.

D: Upgrading and rebooting both firewalls simultaneously guarantees a total network outage, as both devices would be unavailable at the same time, defeating the purpose of HA.

1. Palo Alto Networks PAN-OS® Administrator’s Guide 11.0: In the section "Upgrade the Firewalls in an HA Pair

" the official documentation outlines the precise procedure. Step 3 explicitly states

"Suspend the active firewall to trigger a failover to the passive firewall." The subsequent steps detail upgrading the now-passive device

followed by failing over again to upgrade the second device. This directly supports the methodology described in option A.

Reference: Palo Alto Networks. (2023). PAN-OS® Administrator’s Guide 11.0. Section: Device > High Availability > Upgrade the Firewalls in an HA Pair.

2. Palo Alto Networks Knowledge Base

Document ID 211309: This best-practice article

"How to Upgrade an HA Pair

" details the step-by-step process. It advises

"On the currently active firewall

suspend the local device to cause a failover... After the failover is complete

the previously active firewall is now the passive firewall. Reboot the passive firewall to complete the upgrade." This confirms that suspending the active unit to initiate a failover is the correct first operational step for a minimal-downtime upgrade.

When a Palo Alto Networks firewall performs SSL Forward Proxy decryption, it acts as a man-in-the-middle, decrypting traffic, inspecting it, and then re-encrypting it with a new certificate. This new certificate is signed by a Certificate Authority (CA) certificate residing on the firewall. For client browsers to accept this re-encrypted traffic without generating security warnings, they must trust this firewall CA. Therefore, a mandatory implementation step is to export the public key of the firewall's CA certificate (in this case, the self-signed root CA) and import it into the trusted root certificate store of all client devices that will have their traffic decrypted.

B. Certificates are used for identity and encryption, not for network routing decisions. The concept of a "default routing certificate" is not applicable in this context.

C. Issuing certificates with indefinite validity is a significant security risk and violates certificate lifecycle best practices. All certificates should have a defined expiration date.

D. This is an operational deployment strategy to manage user impact, not a required technical configuration step for implementing the certificate itself. Decryption can be enabled once the CA is trusted by clients.

1. Palo Alto Networks TechDocs

"Configure SSL Forward Proxy": "To ensure that browsers trust the firewall as a CA

you must install the certificate that the firewall uses to sign decrypted traffic in the trust store of each client browser. You can deploy the certificate to browsers using Group Policy Object (GPO)

Apple profiles

or GlobalProtect." This statement directly confirms that distributing the CA certificate to client trust stores is a required step. (Reference: PAN-OS® Administrator's Guide > Objects > Decryption > Configure SSL Forward Proxy)

2. Palo Alto Networks TechDocs

"Keys and Certificates for Decryption Policies": "For SSL Forward Proxy decryption

the firewall uses a forward trust certificate to sign the server certificates that it presents to clients... For clients to trust the certificates that the firewall generates

you must install the forward trust certificate in the client’s browser as a trusted root CA." This reinforces the necessity of installing the CA certificate on client devices. (Reference: PAN-OS® Administrator's Guide > Objects > Decryption > Keys and Certificates for Decryption Policies)

3. Palo Alto Networks TechDocs

"Generate a Self-Signed Root CA Certificate": This document outlines the process of creating the self-signed certificate on the firewall and explicitly notes its purpose for features like SSL Forward Proxy

which presupposes its distribution to clients for trust to be established. (Reference: PAN-OS® Administrator's Guide > Device > Certificate Management > Generate a Self-Signed Root CA Certificate)

In cloud service provider (CSP) environments, the standard and recommended method for achieving high availability (HA) across multiple availability zones (AZs) is to use a native cloud load balancer. The load balancer distributes traffic to multiple Palo Alto Networks NGFW instances, each located in a different AZ. It uses health probes to continuously monitor the status of each firewall. If a firewall instance or an entire AZ fails, the health probe detects the failure, and the load balancer automatically stops sending traffic to the unhealthy instance, redirecting it to the remaining healthy firewalls in other AZs. This architecture provides seamless failover and resilience.

A. Deploying Ansible scripts for zone-specific scaling: Ansible is an automation tool used for configuration and deployment, not the architectural mechanism that provides high availability and failover.

B. Implementing Terraform templates for redundancy within one availability zone: This option is incorrect because the question explicitly requires a solution for HA across multiple availability zones, not within a single one.

D. Configuring active/active HA: Traditional Palo Alto Networks active/active HA relies on Layer 2 connectivity for state synchronization, which is not available across different cloud availability zones. Cloud HA architectures depend on load balancers.

1. Palo Alto Networks - VM-Series on AWS Reference Architecture Guide: "To provide high availability for the VM-Series firewalls

you deploy an active/active pair of firewalls that are fronted by an Elastic Load Balancer (ELB). The ELB distributes traffic between the firewalls and provides health checks to ensure that traffic is only sent to a healthy firewall." (Section: Security VPC with an Internet Gateway

subsection: High Availability)

2. Palo Alto Networks - VM-Series on Azure Deployment Guide: "For high availability and resiliency

you can deploy the VM-Series firewalls in an active/active configuration across multiple availability zones. The Azure Load Balancer distributes sessions between the firewalls and uses health probes to detect firewall failure." (Chapter: VM-Series Firewall for Azure Reference Architecture

Section: High Availability for the VM-Series Firewall on Azure)

3. Palo Alto Networks - High Availability for VM-Series Firewall on AWS: "The VM-Series firewall on AWS supports high availability (HA) between instances deployed in different Availability Zones (AZs). This solution uses AWS services such as Elastic Load Balancing (ELB)

Lambda

and S3 to provide a resilient firewall solution." (Document ID: 86453

Section: Overview)

When configuring a Palo Alto Networks NGFW, a security zone's type dictates the kind of interfaces it can contain and its operational mode. A Tunnel zone is a valid type used to group one or more tunnel interfaces, enabling the application of security policy to traffic traversing VPNs (e.g., IPSec, GRE). A Virtual Wire zone is another valid type used for transparent, "bump-in-the-wire" deployments. It contains a pair of virtual wire interfaces, allowing the firewall to inspect traffic passing through it without being a routed hop.

B. Intrazone: This describes a traffic flow direction (within the same zone), which is used in security policy rules, not a configurable zone type.

C. Internal: This is a common user-defined name for a zone (e.g., "internal-lan," "trust"), not a predefined functional type of zone.

1. Palo Alto Networks. (2023). PAN-OS® Administrator’s Guide

Version 11.0. "Objects > Zones". In the section "Configure a Security Zone

" the guide details the "Type" drop-down menu

which includes Tunnel and Virtual Wire as selectable options.

2. Palo Alto Networks. (2023). PAN-OS® Administrator’s Guide

Version 11.0. "Security Zone Overview". This document explicitly lists the available zone types: Tap

Virtual Wire

Layer 2

Layer 3

Tunnel

and External. This list confirms that 'Tunnel' and 'Virtual Wire' are valid types

while 'Intrazone' and 'Internal' are not.

3. Palo Alto Networks. (2023). PAN-OS® Administrator’s Guide

Version 11.0. "Security Policy". This section clarifies that "intrazone" refers to traffic where the source and destination zones are the same

distinguishing it as a policy concept rather than a zone type.

The most reliable method for mapping users to IP addresses in PAN-OS is GlobalProtect. The GlobalProtect agent is installed directly on the user's endpoint device. It maintains a persistent connection to the firewall, providing real-time, accurate user and device information. Because the information comes directly from the source (the endpoint), it is not subject to the polling delays, network connectivity issues to third-party servers, or log parsing errors that can affect other methods like server monitoring or syslog analysis. This direct reporting mechanism makes it the most dependable source for User-ID.

A. Port mapping: This is a specialized method for multi-user environments like Terminal Services or Citrix and is not a universally applicable or the most reliable general method.

C. Syslog: This method's reliability depends on parsing log messages from external systems. It is prone to failure if log formats change, messages are dropped, or parsing fails.

D. Server monitoring: While a very common and robust method, it is indirect. It relies on polling server security logs, which can introduce latency and is dependent on network connectivity and permissions to the monitored servers.

1. Palo Alto Networks. (2023). PAN-OS® Administrator’s Guide

Version 11.0. "User-ID Concepts" section

under "Methods for Mapping Users to IP Addresses". The guide states

"The most reliable source of user-to-IP-address mapping is the GlobalProtect app

which is installed on the endpoint and sends the user and IP address information directly to the firewall."

2. Palo Alto Networks. (2023). GlobalProtect™ Administrator’s Guide

Version 11.0. "What is GlobalProtect?" section. The document explains that the agent on the endpoint collects and reports host information

including the user

directly to the firewall

reinforcing the reliability of this direct data source for User-ID.

3. Palo Alto Networks. (2021). User-ID™ Agent Administrator's Guide

Version 10.1. "User-ID Agent Deployment Scenarios" section. This guide describes server monitoring as a primary method but implicitly highlights its indirect nature (polling logs) compared to an agent that resides on the endpoint itself

which provides a more direct and thus more reliable data feed.

To allow both SAML and RADIUS administrator authentication to function concurrently, a PAN-OS feature called an Authentication Sequence must be used. This involves two primary actions:

1. Creating the new authentication components for SAML. This requires creating a SAML Identity Provider Server Profile and then creating an Authentication Profile that uses, or "applies," this server profile to it.

2. Creating an Authentication Sequence that lists both the new SAML Authentication Profile and the existing RADIUS Authentication Profile.

This sequence allows the firewall to try authenticating an administrator against one profile (e.g., SAML) and, if that fails or is unavailable, try the next profile in the sequence (e.g., RADIUS). This configuration is then applied to the firewall's administrator authentication settings.

A. Create a testing and rollback plan for the transition from Radius to SAML, as the two authentication profiles cannot be run in tandem.

This is factually incorrect. The Authentication Sequence feature in PAN-OS is specifically designed to allow multiple authentication profiles to be used in tandem.

D. Create and add the “SAML Identity Provider” Server Profile to the authentication profile for the “RADIUS” Server Profile.

This describes a technically impossible action. An Authentication Profile can only reference one Server Profile or one Authentication Sequence; you cannot add a Server Profile to another.

1. Palo Alto Networks PAN-OS® Administrator’s Guide 10.2

"Configure an Authentication Sequence". Device > Authentication Sequence. This section states

"An authentication sequence allows you to try multiple authentication profiles in a specific order... For example

you can create an authentication sequence that first attempts to authenticate users against a Kerberos server. If the Kerberos server is unreachable

the firewall then attempts to authenticate users against an LDAP server

and so on." This directly supports the use of a sequence for the RADIUS and SAML profiles.

2. Palo Alto Networks PAN-OS® Administrator’s Guide 10.2

"Configure an Authentication Profile and Sequence". Device > Authentication Profile. This guide details the process: "Create an Authentication profile for each authentication service that you plan to use... Create an Authentication Sequence that includes the Authentication profiles you created... Apply the Authentication Sequence to a firewall service." This confirms that creating the SAML authentication profile (Option C) and the sequence (Option B) are the correct

distinct actions.

3. Palo Alto Networks PAN-OS® Administrator’s Guide 10.2

"Configure SAML Authentication". Device > Server Profiles > SAML Identity Provider. This section outlines the creation of the SAML IdP Server Profile

which is then selected within an Authentication Profile

confirming the action described in Option C.