LEARN. PRACTICE. GROW.1. Draw both sides of access
In the fictional exercise, a supplier needs browser access to reports while managed operators use a client with additional dependencies. Do not turn that need into generic access to an entire subnet. Describe application, protocols, names, users and device requirements. Secure Access offers different connection methods, and browser access has fewer device controls than client-based access. The choice must satisfy the access contract rather than merely open the landing page. If a requirement depends on posture not demonstrated by that method, keep acceptance open and seek a compatible option.
2. An available connector is not an available application
Connectors establish outbound connections to the cloud service and need to resolve and reach private resources. Healthy cloud-side status does not establish the internal route, correct name resolution or application port. In the worksheet, RC-A resolves the report to 10.30.0.10 but encounters a TCP timeout; RC-B resolves the same name and reaches the application. That difference locates a hypothesis along RC-A’s path. Collect per-connector results before broadening rules. Since any group connector can serve associated resources, acceptance should cover each member’s ability to reach that set.
3. Explain the rule that actually matches
An authorization failure needs the identity, device, resource and actually selected rule. In the fictional case, network object 10.30.0.0/16 overlaps specific resource 10.30.0.10. Review definitions, order and events instead of assuming the more specific name always wins. Posture requirements participate in matching; one rule no longer matching does not alone establish which rule will handle the flow. Documentation also describes a manually modified steering case where later resource changes require manual steering-address updates. Verify that configuration separately when change history matches that case.
4. Build a matrix that tests boundaries
The worksheet contains six planned tests rather than tenant measurements. It includes supplier report access, prohibited supplier SSH, managed-operator access, a device failing required posture, the path through each connector and loss of a group member. For every test, write expected result, observation, owner and decision. Missing observations remain unexecuted. Successful login does not cover all these rows. Also retain application dependencies: redirects, auxiliary names and authorized services should enter the matrix without granting an indiscriminate wildcard to hide failures.
5. Continuity and RUN handover
Two connectors on the same infrastructure do not demonstrate failure independence. If both use one resolver and one egress path, failure there can affect the group. The plan should distinguish process failure, host failure and shared dependencies, as well as remaining capacity. Actual numbers require authorized testing; the worksheet invents neither throughput nor recovery times. Give RUN maps, rules, permissions, searchable records and narrowly scoped recovery steps. The preceding lesson’s TLS lab helps interpret one layer but does not execute Secure Access. Summary: scope the resource, confirm every member’s path and accept only observed results.
RC-A: cloud healthy, expected DNS, TCP timeout. RC-B: cloud healthy, expected DNS, TCP and report work. Fictional data for diagnosis.
Common pitfalls
Online connector as complete proof; two members as no common failures; named rule as effective rule; a wildcard as universal repair.
Related topics: Zero trust · Private DNS · Resilience
Acceptance combines identity, policy, path and service, including cases that should be denied.
Reference: Private resource access · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security