Scenario practice questions

An architect is designing a high-scale User-ID deployment using PAN-OS firewalls and Panorama. Which TWO methods can be utilized to gather user mapping information directly from Active Directory without relying solely on client-side software agents? (Choose two)

Trap 1: Configuring XML API push notifications directly from the VMware NSX…

NSX manager integration maps hypervisor tags, not Active Directory user login identities.

Trap 2: Installing the GlobalProtect app with embedded Host Information…

GlobalProtect HIP reporting gathers workstation posture data, not raw Active Directory IP-to-username mappings.

Trap 3: Enabling Terminal Server (TS) Agent on all client workstations

TS Agent is specifically designed for multi-user terminal servers (Citrix/RDS), not individual standard client workstations.

A
Configuring XML API push notifications directly from the VMware NSX manager
Why it fails: NSX manager integration maps hypervisor tags, not Active Directory user login identities.
B
Configuring PAN-OS to listen for Syslog security log entries emitted from authentication servers or SIEMs
Syslog listening allows the firewall to parse authentication events sent from external logging systems or directory servers.
C
Installing the GlobalProtect app with embedded Host Information Profile (HIP) reporting on every user workstation
Why it fails: GlobalProtect HIP reporting gathers workstation posture data, not raw Active Directory IP-to-username mappings.
D
Configuring PAN-OS Agentless User-ID to poll Active Directory domain controllers via WMI or Windows Security Event logs
Agentless User-ID polls domain controllers directly via WMI or Windows Security event logs, satisfying the stem's requirement to gather mappings without client-side agents. It reads AD logon events server-side, so no software is installed on endpoints, and Panorama can distribute the resulting mappings across managed firewalls at scale.
E
Enabling Terminal Server (TS) Agent on all client workstations
Why it fails: TS Agent is specifically designed for multi-user terminal servers (Citrix/RDS), not individual standard client workstations.

Open the full VLAN trunking answer →

Question 2mediummultiple choice

A security architect is redesigning a campus network to follow Zero Trust principles. The current design places all access switches in a single Layer 2 VLAN with the core, allowing any authenticated user to reach any internal resource. The architect wants to enforce policy based on user identity and device posture while minimizing changes to the existing switching infrastructure. Which approach best aligns with Zero Trust network segmentation?

Trap 1: Create a single large subnet with private VLANs (PVLANs) to isolate…

PVLANs provide Layer 2 isolation but do not enforce identity- or posture-based policy, and they require careful promiscuous port design. They also do not dynamically adapt to user group changes, so a contractor and an employee in the same isolated port would receive identical treatment. This fails the requirement to base access on user identity and device posture.

Trap 2: Deploy a next-generation firewall between every access switch and…

Inserting a firewall per access switch is a valid segmentation tactic but is disruptive and costly here, requiring re-cabling and new high-availability pairs. The scenario explicitly asks to minimize changes to the existing switching infrastructure, and this approach does not leverage the existing 802.1X-capable switches or RADIUS investment, making it a poor architectural fit.

Trap 3: Enable DHCP snooping and dynamic ARP inspection on all access…

DHCP snooping and dynamic ARP inspection mitigate specific Layer 2 attacks such as rogue DHCP servers and ARP spoofing, but they do not segment traffic or enforce identity-based access. They leave the flat VLAN intact, so any authenticated user can still reach any internal resource, which directly contradicts the Zero Trust segmentation goal described in the scenario.

A
Create a single large subnet with private VLANs (PVLANs) to isolate hosts at Layer 2 while keeping the same VLAN interface.
Why it fails: PVLANs provide Layer 2 isolation but do not enforce identity- or posture-based policy, and they require careful promiscuous port design. They also do not dynamically adapt to user group changes, so a contractor and an employee in the same isolated port would receive identical treatment. This fails the requirement to base access on user identity and device posture.
B
Implement 802.1X with dynamic VLAN assignment and downloadable ACLs from the RADIUS server based on user group and posture.
802.1X with dynamic authorization lets the RADIUS server assign VLANs and ACLs per session based on identity and posture, enforcing least privilege without replacing switches. This directly maps to Zero Trust's 'never trust, always verify' by using authentication context to segment access at the port level, satisfying the requirement to minimize infrastructure changes while adding identity-aware controls.
C
Deploy a next-generation firewall between every access switch and the core, forcing all inter-VLAN traffic through inspection.
Why it fails: Inserting a firewall per access switch is a valid segmentation tactic but is disruptive and costly here, requiring re-cabling and new high-availability pairs. The scenario explicitly asks to minimize changes to the existing switching infrastructure, and this approach does not leverage the existing 802.1X-capable switches or RADIUS investment, making it a poor architectural fit.
D
Enable DHCP snooping and dynamic ARP inspection on all access switches to prevent lateral movement.
Why it fails: DHCP snooping and dynamic ARP inspection mitigate specific Layer 2 attacks such as rogue DHCP servers and ARP spoofing, but they do not segment traffic or enforce identity-based access. They leave the flat VLAN intact, so any authenticated user can still reach any internal resource, which directly contradicts the Zero Trust segmentation goal described in the scenario.

Question 3hardmulti select

An architect is troubleshooting an automated workflow where Cortex XSOAR attempts to quarantine a compromised host by registering an IP address to a Dynamic Address Group on Panorama. The API returns a success code, but the firewall does not apply the security rule action. Which THREE potential issues should the architect investigate? (Choose three)

Trap 1: Verify that the physical firewall chassis has active power…

Power redundancy has no bearing on whether a DAG tag propagates to the firewall and matches a rule. It is tempting because hardware health checks are standard troubleshooting, and a failed PSU could cause outages. Here the API returned success, so the fault lies in tag registration, group membership, or rule configuration, not chassis power.

Trap 2: Ensure that the BGP routing table on the core switch is advertising…

BGP advertisement is irrelevant: Dynamic Address Groups are populated by Panorama tags via the User-ID or DAG API, not by routing protocols. It is tempting because network quarantine is often conflated with route manipulation, and BGP blackholing is a legitimate containment technique in routing-based scenarios, but not for DAG-driven policy enforcement.

A
Verify that the physical firewall chassis has active power redundancy on both power supply units.
Why it fails: Power redundancy has no bearing on whether a DAG tag propagates to the firewall and matches a rule. It is tempting because hardware health checks are standard troubleshooting, and a failed PSU could cause outages. Here the API returned success, so the fault lies in tag registration, group membership, or rule configuration, not chassis power.
B
Ensure that the BGP routing table on the core switch is advertising the quarantined IP address.
Why it fails: BGP advertisement is irrelevant: Dynamic Address Groups are populated by Panorama tags via the User-ID or DAG API, not by routing protocols. It is tempting because network quarantine is often conflated with route manipulation, and BGP blackholing is a legitimate containment technique in routing-based scenarios, but not for DAG-driven policy enforcement.
C
Confirm that Panorama has successfully pushed the updated Dynamic Address Group policy configuration to the managed firewalls.
Dynamic Address Group membership only takes effect once Panorama commits and pushes the updated configuration to the managed firewalls. If the push fails or is pending, the firewall keeps the old group contents, so the security rule never matches the registered IP despite the API success.
D
Check that the target firewall is successfully receiving User-ID updates and communicating with Panorama/User-ID agents.
Dynamic Address Group membership driven by User-ID requires the firewall to receive IP-to-tag mappings from Panorama or a User-ID agent. If that update channel is broken, the API registration succeeds on Panorama but the firewall never learns the tag, so the security rule never matches the quarantined host.
E
Verify that the tag name used in the User-ID API registration exactly matches the tag specified in the Dynamic Address Group object configuration.
Dynamic Address Group matching is tag-based, so the tag pushed via the User-ID API must be byte-identical to the tag referenced in the DAG filter. A mismatch or case difference means the IP is registered but never joins the group, leaving the security rule unmatched despite the API success response.

Review the full routing breakdown →

Question 4easymultiple choice

When deploying VM-Series firewalls in Google Cloud Platform (GCP), which feature must be enabled on the firewall's data plane network interfaces (NICs) to allow the firewall to process packets destined for other IP addresses (such as during routing scenarios)?

Trap 1: VPC Flow Logs

VPC Flow Logs only record metadata about traffic traversing the network; they do not alter packet handling or permit a NIC to accept traffic addressed elsewhere. It is tempting because flow logs are a common GCP network visibility tool, and enabling them would be correct when auditing or troubleshooting traffic patterns.

Trap 2: Shared VPC attachment

Shared VPC attachment governs how projects share subnets and IAM, not whether a NIC accepts packets addressed to other IPs. It is tempting because Shared VPC is central to multi-project GCP network design, and attaching a host project would be correct when centralising subnet administration across projects.

Trap 3: Alias IP ranges

Alias IP ranges let a GCP VM accept traffic for additional addresses, but they do not enable forwarding of packets whose destination is neither the NIC's primary nor alias address. IP forwarding is the required setting. Alias ranges suit hosting multiple services on one instance, not transit routing.

A
IP Forwarding
GCP NICs drop traffic not addressed to their own IP unless IP forwarding is enabled. Enabling it lets the VM-Series data plane accept and route packets destined for other addresses, satisfying the routing-scenario requirement in the stem.
B
VPC Flow Logs
Why it fails: VPC Flow Logs only record metadata about traffic traversing the network; they do not alter packet handling or permit a NIC to accept traffic addressed elsewhere. It is tempting because flow logs are a common GCP network visibility tool, and enabling them would be correct when auditing or troubleshooting traffic patterns.
C
Shared VPC attachment
Why it fails: Shared VPC attachment governs how projects share subnets and IAM, not whether a NIC accepts packets addressed to other IPs. It is tempting because Shared VPC is central to multi-project GCP network design, and attaching a host project would be correct when centralising subnet administration across projects.
D
Alias IP ranges
Why it fails: Alias IP ranges let a GCP VM accept traffic for additional addresses, but they do not enable forwarding of packets whose destination is neither the NIC's primary nor alias address. IP forwarding is the required setting. Alias ranges suit hosting multiple services on one instance, not transit routing.

Question 5hardmultiple choice

An architect is deploying Advanced URL Filtering with real-time inline machine learning. A newly registered phishing domain is accessed by an employee. Standard static reputation feeds have not yet categorized this domain. How does Advanced URL Filtering successfully block this attempt in real time?

Trap 1: The firewall forces an immediate SSL client certificate challenge…

A client certificate challenge authenticates the server's identity; it cannot classify an uncategorised domain or block a phishing page, and TLS interception is what inspection actually requires. It is tempting because certificate checks are a genuine security control, and they would be the right answer if the scenario concerned impersonation rather than unknown-domain categorisation.

Trap 2: The local URL caching database queries the local DNS server for…

DNS or WHOIS lookups return registration metadata, not a verdict on page content, and the local cache holds reputation results rather than performing WHOIS queries. It is tempting because domain age is a useful phishing signal, and it would be correct if the question asked how static feeds enrich reputation rather than how inline machine learning classifies uncategorised URLs.

Trap 3: The firewall drops all traffic to newly created domains by default…

Blanket blocking of all newly registered domains with manual analyst release is neither real-time nor inline machine learning, and it would break legitimate new sites. It is tempting because domain-age blocking is a real technique, and it would be correct if the requirement were a strict allow-list policy rather than automated real-time classification.

A
The firewall forces an immediate SSL client certificate challenge to verify the identity of the web server before establishing the TCP connection.
Why it fails: A client certificate challenge authenticates the server's identity; it cannot classify an uncategorised domain or block a phishing page, and TLS interception is what inspection actually requires. It is tempting because certificate checks are a genuine security control, and they would be the right answer if the scenario concerned impersonation rather than unknown-domain categorisation.
B
The local URL caching database queries the local DNS server for historical WHOIS record creation dates.
Why it fails: DNS or WHOIS lookups return registration metadata, not a verdict on page content, and the local cache holds reputation results rather than performing WHOIS queries. It is tempting because domain age is a useful phishing signal, and it would be correct if the question asked how static feeds enrich reputation rather than how inline machine learning classifies uncategorised URLs.
C
The firewall drops all traffic to newly created domains by default until a human analyst manually verifies the site via the Palo Alto Networks Support Portal.
Why it fails: Blanket blocking of all newly registered domains with manual analyst release is neither real-time nor inline machine learning, and it would break legitimate new sites. It is tempting because domain-age blocking is a real technique, and it would be correct if the requirement were a strict allow-list policy rather than automated real-time classification.
D
The cloud-delivered service evaluates page content and structural heuristics in real time via inline machine learning during the transaction.
Inline machine learning inspects the live page content and structural characteristics during the transaction itself, rather than relying on pre-categorised reputation. This lets the cloud service classify and block a newly registered phishing domain that static feeds have not yet rated.

Question 6hardmultiple choice

An architect is designing a high-availability Panorama deployment across two data centers. During a WAN partition event, both Panorama nodes lose connectivity with each other but retain management access to local firewalls. What happens to the management plane operations of the managed firewalls in this split-brain scenario?

Trap 1: Both Panorama nodes automatically initiate a factory reset of all…

Panorama holds no mechanism to wipe managed firewalls, and a partition cannot trigger factory resets. Configuration commits continue locally from each node's cached candidate config. Factory reset is an administrative recovery action for a compromised or redeployed device, not an HA behaviour.

Trap 2: Managed firewalls immediately enter a fail-safe suspended state and…

Panorama manages configuration and logging; it does not gate firewall dataplane forwarding. During a partition, firewalls keep processing transit traffic under their last committed policy. Suspending traffic is a firewall HA (active/passive) behaviour, unrelated to Panorama connectivity.

Trap 3: Firewalls automatically promote the secondary Panorama node to…

Panorama HA election requires the peers to communicate; a WAN partition leaves each node believing it is primary, with no automatic promotion or state-table synchronisation. State synchronisation belongs to firewall HA pairs, which share session tables — Panorama replicates configuration and logs instead.

A
Both Panorama nodes automatically initiate a factory reset of all managed firewalls to prevent configuration drift.
Why it fails: Panorama holds no mechanism to wipe managed firewalls, and a partition cannot trigger factory resets. Configuration commits continue locally from each node's cached candidate config. Factory reset is an administrative recovery action for a compromised or redeployed device, not an HA behaviour.
B
Managed firewalls continue to process traffic normally using their cached running configuration, but cannot receive policy updates until connectivity is restored.
Panorama is a management plane only; firewalls hold their last-pushed configuration locally. During a split-brain WAN partition they keep forwarding traffic on that cached config, but commit operations and policy pushes stall until Panorama connectivity returns.
C
Managed firewalls immediately enter a fail-safe suspended state and drop all transit traffic.
Why it fails: Panorama manages configuration and logging; it does not gate firewall dataplane forwarding. During a partition, firewalls keep processing transit traffic under their last committed policy. Suspending traffic is a firewall HA (active/passive) behaviour, unrelated to Panorama connectivity.
D
Firewalls automatically promote the secondary Panorama node to primary and synchronize state tables.
Why it fails: Panorama HA election requires the peers to communicate; a WAN partition leaves each node believing it is primary, with no automatic promotion or state-table synchronisation. State synchronisation belongs to firewall HA pairs, which share session tables — Panorama replicates configuration and logs instead.

Question 7hardmultiple choice

An architect is troubleshooting a scenario where internal clients are experiencing intermittent connectivity issues to specific SaaS applications. Packet captures reveal that the Palo Alto Networks firewall is resetting connections due to TCP out-of-window anomalies detected by the Threat Prevention engine. What is the correct architectural adjustment?

Trap 1: Increase the TCP Three-Way Handshake timeout value in the zone…

The handshake timeout governs how long a half-open session waits for completion; it cannot suppress out-of-window resets, which occur mid-session when the Threat Prevention engine sees sequence numbers outside the expected window. Raising it is right only when clients legitimately need longer to complete the three-way handshake.

Trap 2: Disable all SSL Decryption profiles globally to prevent TCP…

Disabling SSL decryption removes inspection of encrypted SaaS traffic, but the resets stem from the Threat Prevention engine flagging TCP out-of-window anomalies caused by asymmetric routing or packet reordering, not decryption itself. Decryption profiles are correctly disabled only where legal, privacy or performance constraints forbid inspection.

Trap 3: Configure a static NAT policy mapping all internal RFC 1918…

Static NAT rewrites source addresses for outbound translation and has no bearing on TCP sequence validation, so out-of-window resets persist. It is the correct choice when many internal hosts must share one public address for internet egress or inbound publishing.

A
Increase the TCP Three-Way Handshake timeout value in the zone protection profile to 300 seconds.
Why it fails: The handshake timeout governs how long a half-open session waits for completion; it cannot suppress out-of-window resets, which occur mid-session when the Threat Prevention engine sees sequence numbers outside the expected window. Raising it is right only when clients legitimately need longer to complete the three-way handshake.
B
Disable all SSL Decryption profiles globally to prevent TCP sequence number re-writing by the proxy engine.
Why it fails: Disabling SSL decryption removes inspection of encrypted SaaS traffic, but the resets stem from the Threat Prevention engine flagging TCP out-of-window anomalies caused by asymmetric routing or packet reordering, not decryption itself. Decryption profiles are correctly disabled only where legal, privacy or performance constraints forbid inspection.
C
Configure a static NAT policy mapping all internal RFC 1918 addresses to a single public IP.
Why it fails: Static NAT rewrites source addresses for outbound translation and has no bearing on TCP sequence validation, so out-of-window resets persist. It is the correct choice when many internal hosts must share one public address for internet egress or inbound publishing.
D
Investigate for asymmetric routing paths and adjust TCP Strict Check options or stream normalization settings if necessary.
Out-of-window resets typically stem from traffic traversing asymmetric paths, so return packets arrive outside the expected TCP window. Investigating routing symmetry and tuning TCP Strict Check or stream normalisation prevents the firewall dropping legitimate SaaS sessions.