Strata Cloud Manager gives Prisma Access operators a centralized view of users, branch connectivity, applications, policy, logs, and service health, but effective troubleshooting still depends on a disciplined sequence. A dashboard can show that something is unhealthy; it does not replace the need to identify the affected traffic path and prove where the failure begins.<\/p>\n
The current Security Service Edge Engineer<\/a> role includes post-deployment management and troubleshooting through Prisma Access. The most useful operational habit is to start with scope\u2014one user, one site, one private application, one region, or the whole tenant\u2014and then use Strata Cloud Manager to correlate the relevant health, identity, tunnel, route, policy, and log evidence.<\/p>\n Ask whether the issue affects one user, a user group, one branch, all branches in a location, one private application, or all traffic. Compare with a known-good user or site. A single-user problem suggests endpoint, identity, or local network state. A single branch suggests its remote-network tunnel, routing, or local edge. A broad multi-site outage points toward shared Prisma Access infrastructure, configuration, identity, or service health.<\/p>\n Capture the first failure time and any recent changes. A configuration push, ISP event, authentication change, certificate rollover, DNS update, or application migration may correlate strongly with the outage. Do not immediately push a new policy just because Strata Cloud Manager is the place where policy is edited.<\/p>\n Use Prisma Access monitoring in Strata Cloud Manager to inspect the health and connectivity of remote networks, applications, and mobile-user infrastructure. Confirm whether the relevant cloud location and connection show an active state. If the platform reports a service condition or multiple unrelated sites fail simultaneously, preserve that evidence before changing customer-managed configuration.<\/p>\n For a branch, inspect the remote-network connection and tunnel status. For private resources, inspect service connections or ZTNA Connector health as appropriate. For mobile users, determine whether the client successfully connects to the expected Prisma Access location. The general VPN troubleshooting workflow<\/a> remains useful: establish whether the secure path exists before debugging the application that depends on it.<\/p>\n A connected user can still be denied because Prisma Access sees the wrong identity, group membership, device state, or authentication result. Compare the affected user’s identity information with a working peer. Check whether the user is mapped to the expected policy population and whether a recent directory or identity-provider change altered group membership.<\/p>\n For GlobalProtect, include endpoint and gateway information in the case. For explicit proxy, verify proxy authentication and the traffic-steering method. For private applications, check whether device posture or user context is part of the security rule. Identity problems often masquerade as network problems because the user sees a timeout or denied application rather than an obvious directory error.<\/p>\n If the connection is healthy, prove the route. For remote networks, confirm branch prefixes are learned or configured and that return routes are available. For service connections, verify the private application prefix and the route back to mobile-user or branch sources. Inspect BGP state, static routes, export controls, NAT, and overlapping networks where relevant.<\/p>\n A tunnel that is green with a missing route will not pass application traffic. Likewise, a correct forward route with a different return path can create intermittent or stateful-session failures. Keep the path diagram beside the monitoring view so each tunnel and prefix has an expected role.<\/p>\n Traffic and threat logs answer questions that configuration screenshots cannot. Confirm whether the failing flow reaches Prisma Access, which source and destination are recorded, which user is associated with the session, which application is identified, which rule matches, and what action occurs. Compare those fields with a successful flow from a similar user or site.<\/p>\n The existing Palo Alto monitoring<\/a> guidance is relevant because centralized cloud security still depends on evidence. If there is no log at all, the traffic may not be reaching the expected enforcement point. If the log exists and shows deny, investigate rule logic rather than rebuilding the tunnel.<\/p>\n If policy permits the session, move to DNS and the application itself. Confirm the client resolves the expected name and that Prisma Access or the private-app connector can reach the resulting address and port. Internal applications may use split DNS, load balancers, chained APIs, or identity redirects that make the visible front-end URL only one dependency in the transaction.<\/p>\n For ZTNA Connector targets, validate connector-group health, private DNS, target state, and back-end reachability. For service-connection applications, validate data-center routing and internal firewalls. A cloud security platform cannot compensate for an application server that is down or a private DNS record that points to the wrong location.<\/p>\n Mobile-user troubleshooting must match the steering method. GlobalProtect cases should include client state, gateway, tunnel protocol, local routes, DNS, split-tunnel behavior, and endpoint posture. Explicit Proxy cases should include PAC or forwarding configuration, proxy reachability, authentication, destination eligibility, and whether the application actually honors the proxy.<\/p>\nDefine the blast radius before changing configuration<\/h2>\n
Check service and connection health first<\/h2>\n
Validate user identity and access context<\/h2>\n
Trace the tunnel and the route as separate layers<\/h2>\n
Use logs to prove which policy actually matched<\/h2>\n
Check application and DNS behavior after policy<\/h2>\n
Distinguish GlobalProtect from Explicit Proxy failures<\/h2>\n