SASE
SASE tests your ability to deliver consistent security and connectivity for mobile users, branches, and private apps from a cloud-delivered edge. Questions focus on how traffic reaches the security stack, how private apps are published, and how policy, CASB, DLP, and digital experience fit together.
Core rules
- Know the traffic paths. Mobile users connect to a closest point of presence; remote networks use IPSec or SD-WAN links; private apps are reached through service connections or ZTNA connectors.
- A service connection joins a VPC or data center to the SASE fabric for broad private access. A ZTNA connector publishes individual apps and is the better fit for limited, identity-aware access without broad network reachability.
- Security policy follows the user and device, not the office. Identity, device posture, and app become policy inputs.
- Inline CASB controls sanctioned and unsanctioned SaaS; DLP inspects content; threat prevention inspects the same flow.
- Digital experience monitoring gives hop-by-hop visibility from endpoint to app, which is how you separate SASE, ISP, and SaaS problems.
Worked example
A branch needs an internal ERP system and 200 remote laptops need one HR portal. Use a service connection for the branch because many users and apps require routed private access, and a ZTNA connector for the HR portal because it is a single app with identity-based access. Reasoning: over-publishing the HR app through a service connection widens reachability unnecessarily, while putting the whole branch behind a single-app connector does not scale.
Traps
Swapping service connection and ZTNA connector roles. Publishing more private subnets than needed. Ignoring asymmetric routing when a branch also has local internet. Assuming SASE policy is IP-based when identity and posture drive it. Forgetting that CASB API and inline CASB see different data.