A Wildcard Segment That Made the ZPA Access Policy Decorative
After retiring VPN, a retail bank runs ZPA for 900 contractors and 4,000 staff. A single application segment, *.corp.bank.internal on ports 443, 3389 and 22, covers every internal hostname. It sits in one server group whose six App Connectors are all in the Slough data centre. The Frankfurt core banking platform is 22 ms from most users but is now answered from Slough and feels slow. The access policy has three rules in this order: (1) Allow - All Users - segment *.corp.bank.internal; (2) Allow - Contractors - finance console; (3) Block - Contractors - HR. An internal audit found a contractor had opened the treasury back office, which sits under a different hostname on the same domain.
1. Explain why rule 3 never stopped the contractor, and what the ordering defect tells you about how ZPA policy is evaluated.
Read the worked answer
ZPA evaluates access policy top-down and the first matching rule wins; there is no implicit continue to the next rule. Rule 1 (Allow, All Users, the wildcard segment) matches every contractor request to any *.corp.bank.internal hostname - treasury included - so rules 2 and 3 are never evaluated. Rule 3's presence gave false assurance in reviews.
Fix the ordering: scope rule 1 to staff groups or delete it and rely on group-specific allows, put narrow contractor allows above anything broad, and keep a final Block for the contractor group as a backstop.
But the ordering is the symptom, not the disease. With one wildcard segment covering every hostname on the domain, no policy can distinguish treasury from the MES, because in ZPA the segment is the unit of authorisation. Any rule that grants the wildcard grants everything behind it. Fixing the order without splitting the segment just moves the exposure to the next broad allow someone writes.
2. Propose the segment and policy structure you would put in place, and state how you would prove the exposure is closed.
Read the worked answer
Split by application and trust level. Create segments per app - e.g. mes.corp.bank.internal:443, treasury.corp.bank.internal:443, sql-cluster:1433 - not one wildcard on three ports. Use a wildcard only where an app genuinely uses dynamic subdomains, and then pin the port and the parent domain. Note the current wildcard also quietly exposes 3389 and 22 across the whole domain, which is a much larger finding than the treasury access.
Group for policy reuse. Segment groups: 'Contractor' (MES front end only), 'Branch staff' (retail apps), 'Treasury' (its own segment, named group, posture check, optional approval workflow).
Rules, ordered: Block for high-risk groups where a backstop is needed, then narrow allows keyed to IdP groups, then staff-wide allows that never include privileged segments.
Prove it: re-test with a contractor account and confirm treasury now returns 'no matching segment' - the traffic is not even intercepted, which is stronger than a policy deny. Export the segment inventory with port lists and the matching rules as audit evidence, and check ZPA access logs for any allow events by contractor accounts outside the MES segment for the preceding 30 days.
3. Staff complain core banking is slow. Diagnose the cause and state your connector placement and resilience standard.
Read the worked answer
Cause: App Connectors only need outbound TCP 443 to the ZPA cloud and L3 reachability to the app, so they belong next to the application, not next to the users. Every Frankfurt request is currently travelling user → Zscaler enforcement node → Slough connector → Frankfurt, adding a Slough–Frankfurt leg for a platform that was 22 ms away. Latency compounds on chatty client-server protocols far more than the raw hop time suggests.
Placement: connectors in the Frankfurt data centre for core banking, in Slough for Slough-resident apps, and in regional sites for site-local apps. App Connector placement is per server group per segment - it is a per-application decision, not a global one.
Resilience standard: at least two connectors per group on separate hosts or hypervisors so patching and maintenance do not take the app down, plus a third where the app is tier-1. Monitor connector health and per-connector load in the ZPA console; a saturated single connector looks like an application problem to users.
Caveat to state honestly: the latency floor is still user → enforcement node plus node → connector. If enforcement-node selection is poor for a user cohort, adding connectors will not help - that is a Zscaler-side investigation, not a segment redesign.