Trace cloud packet paths and turn subnet, routing, and filtering decisions into testable isolation controls.
50 min 165 XPSkills: CIDR planning, Traffic-path analysis, Network isolation
Brief
Halcyon Clinics is moving an appointment service into a virtual network. The public entry tier needs inbound HTTPS, application workers need outbound updates, and patient records must never accept an internet connection. During review, the delivery lead points at three subnet names and announces that isolation is complete: one is called public, two are called private.
You must replace those labels with packet-path reasoning. Allocate non-overlapping address blocks, inspect each subnet's route-table association, distinguish an internet attachment from translated outbound access, and test both routing and filtering. The evidence must explain how a connection succeeds or fails, not merely show that a resource exists.
A route provides a possible path; a filter grants permission. Neither alone proves that a workload is reachable or isolated.
Plan address space before connecting networks
A virtual network is a logical routing boundary with one or more address ranges. An IPv4 /16 contains 65,536 addresses; a /24 contains 256. Within 10.48.0.0/16, assign 10.48.10.0/24 to entry resources, 10.48.20.0/24 to application workers, and 10.48.30.0/24 to data services. These blocks do not overlap. A /24 is not a promise of 254 usable workload addresses: managed networks may reserve additional addresses, so budget for service interfaces and growth using the platform's documented reservation rules.
CIDR boundaries matter more than visual similarity. Splitting 10.48.20.0/24 into /26 blocks yields starts at .0, .64, .128 and .192, each containing 64 addresses. The proposed 10.48.20.32/26 is not aligned. Reserve contiguous space for additional deployment zones and avoid reusing ranges already assigned to office networks or partners; translation can work around overlap, but complicates routing, logging and identity attribution.
For an address-management control, retain the approved allocation register, capacity assumptions and network inventory with collection times. Ask: can every connected network be joined without ambiguous destinations, and who approves an allocation before deployment? A diagram without the actual CIDRs cannot answer that question.
Allocate aligned, non-overlapping blocks and leave room for growth before connecting networks.
Routes distinguish public entry from outbound access
A route table maps destination prefixes to next hops. A packet for 10.48.30.8 uses a matching local network route rather than 0.0.0.0/0 because the more specific prefix wins. The effective table is the one associated with the source subnet, including any implicit association. In this room's common IPv4 model, a public subnet has a direct default route to an internet gateway. An instance still needs an appropriate public address or a public-facing intermediary and permissive filters to receive internet traffic; the route alone does not expose every interface.
A private application's default route can instead target a NAT gateway. The gateway translates source addresses and maintains mappings for outbound-initiated sessions; matching replies can return, but unsolicited inbound connections have no mapping. In this model the NAT gateway sits in the entry subnet, has a public address, and reaches the internet through that subnet's internet gateway route. The application keeps its private address. NAT is not a destination allowlist or an application firewall: an overly broad egress rule can still permit exfiltration.
The data subnet can omit a default route entirely while retaining explicit internal routes. For boundary-protection evidence, collect route entries, subnet associations, address assignments and timestamped connection tests in both directions. An auditor should ask whether the supposed private subnet can initiate traffic through the intended egress path and whether unsolicited inbound traffic actually fails.
Translated outbound access does not turn a private application's interface into an internet listener.
Private service access and peering need explicit paths
A private endpoint gives a supported managed service a private access path rather than requiring clients to use its public internet endpoint. An interface-style endpoint may use a private address such as 10.48.20.10 and private DNS resolution; other endpoint models use service-specific routes. Verify the actual model. Private transport does not replace service authentication, authorization, TLS or endpoint access policy. If DNS still resolves to a public address, the client may follow a different path despite the endpoint existing.
Peering connects two virtual networks for direct private routing, usually requiring non-overlapping CIDRs, routes in both directions and compatible filtering. If network A peers with B, and B peers with C, A does not acquire a path to C through B: peering is non-transitive. Even a manually added route cannot turn ordinary peering into a transit service. Use a supported transit design or a separate direct connection when required; do not assume peers share each other's NAT or internet gateways.
For a private-access control, correlate DNS answers, endpoint policies, service access logs and effective routes with a connection from the actual workload. Preserve peering inventories and both sides' route exports for segmentation review. Ask whether public service access is separately restricted and whether the test proves the private path rather than merely proving the service responded.
Stateful groups and stateless subnet filters
In the model used here, security groups attach to workload interfaces and contain allow rules only. They are stateful: allowing an inbound TCP connection to destination port 443 also permits its tracked response traffic without a separate reverse-direction rule. Multiple attached groups contribute their allowed traffic; an extra broad group can defeat a narrowly scoped one. No matching permission means denial, but an explicit deny rule is not available in this group model. Terminology varies across platforms, so verify semantics before translating a policy.
Network ACLs filter at the subnet boundary, are stateless, and support ordered allow and deny rules. Lowest numbered matching rule wins in this room's model; unmatched traffic is denied. Suppose a client uses source TCP port 53000 to contact a server on 443. The inbound ACL must permit destination 443 and the outbound ACL must permit destination 53000 for the reply. Production rules normally cover the documented client ephemeral range, not just that one sample port. A deny at rule 100 shadows an allow at 200 for the same packet, regardless of the allow's narrower description.
Least-privilege evidence combines group memberships, rule exports, ACL ordering, route associations and flow records. Test a permitted connection and a prohibited connection, then explain the first matching ACL rule and the relevant group permission. Ask whether a failed connection is caused by the intended control or by a missing return route; accidental outage is not durable proof of segmentation.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Private by nickname
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
An application subnet called public-app has no directly attached public addresses and routes 0.0.0.0/0 to a translating gateway in the entry subnet. That gateway has the required public address and internet path. A manager insists the application is public because its update downloads work. Separately, a proposed office connection reuses the application's CIDR; the team calls this harmless because resource names differ.
Term bank, not all of these are right
NAT gatewayinternet gatewayoverlaplatency
1.1Which gateway type provides the application's translated outbound path? (two words)
1.2What address-planning defect must be resolved before direct routing to the office? (one word)
Task 2: The invisible transit promise
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
Networks A and B are peered, and B and C are peered. A reviewer claims this makes B a transit router for A to C. Meanwhile, an application in A must call a supported managed service without its public internet endpoint; the reviewer recommends adding another internet default route and labels it private service access.
2.1Which property of peering invalidates the claimed A-to-C path? (one hyphenated word)
2.2Which service access mechanism should replace the proposed public path? (two words)
Task 3: The reply that disappeared
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
A TCP client at source port 53000 reaches a server on 443. The server's security group permits inbound 443, and the subnet ACL permits inbound 443 but denies all outbound traffic. The operator calls the ACL stateful and blames the security group for not containing an outbound response rule. Routing is correct, and packet records show the reply denied at the subnet boundary.
Term bank, not all of these are right
network ACLsecurity group53000443
3.1Which filter must be changed to permit the response at the subnet boundary? (two words)
3.2For this observed connection, what destination TCP port must its outbound response rule permit? (a number)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon Clinics needs an entry tier, private workers with update access, and isolated data services. The draft puts an internet default route on every subnet and calls that 'private because the addresses start with 10'. Replace the draft with the constrained IPv4 design in the fixture.
Complete every empty YAML field. Gateway placement and public addressing in the fixture are already implemented. Use exactly the listed CIDRs, default destinations and target labels; document the supported service's private access mechanism and the peering property that forbids chained transit.
Approved allocations and design constraints
network: 10.48.0.0/16
entry allocation: 10.48.10.0/24
application allocation: 10.48.20.0/24
data allocation: 10.48.30.0/24
internet gateway: attached
NAT gateway: in entry subnet, public address assigned
route target labels: internet-gateway | nat-gateway | none
entry: internet default required
application: translated outbound default required; public_address must be false
data: no default; write none for destination and target
service: supported private endpoint; public service path forbidden
peering: A-B and B-C only; no transit service
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Checks
Use the approved network and three subnet allocations
A change board has six networking claims to approve. Its chair says all are safe because the virtual networks use private addresses.
Judge each claim under this room's filter and routing model. Accept technically sound claims; reject unsound ones using the single most specific reason code. Treat each line independently.
Verdicts are accept or reject. Every rejection needs one reason code from: false-transit | unsupported-deny | missing-return | unproved-private-path.
Boundary review statements
CN-1 | A-B peering and B-C peering automatically allow A-C transit.
CN-2 | A worker's NAT default permits updates and matching replies, but not unsolicited inbound sessions.
CN-3 | Add an explicit deny rule to the interface security group to override its broad allow.
CN-4 | An inbound-only subnet ACL permission is sufficient for TCP replies because the ACL tracks sessions.
CN-5 | The interface private endpoint exists, so no DNS or private-path test is needed to prove clients use it.
CN-6 | An ACL deny numbered 100 shadows a matching allow numbered 200, even if the allow names a narrower source.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Cloud Fundamentals
Cloud Identity and Access
Trace principals, policy decisions and temporary sessions; constrain workloads and protect emergency access with testable controls.
