This domain covers initial firewall deployment and day-to-day configuration on PAN-OS: zones, interfaces, virtual routers, security and NAT policy, URL filtering, and redundancy. Questions present real topologies (DMZ web server, branch office, outbound internet) and ask you to choose the correct policy, interface mode, or high-availability design to satisfy the stated requirement.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member
20 questionsDomain: Deploy and Configure Firewalls
Be able to build a working policy set: define zones and interfaces, write security and NAT rules that match real traffic, attach URL Filtering profiles, and design HA or redundant egress. The single most important thing is getting zone, address, and NAT matching correct so traffic is actually allowed and translated.
Security policy rule order and zone-based matching from Untrust to DMZ
NAT policy for inbound destination translation and outbound source translation
Interface types and modes: L3, L2, virtual wire, tap, and subinterfaces
High availability, virtual router redundancy, and policy-based forwarding for outbound redundancy
Watch out for
Common Deploy and Configure Firewalls exam traps
▸Assuming a security policy alone permits inbound traffic; the matching NAT rule and destination zone must also be correct.
▸Forgetting that URL filtering requires the traffic to match a security policy with a URL Filtering profile attached.
▸Confusing active/passive HA with active/active, or missing that redundant paths need separate virtual routers or PBF.
Practice set
Deploy and Configure Firewalls questions
20 questions · select your answer, then reveal the explanation
A company is deploying a new firewall in active/passive high availability. The two firewalls are connected directly via the HA1 and HA2 interfaces. After configuration, the passive firewall shows 'HA state: passive' but the active firewall shows 'HA state: non-functional'. What is the most likely cause?
Trap 1: The HA1 link is down or misconfigured.
HA1 is for heartbeat; if down, the firewalls would not form a pair.
Trap 2: The HA2 link is being used for management traffic.
HA2 should be dedicated for synchronization; management traffic should not be sent over it.
Trap 3: The preemptive setting is enabled on both firewalls.
Preemption determines which firewall becomes active; it does not cause a non-functional state.
An administrator configures a firewall with two virtual routers: VR1 and VR2. VR1 connects to the corporate network and VR2 to an ISP. The administrator creates a static route in VR1 to reach the internet via a next hop of 10.0.0.1, but traffic from VR1 to the internet fails. What is the most likely cause?
Trap 1: The firewall does not support multiple virtual routers.
Palo Alto firewalls do support multiple virtual routers.
Trap 2: The virtual routers are not connected to each other.
They can be connected via a shared interface or redistribution.
Trap 3: NAT is not configured on VR2.
NAT is not required for routing; it is for address translation.
You are deploying a pair of PA-5250 firewalls in active/passive HA mode for a large enterprise. The firewalls are configured with multiple virtual routers (VRs) to segment traffic: VR-A for internal corporate network, VR-B for DMZ, and VR-C for Internet edge. Each VR is associated with a separate Vsys. The HA pair uses IPsec tunnel monitoring to determine failover. The customer reports that after a recent configuration change, failover does not occur when the primary firewall's Internet-facing interface (ethernet1/1) goes down. You verify that the primary firewall detects the interface failure, but the secondary does not take over. The HA configuration shows: 'monitor failure only' set to 'link-status', 'monitor hold time' 1000ms, 'promotion hold time' 2000ms, and 'monitor failure condition' is 'any'. The IPsec tunnel monitoring is configured for tunnel to a remote site. The path monitoring includes the Internet-facing interface under VR-C. What is the most likely reason for the failover failure?
Trap 1: The use of multiple virtual routers prevents HA from monitoring…
HA monitoring is per-Vsys and can monitor interfaces in different VRs within the same Vsys.
Trap 2: The 'monitor hold time' is too short, causing flapping to be…
1000ms is a standard value and would not prevent failover detection.
Trap 3: The 'monitor failure only' is set to 'link-status' instead of…
While path monitoring is more comprehensive, link-status should still trigger failover for a direct interface failure.
A company has deployed two PA-5250 firewalls in an active/passive high-availability pair. The passive firewall shows the status 'non-functional' after a reboot. The active firewall is still passing traffic. The administrator checks the HA configuration and sees that the preemptive setting is enabled on both firewalls. What is the most likely cause of the passive firewall showing 'non-functional'?
Trap 1: The preemptive setting is causing the passive firewall to remain in…
The preemptive setting does not cause the passive firewall to remain in a non-functional state; it only determines whether a higher-priority device will take over after a failover.
Trap 2: The HA2 keepalive timer has expired.
The HA2 keepalive timer is used for session synchronization; its expiration affects data plane synchronization but does not directly cause the passive to show as 'non-functional'.
Trap 3: The management port (MGT) on the passive firewall is down or…
The management port (MGT) is not part of the HA control link in default deployments, so its status does not affect HA functional state.
The preemptive setting is causing the passive firewall to remain in non-functional state until a failover occurs.
Why it fails: The preemptive setting does not cause the passive firewall to remain in a non-functional state; it only determines whether a higher-priority device will take over after a failover.
B
The HA2 keepalive timer has expired.
Why it fails: The HA2 keepalive timer is used for session synchronization; its expiration affects data plane synchronization but does not directly cause the passive to show as 'non-functional'.
C
The management port (MGT) on the passive firewall is down or unplugged.
Why it fails: The management port (MGT) is not part of the HA control link in default deployments, so its status does not affect HA functional state.
D
The hello interval on the passive firewall is set to a different value than on the active firewall.
HA peers must share identical hello and hold interval values; a mismatch prevents the passive device from forming the HA control link, so it reports non-functional. Preemption is irrelevant here, and the differing hello interval directly explains the failure.
A security engineer is deploying a Palo Alto Networks firewall in a branch office. The firewall must enforce the following security policies: (1) Allow outbound HTTPS traffic from internal users to the internet. (2) Block all inbound traffic from the internet to the internal network except for SMTP traffic to a specific mail server. (3) Allow outbound DNS traffic from internal DNS servers to external DNS servers. Which TWO security rules should the engineer create to satisfy these requirements? (Choose two.)
Trap 1: Rule: from internal to external, source any, destination any,…
Using service instead of application may allow non-HTTPS traffic on port 443.
Trap 2: Rule: from internal to external, source any, destination any,…
Overly permissive; allows all outbound traffic.
Trap 3: Rule: from internal to external, source any, destination any,…
Allows all web-browsing including HTTP, but requirement is only HTTPS.
Rule: from internal to external, source any, destination any, application any, service tcp/443, action allow.
Why it fails: Using service instead of application may allow non-HTTPS traffic on port 443.
B
Rule: from internal to external, source internal-users, destination any, application ssl, service application-default, action allow.
Permitting internal users outbound HTTPS satisfies requirement one: the ssl application is identified by App-ID regardless of port, and application-default restricts the service to TCP 443. Source zone internal and destination zone external match the traffic path, so the firewall enforces the stated outbound policy without opening inbound access.
C
Rule: from external to internal, source any, destination mail-server-ip, application smtp, service application-default, action allow.
Permitting SMTP from the untrust zone to the mail server's IP satisfies requirement two, which blocks all inbound internet traffic except mail delivery. Specifying application smtp with service application-default restricts the rule to TCP port 25, so no other inbound services reach the internal network.
D
Rule: from internal to external, source any, destination any, application any, service any, action allow.
Why it fails: Overly permissive; allows all outbound traffic.
E
Rule: from internal to external, source any, destination any, application web-browsing, service application-default, action allow.
Why it fails: Allows all web-browsing including HTTP, but requirement is only HTTPS.
Refer to the exhibit. An administrator is troubleshooting traffic from a host at 10.2.2.10 to a server at 10.3.3.10. The firewall has a security rule allowing the traffic. However, traffic is failing. Based on the routing table, what is the most likely cause?
Exhibit
Refer to the exhibit.
admin@PA-5250> show routing route
IPv4 Route Table for virtual-router default
destination nexthop metric flags interface age
0.0.0.0/0 10.1.1.1 10 A S ethernet1/1 5m
10.1.1.0/24 10.1.1.100 0 A C ethernet1/1 5m
10.2.2.0/24 10.1.1.200 1 A S ethernet1/1 5m
10.3.3.0/24 10.1.1.200 1 A S ethernet1/1 5m
Trap 1: The destination network 10.3.3.0/24 is not in the routing table.
10.3.3.0/24 is present.
Trap 2: The source network 10.2.2.0/24 is not in the routing table.
The next hop 10.1.1.200 for the destination 10.3.3.0/24 is unreachable.
The route to 10.3.3.0/24 points via next hop 10.1.1.200, which is not reachable through any connected interface in the routing table. Palo Alto firewalls drop traffic when the resolved next hop is unreachable, so the security rule never matches. This satisfies the stem's constraint that routing, not policy, causes the failure.
B
The destination network 10.3.3.0/24 is not in the routing table.
Why it fails: 10.3.3.0/24 is present.
C
The source network 10.2.2.0/24 is not in the routing table.
Why it fails: 10.2.2.0/24 is present with next hop 10.1.1.200.
Order the steps to configure an IPsec VPN tunnel between two Palo Alto firewalls.
Drag or tap steps into the slots.
Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5
Trap 1: Configure Tunnel Interface, then IKE Gateway, then IPsec Crypto…
Creating the tunnel interface before the IKE gateway and crypto profile is incorrect because the tunnel interface requires IPsec parameters that are defined later; moreover, the IKE gateway must exist before the tunnel can be established.
Trap 2: Configure Security Policy, then IKE Gateway, then IPsec Crypto…
Security policies cannot reference a tunnel interface that hasn't been created yet, and they are applied after the tunnel is established; also, IKE and crypto profiles must be configured before the tunnel interface.
Trap 3: Configure IKE Gateway, then Tunnel Interface, then IPsec Crypto…
The IPsec crypto profile should be configured before the tunnel interface because the tunnel interface uses the crypto profile's parameters; placing it after the tunnel interface may cause the tunnel to fail during configuration.
Configure IKE Gateway, then IPsec Crypto Profile, then Tunnel Interface, then Security Policy
This order follows the logical dependency: IKE negotiation (Phase 1) must be configured first, then Phase 2 parameters via the crypto profile, then the tunnel interface for traffic, and finally security policies to permit traffic through the tunnel.
B
Configure Tunnel Interface, then IKE Gateway, then IPsec Crypto Profile, then Security Policy
Why it fails: Creating the tunnel interface before the IKE gateway and crypto profile is incorrect because the tunnel interface requires IPsec parameters that are defined later; moreover, the IKE gateway must exist before the tunnel can be established.
C
Configure Security Policy, then IKE Gateway, then IPsec Crypto Profile, then Tunnel Interface
Why it fails: Security policies cannot reference a tunnel interface that hasn't been created yet, and they are applied after the tunnel is established; also, IKE and crypto profiles must be configured before the tunnel interface.
D
Configure IKE Gateway, then Tunnel Interface, then IPsec Crypto Profile, then Security Policy
Why it fails: The IPsec crypto profile should be configured before the tunnel interface because the tunnel interface uses the crypto profile's parameters; placing it after the tunnel interface may cause the tunnel to fail during configuration.
What is the most likely reason the traffic from 192.168.1.100 to 203.0.113.50 is being denied?
Exhibit
Refer to the exhibit.
Time,Source,Destination,Application,Action,Rule
2024-05-01 10:00:00,192.168.1.100,203.0.113.50,ssl,deny,default-deny
Trap 1: The session ended with TCP FIN, causing the firewall to deny.
A TCP FIN closes an established session cleanly; it does not cause the firewall to deny the initial connection attempt. Session teardown is expected behaviour, and this would only be relevant if the question concerned logging or session ageing rather than why a new flow was blocked.
Trap 2: The destination IP is blacklisted.
A blacklist entry blocks traffic by matching the destination address in a deny rule, but the stem gives no evidence of such an entry existing; the deny is more likely a security policy rule evaluation. Blacklists are used to block known-malicious external hosts, not to explain an internal-to-external flow denial.
Trap 3: The security rule 'default-deny' explicitly blocks this traffic.
An explicit default-deny rule is a catch-all at the bottom of the rulebase; traffic matching a specific deny rule above it would be blocked by that rule, and the stem gives no evidence of which rule matched. Default-deny explains blocks only when no permissive rule matches.
The application 'ssl' is not allowed in any security rule.
Firewall policy evaluates the application identified by App-ID; if no security rule permits the ssl application for that source-destination pair, the session matches the implicit deny and is dropped. The denial therefore stems from absent application allowlisting.
B
The session ended with TCP FIN, causing the firewall to deny.
Why it fails: A TCP FIN closes an established session cleanly; it does not cause the firewall to deny the initial connection attempt. Session teardown is expected behaviour, and this would only be relevant if the question concerned logging or session ageing rather than why a new flow was blocked.
C
The destination IP is blacklisted.
Why it fails: A blacklist entry blocks traffic by matching the destination address in a deny rule, but the stem gives no evidence of such an entry existing; the deny is more likely a security policy rule evaluation. Blacklists are used to block known-malicious external hosts, not to explain an internal-to-external flow denial.
D
The security rule 'default-deny' explicitly blocks this traffic.
Why it fails: An explicit default-deny rule is a catch-all at the bottom of the rulebase; traffic matching a specific deny rule above it would be blocked by that rule, and the stem gives no evidence of which rule matched. Default-deny explains blocks only when no permissive rule matches.
In a Panorama-managed deployment, the device group has a rule called 'Allow-Web' that allows 'web-browsing'. The local firewall also has a rule with the same name and content. After Panorama pushes the device group configuration, what happens to the local rule?
Trap 1: The local rule is overwritten by the device group rule.
It is not overwritten; the device group rule supersedes it.
Trap 2: The local rule is deleted.
The local rule remains in the configuration but is not active.
Trap 3: The rules are merged into a single rule.
There is no merge; only the device group rule is active.
Both rules are present; the device group rule takes precedence and the local rule is not installed.
Panorama's device group push replaces any local rule sharing the same name, so the local 'Allow-Web' entry is overwritten rather than duplicated. Only the Panorama-managed rule is installed in the running configuration, satisfying the stem's constraint that both rules have identical names and content.
B
The local rule is overwritten by the device group rule.
Why it fails: It is not overwritten; the device group rule supersedes it.
C
The local rule is deleted.
Why it fails: The local rule remains in the configuration but is not active.
D
The rules are merged into a single rule.
Why it fails: There is no merge; only the device group rule is active.
Why it fails: FIPS mode is optional and not a prerequisite for User-ID.
B
The interface must be in a zone.
Why it fails: This is a general network requirement, not specific to User-ID.
C
A User-ID agent must be installed.
User-ID requires an agent to map IP addresses to usernames, either a Windows-based User-ID agent or the firewall's integrated agent, so identity data can be collected. Without this mapping source, the firewall cannot associate traffic with users, satisfying the prerequisite for interface configuration.
D
User-ID must be enabled on the zone.
User-ID operates at zone level, so it must be enabled on the zone containing the interface before identity mapping functions. This satisfies the prerequisite because the firewall only performs user mapping on traffic entering zones where User-ID is explicitly activated.
E
An authentication profile must be configured.
Why it fails: Authentication profiles are used for specific authentication methods, but not mandatory for all User-ID setups.
A company has a firewall with multiple virtual routers. They need to ensure that traffic from a specific subnet (10.1.1.0/24) can reach the internet but not other internal subnets. What is the best way to achieve this?
Trap 1: Use NAT policies
NAT policies translate IP addresses, but they do not provide access control between subnets.
Trap 2: Configure static routes in the virtual router
Static routes determine the path for traffic but do not enforce access control between subnets.
Trap 3: Configure path monitoring
Path monitoring is used for failover of static routes, not for access control.
An administrator wants to ensure that all traffic from the internal network to the internet uses a specific public IP address for source NAT. There are multiple public IP addresses available. What is the best way to achieve this?
Trap 1: Configure a NAT IP pool
An IP pool uses multiple addresses, not a single specific one.
Trap 2: Use a static NAT policy
Static NAT maps a specific internal IP to a specific public IP, not suitable for all traffic.
Why it fails: An IP pool uses multiple addresses, not a single specific one.
B
Use a static NAT policy
Why it fails: Static NAT maps a specific internal IP to a specific public IP, not suitable for all traffic.
C
Create a dynamic IP and port (DIPP) NAT policy with the specific IP as translated address
Dynamic IP and port NAT with a single translated address guarantees every internal host egresses behind that specific public IP, because the firewall allocates both address and port from one fixed pool. This satisfies the stem's requirement for deterministic source NAT when multiple public addresses exist, unlike dynamic IP NAT, which would rotate across the pool.
D
Use a PAT pool
Why it fails: A PAT pool also uses multiple addresses.
A firewall is configured with multiple virtual wire interfaces. Traffic passes through but the firewall cannot enforce security policies based on source/destination IP addresses. What is the reason?
Trap 1: The virtual wire is not configured with zones
Zones are required but even with zones, IP-based policies are not available in virtual wire mode.
Trap 2: The virtual wire requires a VLAN tag
VLAN tagging is optional and does not enable IP-based policies.
Trap 3: The security policy is in layer 3 mode
Layer 3 mode is for routed interfaces; virtual wire is Layer 2.
What does the PCNSE exam test about Deploy and Configure Firewalls?
Be able to build a working policy set: define zones and interfaces, write security and NAT rules that match real traffic, attach URL Filtering profiles, and design HA or redundant egress. The single most important thing is getting zone, address, and NAT matching correct so traffic is actually allowed and translated.
How should I use these practice questions?
Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Deploy and Configure Firewalls questions in a focused session?
Yes — the session launcher on this page draws every question from the Deploy and Configure Firewalls domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other PCNSE topics?
Use the topic links above to move to related areas, or go back to the PCNSE question bank to see all topics.
Are these real exam questions or dumps?
These are original practice questions written to test the same concepts the PCNSE exam covers. They are not copied from any real exam or dump site.