Prisma Access (ZTNA)
Prisma Access (ZTNA) tests how you replace network-level remote access with identity- and posture-based access to private applications. The exam expects component knowledge, traffic-path reasoning, and policy logic.
Core components and path
- App Connector: outbound-only component deployed close to private apps; it creates tunnels to Prisma Access and never needs inbound firewall openings.
- Service connection: connects a data center or headquarters network to Prisma Access for broad private access; it is not an App Connector.
- Identity: user and group data come from the IdP via SAML/SCIM; policy matches users/groups, not IP subnets.
- Device posture: the Prisma Access agent or browser context supplies posture; access can be allowed, denied, or limited continuously.
- Traffic flow: user to nearest Prisma Access PoP, then App Connector, then private app. The app is never exposed to the internet.
Policy rules
ZTNA policy binds source identity/group, device posture, destination app, and action. App definitions use FQDN, protocol, and port. Default deny applies. High availability needs at least two App Connectors.
Worked example
A finance user in group Finance opens an internal ERP app. The IdP asserts group membership, the device is compliant, and the app definition matches erp.corp.example:443. The ZTNA rule allows the session through the App Connector. A contractor authenticates successfully but is not in Finance; the rule does not match, so default deny blocks access. Reasoning: authentication is necessary but not sufficient; authorization comes from group and posture matching.
Traps
- Treating an App Connector as a service connection.
- Assuming ZTNA needs inbound NAT or a public app IP.
- Checking only login, not posture or continuous trust.
- Forgetting that App Connector HA requires redundant connectors.