PAC Architect Registration common mistakes
PAC Architect Registration · Understand the traps and how to avoid them.
Treating Prisma Access as a single centralized firewall and sizing compute/bandwidth as if all traffic backhauls to one location, instead of designing around distributed service connections and per-region capacity.
Candidates carry over mental models from on-premises NGFW deployments and underweight the multi-tenant, region-based architecture where mobile users, remote networks, and service connections are placed in different compute locations.
What to do instead
Study the separation between the management plane and the data plane, the role of compute locations and regions, and how bandwidth is allocated per compute location. Practice mapping user populations and remote-network sites to regions and sizing each location independently before summing totals.
Confusing service connections with remote networks and choosing the wrong one for a given connectivity scenario (for example, proposing a remote network to connect a data center that must be reachable by mobile users).
Both constructs look similar on the surface, but service connections attach external networks to Prisma Access for inbound/outbound reachability, while remote networks onboard branch sites as IPsec tunnels. The exam tests scenario-to-construct matching, not definitions.
What to do instead
Build a decision table: mobile users, remote networks (branch with its own tunnel and routing), and service connections (data center or cloud VPC reachable by mobile users and remote networks). For each practice scenario, write one sentence justifying the chosen construct and the routing implications for return traffic.
Designing a deployment that ignores redundancy and high availability at the tunnel, service-connection, and compute-location levels, assuming the cloud is inherently resilient.
Candidates equate 'cloud-delivered' with 'automatically HA' and skip explicit design of dual tunnels, secondary service connections, and failover behavior for remote networks and mobile users.
What to do instead
For every scenario, explicitly state primary and secondary tunnels, whether ECMP or single-path routing applies, and what happens to sessions when a compute location or tunnel fails. Review how remote-network redundancy is configured (multiple tunnels, path monitoring) and how service connections can be duplicated across locations.
Misconfiguring routing for remote networks and service connections, such as overlapping subnets, missing static routes, or not advertising the correct prefixes, then being unable to explain why traffic fails.
The candidate understands the concepts but has not practiced the concrete configuration objects (tunnel interfaces, static routes, BGP for service connections) and does not check for address overlap between onboarded networks.
What to do instead
Practice end-to-end route tracing: source network, tunnel, virtual router, Prisma Access routing table, destination. Always check for RFC1918 overlap before onboarding. Memorize which routing options are available per construct (static and BGP for service connections; static for remote networks) and validate with the routing table views in the portal.
Skipping or misordering the onboarding workflow, for example attempting to push security policy or commit changes before service setup and license activation are complete, or ignoring the separate commit steps for different configuration areas.
The platform splits configuration into distinct commit scopes (service setup, mobile users, remote networks, security policy), and candidates who treat it as one monolithic commit get stuck or misread the resulting state.
What to do instead
Memorize the onboarding sequence: activate licenses, configure service setup (regions, compute locations, bandwidth), configure identity and mobile user settings, onboard remote networks and service connections, then author policy. Learn which changes require which commit and practice reading the task/commit status indicators.
Assuming a single security policy applies uniformly to all traffic types, instead of accounting for the separate policy scopes for mobile users, remote networks, and service connections, and the implicit rules that precede explicit ones.
Candidates study policy in the abstract and miss that Prisma Access evaluates traffic through distinct rule sets depending on the traffic source, with default and inter-zone behavior that can silently permit or deny traffic.
What to do instead
Map each traffic type to its policy scope and practice writing rules for a mobile user accessing the internet versus a branch user accessing a data center. Review decryption policy, application-based rules, and the default rules so you can predict evaluation order without guessing.
Treating identity and authentication as an afterthought, for example not planning for user identification methods (SAML/IdP, Cloud Identity Engine, authentication profiles) or forgetting that policy can depend on user and group context.
Identity is often studied as a separate topic from policy, so candidates fail scenario questions that require group-based rules or that hinge on how users are identified before policy is applied.
What to do instead
For each policy scenario, explicitly state how the user is identified and how group membership reaches the firewall. Practice writing a rule that targets a specific user group and describe the fallback behavior when identity is unavailable, including how authentication portals and profiles fit in.
Ignoring decryption and its operational consequences, such as not planning certificate distribution, exceptions for pinned or unsupported applications, or the performance impact of decrypting traffic.
Candidates focus on allow/deny rules and forget that many application-based controls and threat inspection depend on decryption, and that poor decryption design breaks user experience.
What to do instead
Design a decryption policy with explicit no-decrypt categories and exceptions, describe how the forward-trust and forward-untrust certificates are deployed to endpoints, and explain how decryption interacts with security profiles. Practice predicting which traffic will be inspected and which will bypass.
Diagnosing problems by changing configuration blindly rather than following a structured troubleshooting path from the endpoint through tunnel, routing, policy, and inspection, and not knowing which logs and tools answer which question.
Candidates memorize features but not the observability surface: traffic logs, threat logs, tunnel and IPsec status, routing tables, and the various test and connectivity tools. Without a method, they guess.
What to do instead
Build a layered checklist: is the tunnel up, is the route present, does policy match, is the session decrypted and inspected, what do the logs say. For each layer, name the specific log type or status view you would check. Practice reading traffic logs to reconstruct why a session was allowed or denied.
Overlooking performance and capacity optimization, such as not evaluating bandwidth per compute location, ignoring session and tunnel limits, or failing to consider traffic symmetry and inspection overhead when troubleshooting slowness.
Candidates treat optimization as a minor topic and cannot connect symptoms like high latency or throughput ceilings to capacity allocation, compute-location placement, or asymmetric routing.
What to do instead
Study how bandwidth is allocated and where limits apply, how compute-location choice affects latency for users and remote networks, and how asymmetric traffic paths break stateful inspection. Practice diagnosing a slowness scenario by separating capacity, path, and policy causes and recommending a concrete placement or sizing change.