Scenario practice questions

An enterprise deployment of Prisma Access utilizes Kerberos authentication for mobile users. Users report frequent authentication prompt failures when connecting via GlobalProtect from external networks. What is the most likely root cause of Kerberos authentication failure in this scenario?

Trap 1: WildFire cloud subscription has expired.

WildFire is a cloud sandboxing and threat-detection subscription; its expiry affects file analysis and verdicts, not Kerberos ticket exchange. It would be the likely cause if users reported that suspicious files stopped receiving cloud verdicts rather than authentication prompts failing.

Trap 2: The decryption policy is missing an inbound rule.

Decryption policy governs SSL inspection of traffic flows, not Kerberos authentication. A missing inbound rule would cause traffic to be blocked or uninspected; it would be the right answer if users reported specific applications failing due to uninspected encrypted sessions, not credential prompts.

Trap 3: The GlobalProtect client software license is invalid.

GlobalProtect client licensing governs portal and gateway connectivity entitlements, not Kerberos ticket validation. An invalid licence would block the tunnel from establishing at all; it would be the correct suspect if GlobalProtect refused to connect outright rather than prompting for credentials repeatedly.

A
WildFire cloud subscription has expired.
Why it fails: WildFire is a cloud sandboxing and threat-detection subscription; its expiry affects file analysis and verdicts, not Kerberos ticket exchange. It would be the likely cause if users reported that suspicious files stopped receiving cloud verdicts rather than authentication prompts failing.
B
The decryption policy is missing an inbound rule.
Why it fails: Decryption policy governs SSL inspection of traffic flows, not Kerberos authentication. A missing inbound rule would cause traffic to be blocked or uninspected; it would be the right answer if users reported specific applications failing due to uninspected encrypted sessions, not credential prompts.
C
The GlobalProtect client software license is invalid.
Why it fails: GlobalProtect client licensing governs portal and gateway connectivity entitlements, not Kerberos ticket validation. An invalid licence would block the tunnel from establishing at all; it would be the correct suspect if GlobalProtect refused to connect outright rather than prompting for credentials repeatedly.
D
Lack of direct network line-of-sight or routing from the mobile user's remote location to the internal Active Directory Domain Controllers via a Service Connection.
Kerberos requires direct line-of-sight to a domain controller for ticket issuance, so remote GlobalProtect users off-network cannot reach internal Active Directory Domain Controllers unless a Service Connection provides routing. Without that path, ticket requests fail, producing the reported authentication prompt failures.

Question 2mediummultiple choice

An administrator is configuring Prisma Access to enforce security policies for mobile users based on the user's department. The administrator wants to ensure that only members of the 'Finance' department can access a sensitive internal application. Which Prisma Access feature should the administrator use to dynamically assign users to a policy group based on their department attribute from the identity provider?

Trap 1: Prisma Access explicit proxy with LDAP authentication for group…

Explicit proxy with LDAP authentication can authenticate users but does not dynamically assign them to policy groups based on IdP attributes. It also requires manual proxy configuration and may not integrate with SAML attributes. This method is not designed for dynamic group assignment based on department.

Trap 2: GlobalProtect HIP profiles with custom checks for department…

HIP profiles are used to assess endpoint security posture, not to assign users to groups based on department attributes. Using registry keys to infer department is unreliable and does not leverage identity provider data. This approach would not dynamically assign users based on their department from the IdP.

Trap 3: User-ID agent with group mapping from Active Directory.

A User-ID agent with group mapping from Active Directory can provide user-to-group mappings, but it requires an on-premises agent and is not the most direct feature for dynamic assignment based on IdP attributes. It may not support all IdP attributes and adds complexity, making it less suitable for this scenario.

A
Prisma Access explicit proxy with LDAP authentication for group lookup.
Why it fails: Explicit proxy with LDAP authentication can authenticate users but does not dynamically assign them to policy groups based on IdP attributes. It also requires manual proxy configuration and may not integrate with SAML attributes. This method is not designed for dynamic group assignment based on department.
B
Cloud Identity Engine (CIE) with SAML attributes for user group mapping.
The Cloud Identity Engine (CIE) ingests user and group information from identity providers and can map SAML attributes to Prisma Access policy groups. This allows dynamic assignment based on department attributes, enabling precise policy enforcement for the Finance department without on-premises infrastructure.
C
GlobalProtect HIP profiles with custom checks for department registry keys.
Why it fails: HIP profiles are used to assess endpoint security posture, not to assign users to groups based on department attributes. Using registry keys to infer department is unreliable and does not leverage identity provider data. This approach would not dynamically assign users based on their department from the IdP.
D
User-ID agent with group mapping from Active Directory.
Why it fails: A User-ID agent with group mapping from Active Directory can provide user-to-group mappings, but it requires an on-premises agent and is not the most direct feature for dynamic assignment based on IdP attributes. It may not support all IdP attributes and adds complexity, making it less suitable for this scenario.

Question 3hardmulti select

An administrator is troubleshooting a Prisma Access deployment experiencing intermittent packet drops and high latency across remote branches. Which THREE diagnostic steps or tools should be used? (Choose three)

Trap 1: Modify the administrative administrator accounts in Panorama.

Administrator account changes in Panorama affect management-plane access permissions and audit trails, not dataplane forwarding. This step suits a privileged-access review or role separation task; intermittent branch drops and latency require tunnel, routing and flow-level diagnostics instead.

Trap 2: Check the GlobalProtect portal certificate expiration date.

An expired portal certificate breaks GlobalProtect authentication outright, producing connection failures rather than intermittent drops with latency. Certificate expiry checks belong in a portal-access outage investigation; for branch packet loss you need tunnel and path diagnostics such as flow logs and IPSec counters.

A
Modify the administrative administrator accounts in Panorama.
Why it fails: Administrator account changes in Panorama affect management-plane access permissions and audit trails, not dataplane forwarding. This step suits a privileged-access review or role separation task; intermittent branch drops and latency require tunnel, routing and flow-level diagnostics instead.
B
Check IPsec tunnel monitoring statistics and DPD settings for packet loss and tunnel flapping.
IPsec tunnel statistics expose packet loss, rekey failures and latency across the tunnel, while Dead Peer Detection settings reveal flapping caused by missed keepalives or mismatched timers. Since the stem describes intermittent drops and high latency across remote branches, this directly targets the site-to-site VPN path rather than unrelated policy or endpoint causes.
C
Check the GlobalProtect portal certificate expiration date.
Why it fails: An expired portal certificate breaks GlobalProtect authentication outright, producing connection failures rather than intermittent drops with latency. Certificate expiry checks belong in a portal-access outage investigation; for branch packet loss you need tunnel and path diagnostics such as flow logs and IPSec counters.
D
Verify TCP MSS clamping and MTU configurations across the IPsec tunnels to prevent packet fragmentation.
Verifying TCP MSS clamping and MTU settings directly addresses fragmentation across the IPsec tunnels, a common cause of intermittent drops and latency at remote branches. Overlay encapsulation reduces usable MTU, so mismatched values force fragmentation or black-holing. Correctly clamping MSS prevents this, satisfying the stem's packet-loss and latency constraint.
E
Review QoS bandwidth allocation and utilization to ensure critical traffic is not being dropped due to congestion.
Reviewing QoS bandwidth allocation directly addresses congestion, a plausible cause of intermittent drops and high latency across bandwidth-constrained remote branches. Prisma Access applies QoS profiles per tunnel and class, so confirming critical traffic classes retain sufficient guaranteed bandwidth, and that utilisation has not saturated shaping limits, isolates congestion-induced loss from other faults.

Read the full VPN explanation →

Question 4mediummulti select

An administrator is reviewing the status of Remote Networks in Prisma Access and notices that an IPsec tunnel has failed to establish. Which THREE diagnostic steps or verifications should the administrator perform in Panorama or Prisma Access Insights? (Choose three)

Trap 1: Modify the GlobalProtect client configuration to force internal DNS…

GlobalProtect client DNS settings affect mobile user traffic, not IPsec tunnel establishment between a remote network and Prisma Access. It is tempting because DNS misconfiguration does break connectivity, and this step would be correct when troubleshooting GlobalProtect client name resolution failures.

Trap 2: Reboot the Cloud Identity Engine container to clear stale routing…

Cloud Identity Engine handles identity and directory services, not IPsec routing; rebooting it cannot clear tunnel state. It is tempting because stale cache entries do cause intermittent faults, and this action would be correct when Cloud Identity Engine authentication or directory sync is failing.

A
Modify the GlobalProtect client configuration to force internal DNS resolution.
Why it fails: GlobalProtect client DNS settings affect mobile user traffic, not IPsec tunnel establishment between a remote network and Prisma Access. It is tempting because DNS misconfiguration does break connectivity, and this step would be correct when troubleshooting GlobalProtect client name resolution failures.
B
Reboot the Cloud Identity Engine container to clear stale routing cache entries.
Why it fails: Cloud Identity Engine handles identity and directory services, not IPsec routing; rebooting it cannot clear tunnel state. It is tempting because stale cache entries do cause intermittent faults, and this action would be correct when Cloud Identity Engine authentication or directory sync is failing.
C
Verify that the peer public IP address configured in Panorama matches the public IP of the branch office router.
IPsec establishment requires matching peer identities; if Panorama's configured peer public IP differs from the branch router's actual public IP, IKE negotiation fails. Verifying this match directly addresses the tunnel failure described in the stem.
D
Check that IKE Phase 1 and Phase 2 cryptographic proposals (encryption, authentication, DH group) match on both the Prisma Access side and the branch router.
IPsec requires matching IKE Phase 1 and Phase 2 proposals on both peers; any mismatch in encryption, authentication or DH group causes tunnel establishment to fail. Verifying these parameters directly addresses the failed-tunnel symptom by ruling out a cryptographic proposal mismatch.
E
Review Prisma Access Insights to check tunnel status, error logs, and event details.
Prisma Access Insights surfaces tunnel status, error logs and event details, giving the administrator the specific failure reason for the IPsec tunnel. Reviewing these directly satisfies the diagnostic requirement, since the logs identify whether the failure is proposal, routing or peer related.

Question 5easymultiple choice

An administrator needs to give the security team a single dashboard that shows which Prisma Access security policy rules are being triggered most frequently across all mobile users and Remote Networks over the last 30 days. Which Prisma Access reporting capability should the administrator use?

Trap 1: The Threat log filtered by policy name

The Threat log records security events such as antivirus, anti-spyware, and vulnerability detections, not a count of policy rule hits. Filtering it by policy name would only show threats that matched a rule, not overall rule utilization. It also does not provide a consolidated 30-day dashboard of policy rule frequency across all users and networks.

Trap 2: The Policy Optimizer in the Prisma Access monitoring interface

Policy Optimizer helps identify unused or overly permissive rules and suggests consolidation, but it does not provide a dashboard of the most frequently triggered rules over a 30-day period. Its purpose is rule hygiene and migration, not usage trending, so it does not satisfy the requirement for a frequency dashboard.

Trap 3: The System log filtered by configuration commits

The System log records administrative and system events such as commits, HA state changes, and process restarts. It contains no information about security policy rule matches or traffic, so it cannot show which rules are triggered most frequently. This option is unrelated to the reporting requirement.

A
The Threat log filtered by policy name
Why it fails: The Threat log records security events such as antivirus, anti-spyware, and vulnerability detections, not a count of policy rule hits. Filtering it by policy name would only show threats that matched a rule, not overall rule utilization. It also does not provide a consolidated 30-day dashboard of policy rule frequency across all users and networks.
B
The Policy Optimizer in the Prisma Access monitoring interface
Why it fails: Policy Optimizer helps identify unused or overly permissive rules and suggests consolidation, but it does not provide a dashboard of the most frequently triggered rules over a 30-day period. Its purpose is rule hygiene and migration, not usage trending, so it does not satisfy the requirement for a frequency dashboard.
C
The System log filtered by configuration commits
Why it fails: The System log records administrative and system events such as commits, HA state changes, and process restarts. It contains no information about security policy rule matches or traffic, so it cannot show which rules are triggered most frequently. This option is unrelated to the reporting requirement.
D
The predefined Security policy rule usage report in the Prisma Access reporting interface
Prisma Access includes predefined reports that summarize security policy rule usage, showing which rules are hit most often. This directly provides the requested 30-day view across mobile users and Remote Networks, giving the security team a single dashboard of rule frequency without custom log queries.

Read the full DNS explanation →

Question 6hardmultiple choice

A Prisma Access mobile user experiences a scenario where specific internal domains fail to resolve when connected via GlobalProtect, while other internal domains resolve successfully. The split-DNS configuration in Panorama lists multiple domains. What is the most likely reason for this partial DNS failure?

Trap 1: The GlobalProtect portal SSL certificate is expired.

An expired portal certificate breaks the GlobalProtect portal or gateway TLS handshake entirely, preventing any connection. It would be correct if users could not connect at all, but the tunnel is established and other internal domains resolve, so certificate validity is not the cause.

Trap 2: WildFire cloud connectivity is down.

WildFire cloud connectivity governs file submission and verdict retrieval for threat inspection, unrelated to name resolution. It would be correct when sandboxing or malware verdicts fail, but DNS queries for internal domains do not traverse WildFire, so partial resolution failures cannot stem from it.

Trap 3: BGP route reflection is misconfigured on the Service Connection.

BGP route reflection affects route distribution between Service Connection and remote networks, not which DNS servers GlobalProtect hands to clients. It would matter for routing reachability failures, yet here some domains resolve, so the fault lies in split-DNS domain matching rather than routing.

A
The GlobalProtect portal SSL certificate is expired.
Why it fails: An expired portal certificate breaks the GlobalProtect portal or gateway TLS handshake entirely, preventing any connection. It would be correct if users could not connect at all, but the tunnel is established and other internal domains resolve, so certificate validity is not the cause.
B
WildFire cloud connectivity is down.
Why it fails: WildFire cloud connectivity governs file submission and verdict retrieval for threat inspection, unrelated to name resolution. It would be correct when sandboxing or malware verdicts fail, but DNS queries for internal domains do not traverse WildFire, so partial resolution failures cannot stem from it.
C
BGP route reflection is misconfigured on the Service Connection.
Why it fails: BGP route reflection affects route distribution between Service Connection and remote networks, not which DNS servers GlobalProtect hands to clients. It would matter for routing reachability failures, yet here some domains resolve, so the fault lies in split-DNS domain matching rather than routing.
D
Improperly formatted domain suffixes or exceeding the maximum number of supported split-DNS search domains for the client operating system.
Split-DNS resolution fails partially when suffix entries are malformed or the client OS search-domain limit is exceeded, so only some internal domains resolve. Correcting suffix formatting and reducing entries below the OS maximum restores resolution for the affected domains.

Read the full VPN explanation →

Question 7hardmultiple choice

A Prisma Access administrator is troubleshooting a remote network site where IPsec tunnels are flapping. The administrator suspects that the tunnel monitoring settings are too aggressive. Which configuration parameter should be adjusted to reduce flapping?

Trap 1: Enable IKEv1 instead of IKEv2 for the remote network IPSec tunnel.

Switching to IKEv1 does not inherently reduce flapping. IKEv1 and IKEv2 both support DPD, and the flapping issue is related to DPD settings, not the IKE version. In fact, IKEv2 is generally more robust and efficient. Changing the IKE version would not address the aggressive monitoring that likely causes the flapping. Thus, this is not the correct adjustment.

Trap 2: Modify the IPsec proposal encryption algorithms to use stronger…

Changing encryption algorithms affects security and performance but does not influence tunnel stability. Flapping is caused by connectivity detection failures, not by the cryptographic strength of the IPsec proposal. Stronger ciphers might increase CPU load, potentially worsening performance, but they will not resolve flapping. Therefore, this change is irrelevant to the problem.

Trap 3: Increase the IKEv2 rekey timer on the remote network IPSec tunnel.

The IKEv2 rekey timer controls how often the IKE security association is renegotiated for key refresh. While a very short rekey timer could cause periodic renegotiation, it does not directly cause tunnel flapping due to connectivity checks. Flapping is typically caused by aggressive dead peer detection (DPD) or tunnel monitoring, not by rekey timers. Adjusting the rekey timer would not address the underlying flapping issue.

A
Enable IKEv1 instead of IKEv2 for the remote network IPSec tunnel.
Why it fails: Switching to IKEv1 does not inherently reduce flapping. IKEv1 and IKEv2 both support DPD, and the flapping issue is related to DPD settings, not the IKE version. In fact, IKEv2 is generally more robust and efficient. Changing the IKE version would not address the aggressive monitoring that likely causes the flapping. Thus, this is not the correct adjustment.
B
Modify the IPsec proposal encryption algorithms to use stronger ciphers.
Why it fails: Changing encryption algorithms affects security and performance but does not influence tunnel stability. Flapping is caused by connectivity detection failures, not by the cryptographic strength of the IPsec proposal. Stronger ciphers might increase CPU load, potentially worsening performance, but they will not resolve flapping. Therefore, this change is irrelevant to the problem.
C
Adjust the dead peer detection (DPD) interval and retry count on the remote network IPSec tunnel.
DPD detects if the peer is unreachable. If the DPD interval is too short or retry count too low, transient network issues can cause the tunnel to be torn down and re-established, leading to flapping. Increasing the DPD interval and retry count makes the tunnel more tolerant of brief disruptions, reducing unnecessary flapping. This directly addresses the suspected cause and is the correct parameter to adjust.
D
Increase the IKEv2 rekey timer on the remote network IPSec tunnel.
Why it fails: The IKEv2 rekey timer controls how often the IKE security association is renegotiated for key refresh. While a very short rekey timer could cause periodic renegotiation, it does not directly cause tunnel flapping due to connectivity checks. Flapping is typically caused by aggressive dead peer detection (DPD) or tunnel monitoring, not by rekey timers. Adjusting the rekey timer would not address the underlying flapping issue.

Question 8mediummultiple choice

An administrator has deployed Prisma Access with a single Remote Network SPN at a branch office in Frankfurt. Users complain that after a failover of the primary ISP link, all traffic to SaaS applications is being forced through the backup link even though the primary link is healthy again. The administrator wants Prisma Access to automatically restore the preferred path without manual intervention. Which feature should be configured?

Trap 1: Quality of Service (QoS) profiles on the IPSec tunnel

QoS profiles classify and prioritize traffic within a tunnel; they do not select which ISP link carries the tunnel. Applying QoS would not move traffic from the backup link back to the primary link after recovery, so this option does not meet the requirement of automatic path restoration.

Trap 2: ECMP load balancing across both ISP links

ECMP distributes flows across multiple equal-cost paths, but it does not automatically revert traffic to a preferred link after a failover. It also can cause asymmetric routing for stateful inspection. In this scenario, the requirement is deterministic restoration of the primary path, not per-flow load sharing, so ECMP does not satisfy the stated goal.

Trap 3: BGP local preference tuning on the CPE router

BGP local preference influences outbound path selection on the branch router, but Prisma Access Remote Network tunnels are typically static or IKEv2-based and do not depend on BGP preference for tunnel selection. Changing local preference also does not cause Prisma Access to re-evaluate link quality and fail back automatically, so it does not solve the stated problem.

A
Quality of Service (QoS) profiles on the IPSec tunnel
Why it fails: QoS profiles classify and prioritize traffic within a tunnel; they do not select which ISP link carries the tunnel. Applying QoS would not move traffic from the backup link back to the primary link after recovery, so this option does not meet the requirement of automatic path restoration.
B
ECMP load balancing across both ISP links
Why it fails: ECMP distributes flows across multiple equal-cost paths, but it does not automatically revert traffic to a preferred link after a failover. It also can cause asymmetric routing for stateful inspection. In this scenario, the requirement is deterministic restoration of the primary path, not per-flow load sharing, so ECMP does not satisfy the stated goal.
C
BGP local preference tuning on the CPE router
Why it fails: BGP local preference influences outbound path selection on the branch router, but Prisma Access Remote Network tunnels are typically static or IKEv2-based and do not depend on BGP preference for tunnel selection. Changing local preference also does not cause Prisma Access to re-evaluate link quality and fail back automatically, so it does not solve the stated problem.
D
Path quality monitoring with failback on the Remote Network
Path quality monitoring continuously probes each ISP link and, when the primary link's metrics recover, triggers failback so the preferred path is restored automatically. This directly addresses the described symptom where traffic remains on the backup link after the primary ISP recovers, and it requires no manual administrator action.