Deploy and Configure Core Components
Free Palo Alto Networks Certified Network Security Engineer practice — 6 questions on Deploy and Configure Core Components, with explanations. No sign-up. Full 12-question mixed test →
A firewall administrator enables SSL Forward Proxy decryption for all outbound web traffic. Users report that when accessing a specific banking site that presents a valid, publicly trusted certificate, they still receive a browser certificate-warning page. Firewall decryption logs show the site's certificate chain terminating at an untrusted issuer, while all other HTTPS sites decrypt without warnings. What is the MOST likely cause and correct fix?
When only one specific site fails chain validation while all others decrypt cleanly, the root cause is almost always a missing intermediate CA certificate in the firewall's trusted CA store, which prevents the firewall from building a complete trust chain and forces it to sign the substitute certificate with the Forward Untrust CA instead of the Forward Trust CA.
A web server sits in the DMZ zone at 10.1.1.10 and is published externally as 203.0.113.10 via a static Destination NAT rule with source zone 'Untrust' and destination zone 'Untrust' (the zone associated with the public IP's routing). Internal users in the 'Trust' zone try to reach the server using the public IP 203.0.113.10, and connections fail, even though a Security policy rule permits Trust-to-DMZ traffic. Which NAT configuration change correctly enables this u-turn NAT scenario?
NAT rule zone matching is based on the zone the original (pre-NAT) destination IP would route to according to the routing table, not the zone the traffic will ultimately land in after translation. Because 203.0.113.10 routes toward Untrust, a u-turn NAT rule must use source zone Trust and destination zone Untrust (matching that pre-NAT routing lookup), with source NAT added so the DMZ server's return traffic hairpins correctly back to the Trust host instead of routing to the internet.
According to Palo Alto Networks' documented App-ID application dependency chain, which additional applications must an administrator explicitly permit in the Security policy to allow 'facebook-chat' to function correctly?
The App-ID database documents facebook-chat as dependent on facebook-base, and facebook-base as dependent on web-browsing; PAN-OS does not automatically permit dependent applications through policy, so all three must be explicitly allowed (or covered by an application-group/filter) for facebook-chat to be permitted.
A security engineer notices that the User-ID feature is actively mapping IP addresses to usernames inside the Data Center zone, where servers communicate using shared service accounts. This produces misleading user attribution in traffic logs and increases the risk of user-mapping spoofing from that zone. What is the recommended configuration to correct this?
The documented best practice is to enable User Identification only on zones where user-to-IP mapping is actually needed for policy enforcement; the per-zone 'Enable User Identification' checkbox (Network > Zones) directly controls whether the firewall applies User-ID mapping within that zone, and disabling it on server/Data Center zones eliminates the spoofing risk described.
An administrator configures SSL Inbound Inspection to decrypt and inspect traffic destined to an internal application server, using a Decryption Profile that has settings enabled on both the 'SSL Protocol Settings' tab and the 'SSL Forward Proxy' tab. Which single setting will have NO effect on the SSL Inbound Inspection sessions?
'Block sessions with untrusted issuer' lives on the SSL Forward Proxy tab and only applies when the firewall is validating an external server's certificate chain against its trusted CA store during Forward Proxy decryption. In SSL Inbound Inspection, the firewall already holds the actual server's private key and certificate, so there is no external issuer trust decision to evaluate, making this setting inapplicable.
Two interfaces, ethernet1/3 and ethernet1/4, are both assigned to the same zone, 'DMZ', on a Palo Alto Networks firewall. No explicit Security policy rules have been created for DMZ-to-DMZ traffic. An administrator observes that traffic between hosts on these two interfaces is being permitted anyway. What explains this behavior?
PAN-OS ships with two hidden default Security policy rules: 'intrazone-default,' which allows all traffic within the same zone, and 'interzone-default,' which denies all traffic between different zones. Since both interfaces belong to the same DMZ zone, the intrazone-default allow rule is the one being matched, and it remains in effect until an administrator explicitly clones, modifies, or overrides it.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →