Select Two (Multi-Select) Questions

Disable all multi-factor authentication (MFA) requirements on Prisma Access portals.

Why it fails: Disabling MFA removes an authentication control rather than configuring CIE to consume directory group data, so group-based policy enforcement gains nothing. It is tempting because MFA prompts can complicate portal logins during testing, and disabling MFA would be valid only where a separate identity provider already enforces it upstream.

Install the GlobalProtect agent directly on all domain controller servers acting as CIE proxies.

Why it fails: GlobalProtect belongs on user endpoints for tunnel and HIP collection, not on domain controllers, which run the CIE proxy service to query AD. Installing it there adds no authentication path and may disrupt the directory role.

Manually export user CSV files daily and upload them to Panorama using the CLI.

Why it fails: CIE maintains live directory synchronisation through its proxy or agent, so scheduled CSV exports are unnecessary and stale between uploads; group membership changes would not be reflected promptly. CSV import suits isolated environments with no direct directory connectivity.

Individual endpoint user Windows registry configurations

Why it fails: Prisma Access Insights reports on service health, tunnels, users and threat activity from telemetry, not endpoint registry settings. Endpoint registry configuration belongs to endpoint management or the agent's own configuration tooling, so it is tempting when troubleshooting client behaviour, but it is outside this tool's scope.

Local branch switch port VLAN configurations

Why it fails: Prisma Access Insights surfaces aggregate service and security telemetry; it does not read branch switch port VLAN assignments, which live in the switching infrastructure. It is tempting because Insights covers network health, yet switch-level configuration is gathered by network management tooling, not this dashboard.

Verify the WildFire cloud analysis subscription status.

Why it fails: WildFire cloud analysis inspects files and URLs for malware; it has no role in BGP peering or route exchange, so a subscription status cannot explain unlearned routes. It is tempting because licence and subscription checks often resolve feature failures, and WildFire subscription status would be the correct thing to verify when cloud file analysis or inline malware verdicts are unavailable.

Check the GlobalProtect portal SSL certificate expiration date.

Why it fails: GlobalProtect portal certificates secure end-user VPN authentication, not the IPSec or BGP session carrying remote network routes. It is tempting because expired certificates cause connectivity failures elsewhere, but route learning depends on tunnel, peering and prefix configuration, not portal certificate validity.

Legacy PPTP VPN dial-in server integration

Why it fails: PPTP is a deprecated tunnelling protocol providing network-level access, not per-application least-privileged authorisation, and Prisma Access ZTNA 2.0 does not integrate with it. It is tempting as a remote-access VPN, and it would suit legacy site-to-site or dial-in connectivity, not application-scoped policy enforcement.

Explicit PAC files distributed to all internal users

Why it fails: PAC files route browser proxy traffic by URL patterns; they cannot enforce identity-based, per-application least-privileged access to private apps. They are tempting because they centralise proxy configuration, and they would be correct for directing web traffic through an explicit proxy, not for ZTNA application segmentation.

Public IP addresses assigned to every internal workstation

Why it fails: ZTNA 2.0 identifies private applications and users through the Prisma Access app connector and identity context, not workstation addressing; internal endpoints typically use private RFC 1918 addresses, so public IPs per workstation are neither required nor scalable. Public addressing matters when publishing internet-facing services, not for least-privileged private app access.

The physical desk layout of employee cubicles in branch offices

Why it fails: Compute location placement depends on user geography, latency and traffic egress requirements, not office furniture arrangement. It is tempting because branch office characteristics do inform overall design, but cubicle layout has no bearing on where Prisma Access compute nodes are deployed or how traffic is routed.

The local power grid provider utilized by the cloud data center

Why it fails: Compute location selection depends on latency, data residency and traffic routing, not on which utility supplies the data centre's electricity. It is tempting because power resilience affects data centre viability generally, but Prisma Access placement is driven by user proximity and egress requirements, not grid providers.

Cloud Access Security Broker (CASB) API connector tokens

Why it fails: CASB API connectors govern SaaS application discovery and inline/DLP policy for sanctioned apps; they play no part in the security processing chain that inspects remote-user traffic. It tempts because CASB is a Prisma Access feature, but it would be the answer only when troubleshooting SaaS visibility or data-loss rules.

GlobalProtect user username-to-IP mapping agent status

Why it fails: Username-to-IP mapping feeds user identification for policy and logging; it does not determine whether Threat Prevention profiles are applied to a session. It tempts because mapping failures cause policy mismatches, but it would be the answer only when troubleshooting user-ID-based rules, not inspection itself.

Service Connection BGP peer keepalive intervals

Why it fails: BGP keepalive intervals affect routing adjacency between service connections and remote networks, not the security policy pipeline applied to mobile-user flows. It tempts because service connection health matters for Prisma Access, but it would be the correct area only when diagnosing tunnel or route flapping, not Threat Prevention inspection.

Modify the NAT policy rules.

Why it fails: NAT policy governs address translation for traffic traversing a firewall; it does not influence how the GlobalProtect agent gathers host information or how Prisma Access evaluates HIP profiles. NAT edits suit resolving routing or translation issues. HIP troubleshooting instead inspects the agent's HIP report and match logs.

Restart the physical branch firewall.

Why it fails: Restarting a branch firewall affects on-premises enforcement, not the GlobalProtect agent's HIP report collection or Prisma Access posture evaluation for mobile users. It would be relevant when clearing a branch device's dataplane sessions. Verifying HIP requires checking the agent's HIP report and the HIP match logs.

Update the URL Filtering database.

Why it fails: URL Filtering database updates refresh web category signatures; they have no bearing on whether the GlobalProtect agent collects and submits host posture data. That task suits maintaining web security enforcement. HIP verification instead examines the endpoint's HIP report and Prisma Access HIP match events.

Verify the BGP AS number on the Service Connection.

Why it fails: BGP AS numbers govern Service Connection routing to remote networks and are unrelated to explicit proxy web traffic, which traverses the proxy rather than the BGP-peered tunnels. It is tempting because BGP misconfiguration does cause connectivity failures, but only for routed traffic, not proxy sessions.

Check the GlobalProtect client pre-logon timeout value.

Why it fails: Pre-logon timeout governs when the GlobalProtect agent establishes its tunnel before user sign-in; it has no bearing on explicit proxy web requests, which traverse the proxy independently of any GlobalProtect tunnel. It is tempting because pre-logon settings do affect connectivity in always-on VPN designs, where tunnel establishment timing genuinely causes timeouts.

Reconfigure the mobile user SAML authentication profile.

Why it fails: The mobile user SAML profile governs remote-user authentication to GlobalProtect portals and gateways, not the IKE pre-shared key or certificate used by the CPE for the site-to-site tunnel. It would be correct when mobile users cannot authenticate to Prisma Access.

Disable all security policy rules across all remote locations.

Why it fails: Disabling security policy rules removes enforcement but does not restore IKE phase 1 or phase 2 negotiation, so the tunnel stays down and traffic is left unfiltered. It would be correct when a policy rule is blocking permitted traffic after the tunnel is already established.

Restart the GlobalProtect agent on all remote user endpoints.

Why it fails: GlobalProtect is the remote-user VPN client; restarting it cannot affect an IPsec tunnel negotiated between the CPE and the Prisma Access Remote Network node, which uses IKE and static routing. It would be correct when troubleshooting remote user connectivity failures, not site-to-site tunnels.

Check the WildFire file size upload limit for malicious attachments.

Why it fails: WildFire inspects files for malware; its upload size limit has no bearing on GlobalProtect tunnel establishment, authentication or portal configuration. It is tempting because WildFire is a Prisma Access security subscription, but it would be the right check when investigating why a suspicious attachment was not detonated or blocked.

Verify the BGP AS number configured on the customer data center router.

Why it fails: BGP AS numbers govern route exchange between the customer data centre router and Prisma Access, which affects traffic forwarding after a tunnel is established, not GlobalProtect client connection establishment. It is tempting because routing misconfiguration does break connectivity, and it would be correct when troubleshooting service connection or remote network routing.

The private applications are configured with the correct FQDN or IP address and are assigned to the service connection.

Why it fails: While ensuring private applications are correctly defined is important, the question focuses on the service connection configuration. If the service connection is not associated with the right locations or the tunnel is down, even correctly defined applications will be unreachable. The two most critical service connection checks are location association and tunnel status. Application definitions are part of the overall setup but not specific to the service connection establishment.

The mobile users' GlobalProtect configuration includes the service connection's gateway address as a split tunnel exclusion.

Why it fails: Split tunnel exclusions are used to bypass the VPN for certain traffic, not to include service connection gateways. The service connection is not a GlobalProtect gateway; it is a separate tunnel for private application access. Including it as a split tunnel exclusion would actually prevent traffic from being routed through the service connection. This option misconstrues the role of split tunneling in service connection access.

The service connection's BGP configuration is advertising the private application subnets to the mobile user locations.

Why it fails: BGP is used in some service connection deployments to dynamically advertise routes, but it is not mandatory for all service connections. For basic service connections, static routes can be used. The absence of BGP does not necessarily prevent access. Therefore, verifying BGP advertisement is not a primary step unless the design specifically requires dynamic routing. The more critical checks are location association and tunnel status.

Disable SSL Decryption globally to maximize Prisma Access processing throughput across all mobile user nodes.

Why it fails: Disabling SSL decryption globally blinds inspection to encrypted threats and violates the coverage the policy must deliver, so it cannot be a best practice. It is tempting because decryption consumes processing capacity, but selective decryption with exclusions preserves both throughput and visibility.

Configure all Security Policy rules to use 'Any' application to simplify rule maintenance and reduce rule count.

Why it fails: Using 'Any' application disables App-ID enforcement, so traffic matching permitted ports bypasses application-level control and weakens security coverage. It is tempting because it shrinks rule counts, but best practice is explicit application-based rules, reserving 'Any' only for tightly scoped cases.

The SSL decryption profile applied to the Service Connection

Why it fails: An SSL decryption profile governs inspection of encrypted traffic; it does not influence route advertisement or tunnel reachability. Even a restrictive decryption profile would not cause intermittent inability to reach internal applications at the routing layer, so this is not a valid item to verify for the described symptom.

The IKEv2 pre-shared key used by the Service Connection tunnel

Why it fails: The pre-shared key authenticates the IPSec tunnel between Prisma Access and the on-premises device. If it were wrong, the tunnel would not establish at all, causing complete rather than intermittent failure. Since the users sometimes reach applications, the tunnel is up, so the pre-shared key is not the cause of intermittent reachability.

The GlobalProtect portal agent configuration for the London region

Why it fails: The GlobalProtect portal agent configuration controls how mobile users authenticate and connect to Prisma Access, not how internal routes are advertised through a Service Connection. A portal misconfiguration would affect user login or endpoint settings, not the routing of internal prefixes, so it is unrelated to the intermittent reachability of published applications.

GlobalProtect client software download URLs for mobile endpoints.

Why it fails: GlobalProtect client download URLs belong to mobile user and portal configuration, not Service Connections, which link data centres via IPSec tunnels. They are tempting because GlobalProtect is part of Prisma Access, but they are required only when deploying remote-user connectivity.

WMI probing schedules for Active Directory domain discovery.

Why it fails: WMI probing schedules belong to User-ID agent configuration for mapping IP addresses to users, not Service Connections, which need tunnel, routing, and IPSec parameters. They are tempting because User-ID is configured in Panorama, but it is irrelevant to data-centre tunnel establishment.

Deep historical scanning of files at rest stored within cloud SaaS storage repositories.

Why it fails: Historical scanning of files already at rest depends on API access to the SaaS repository, which inline traffic inspection cannot reach. It is tempting because file scanning is a real CASB function, but inline CASB acts on data in transit, not stored content.

Out-of-band remediation of externally shared links via API webhooks.

Why it fails: Remediating externally shared links via API webhooks is out-of-band behaviour, requiring the SaaS Security API to poll and act after the fact. It is tempting because link remediation is a genuine CASB capability, but inline CASB enforces at the traffic path, not through API callbacks.

Reboot the physical public cloud provider datacenter hypervisor hosting the tenant

Why it fails: Rebooting a provider hypervisor is a disruptive infrastructure action outside the administrator's remit and cannot diagnose ZTNA policy, tunnel or identity faults. It is tempting as a generic 'turn it off and on' remedy, and would be justified only if the tenant's hosting platform itself were confirmed faulty.

Reconfigure the local ISP router's BGP autonomous system number to match the Prisma Access gateway

Why it fails: Changing the local ISP router's BGP autonomous system number affects internet routing reachability, not ZTNA application access, and would likely break connectivity further. It is tempting because BGP faults do cause reachability failures, and ASN alignment matters when peering with a provider's edge.

IPsec crypto profile selection for branch offices

Why it fails: IPsec crypto profiles define encryption, hashing, and lifetime parameters for VPN tunnels, not SaaS application policies. It is tempting because crypto profiles are configured in Prisma Access, and it would be correct when hardening site-to-site or remote-access tunnel negotiation between gateways.

GlobalProtect client software version deployment rules

Why it fails: GlobalProtect version rules control which agent build endpoints receive, an endpoint-management function unrelated to SaaS application control. It is tempting because GlobalProtect is configured in Prisma Access, and it would be correct when governing agent upgrades or enforcing minimum client versions across mobile users.

WMI-based user mapping polling intervals

Why it fails: WMI polling intervals govern how User-ID collects mapping data from Windows endpoints, not SaaS traffic control. It is tempting because User-ID feeds policy enforcement, and it would be correct when tuning how frequently domain user-to-IP mappings refresh for firewall rules.

A File Blocking profile to prevent executable downloads.

Why it fails: File Blocking is not mentioned in the requirement. The goal is to inspect for threats and block risky URLs, not specifically to block file downloads. While File Blocking could be part of a broader security posture, it is not a required component for this scenario.

A Decryption policy to decrypt all SSL traffic from branch users.

Why it fails: While decryption is often necessary for full inspection, it is not explicitly required by the scenario. The requirement is to inspect for threats and block risky URLs; URL Filtering and Threat Prevention can operate on non-decrypted traffic to some extent. Decryption adds visibility but is not a mandatory component for the stated goal.

A DNS Security policy to sinkhole malicious domains.

Why it fails: DNS Security is valuable but not strictly required for URL filtering and threat inspection. The scenario focuses on web traffic inspection and URL blocking, which are handled by Security Policy rules with URL Filtering and Threat Prevention. DNS Security would add domain-level protection but is not a mandatory component for the described functionality.

Run a packet capture on the Prisma Access service connection to see if traffic arrives.

Why it fails: A packet capture on the service connection would show traffic that reaches the service connection, but if the client is not sending traffic due to missing routes, no packets will arrive. While captures can be useful, they do not directly verify the split-tunnel routes pushed to the client. The issue is likely on the client side routing, so this step is less direct and may not provide the needed insight.

Verify the user's authentication and group mapping in the Prisma Access directory sync.

Why it fails: Authentication and group mapping affect security policy enforcement, not split-tunnel route assignment. Even if the user is correctly mapped, if the split-tunnel configuration omits the internal subnet, access will fail. Therefore, checking directory sync does not address the routing problem. This action is misdirected for a split-tunnel issue.

Inspect the IPsec tunnel status between the service connection and the remote network.

Why it fails: The IPsec tunnel status between service connection and remote network is relevant for remote network connectivity, not for mobile user split-tunnel routes. Mobile users connect via GlobalProtect, which uses SSL or IPsec to the gateway, and the routing is controlled by the gateway's split-tunnel settings. Checking remote network tunnels would not reveal why a mobile user's internal access fails. This action is unrelated to the scenario.

Check the system logs for decryption-related events

Why it fails: System logs capture control-plane events, not per-session decryption details. They may show decryption profile commits or errors, but they do not indicate whether a specific user session was decrypted. Therefore, they are not useful for confirming decryption on a per-session basis.

Examine the GlobalProtect app logs on the user's endpoint for SSL errors

Why it fails: GlobalProtect app logs may show SSL errors if the endpoint does not trust the decryption certificate, but they do not confirm whether Prisma Access applied decryption. The absence of SSL errors does not prove decryption occurred; it only indicates the endpoint did not encounter certificate issues.

Use the Prisma Access CLI to run 'show session all' for the user

Why it fails: The 'show session all' command on a firewall displays active sessions and may include a decryption flag, but in Prisma Access, CLI access is limited and not typically used for per-user session verification. Traffic and decryption logs are the supported and authoritative methods.