Virtual network
A fictional customer-defined cloud network boundary containing subnets, routes, security controls, endpoints, and connected services.
High School IntermediateModule I13Lesson 4 of 8
I13.4 Cloud Networking and Service Exposure
Learn how defenders interpret fictional virtual networks, subnets, routes, gateways, load balancers, private endpoints, public paths, security rules, segmentation, egress, DNS, flow evidence, service dependencies, and practical reachability without touching any real cloud network.
Lesson Progress
Cloud Networking and Service Exposure
High School Intermediate • I13: Cloud Security Basics • Lesson 4 of 8
50% complete
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Private Endpoint Can Exist while a Wider Route Still Remains
The fictional Northbridge Learning Cloud uses private endpoints for databases and storage, but one storage collection also remains reachable through a wider provider-service route. The export function has a general outbound route beyond its documented destinations. One private-service subnet lacks flow-log coverage. These records support design and monitoring gaps, but they do not independently prove public access, data use, or disclosure.
Weak exposure analysis
Find one public-capable feature or broad route, declare the service exposed, and remove controls without checking return paths, identities, applications, or dependencies.
Professional exposure analysis
Calculate effective reachability, correlate observed traffic, preserve authentication and impact limits, map dependencies, and stage a reversible, monitored change.
Objective 1
Explain fictional virtual networks, subnets, routes, gateways, load balancers, private endpoints, security rules, service exposure, segmentation, and network trust boundaries.
Objective 2
Evaluate fictional inbound and outbound reachability by correlating architecture, route, rule, endpoint, identity, application, DNS, flow, and business evidence.
Objective 3
Distinguish public capability, public addressability, practical reachability, authenticated access, service use, and confirmed impact.
Objective 4
Design fictional segmentation and service-exposure improvements with named owners, approvals, staged validation, rollback, monitoring, and completion evidence.
Objective 5
Create a portfolio-safe fictional cloud network exposure package with asset maps, dependency diagrams, findings, alternatives, confidence, limitations, and owner decisions.
Why This Matters
Cloud Exposure Is the Result of Several Controls, Not One Checkbox
A fictional cloud service may have a public address but remain unreachable because no route or rule permits the source. A private endpoint may exist while a wider alternate route remains. A network path may succeed but application authorization may still deny the action. Strong analysis therefore connects intended architecture, effective routes, security controls, service policies, identities, application permissions, observed traffic, source health, and business dependencies.
Core Concept
Use the Source–Path–Control–Service Model
Source
Which fictional user, workload, subnet, partner, administrator, service, or recovery process starts the connection?
Path
Which fictional address, DNS record, route, gateway, endpoint, load balancer, subnet, and return path carry the traffic?
Control
Which fictional rules, resource policies, identities, conditions, application permissions, and explicit denies apply?
Service
Which fictional application or data function is reached, what business need exists, and what evidence supports observed use or impact?
Key Vocabulary
Cloud Networking and Exposure Terms
Subnet
A fictional segment of a virtual network used to group workloads, services, and network controls by purpose or trust level.
Route table
A fictional set of rules that determines where network traffic is sent based on destination, next hop, and network design.
Gateway
A fictional network service that connects a cloud network to the internet, another network, a provider service, or a private connection.
Load balancer
A fictional service that receives traffic and distributes it to approved application targets according to health and routing rules.
Private endpoint
A fictional customer-controlled network interface that provides private access to a managed cloud service.
Public endpoint
A fictional service address that may be reachable through a public network path when routing, security, service policy, and authentication permit it.
Security rule
A fictional allow or deny control applied to a subnet, interface, workload, gateway, or service under documented conditions.
Network segmentation
Dividing a fictional environment into smaller trust zones to reduce unnecessary communication and limit failure or incident spread.
North-south traffic
Fictional traffic entering or leaving a cloud environment, application boundary, or external trust zone.
East-west traffic
Fictional traffic moving between internal workloads, subnets, services, or application tiers.
Service exposure
The fictional practical ability of a user, system, network, or identity to reach and interact with a cloud service.
Reachability
Whether a fictional source can establish the required network path to a destination under effective routes, rules, gateways, endpoints, and service controls.
Flow record
A fictional summary of a network relationship such as source, destination, protocol, ports, action, bytes, duration, and time.
Egress
Fictional outbound traffic from a workload, subnet, application, or cloud service toward another destination.
Dependency map
A fictional record of which applications, services, networks, identities, data stores, monitoring systems, and recovery processes depend on one another.
Network Components
Eight Components and Their Defensive Boundaries
Public application edge
Purpose
Receives fictional learner traffic through an approved public service and forwards only expected application requests.
Strong controls
Approved public entry, health checks, encrypted connection concept, application filtering, limited back-end targets, logging, and owner review.
Common gap
Administrative or internal services are accidentally attached to the same public path.
Review evidence
Architecture, listener configuration, target groups, health checks, DNS, access logs, and change records.
Application subnet
Purpose
Hosts fictional application workloads that process approved user requests.
Strong controls
Restricted inbound from the public edge, restricted outbound to required services, workload identities, monitoring, and segmentation.
Common gap
Broad outbound access or unrestricted communication to unrelated internal services.
Review evidence
Subnet routes, interface rules, workload inventory, flow records, application dependencies, and owner requirements.
Private service subnet
Purpose
Hosts fictional internal APIs, processing services, database interfaces, and storage endpoints.
Strong controls
No direct public path, limited application-tier access, private name resolution, service-specific rules, and detailed monitoring.
Common gap
A wide provider-service route or shared rule allows more sources than the approved architecture requires.
Review evidence
Private endpoints, route tables, rules, DNS, flow records, service policy, and dependency map.
Administrative path
Purpose
Supports fictional approved maintenance, troubleshooting, configuration, and incident-response access.
Strong controls
Separate identity, approval, temporary access, controlled source, session monitoring, narrow destinations, and expiration.
Common gap
Permanent administrative reachability from broad user networks or daily-use identities.
Review evidence
Access request, privileged session, source network, route, rule, target, approval, and expiration.
Private endpoint
Purpose
Provides fictional private network access to managed storage, database, identity, logging, or other provider services.
Strong controls
Approved subnets, private DNS, limited resource policy, route validation, source restrictions, and flow monitoring.
Common gap
A private endpoint exists, but the resource also remains reachable through a wider path.
Review evidence
Endpoint configuration, service policy, DNS records, routes, resource policy, flow logs, and application configuration.
Internet gateway or public route
Purpose
Supports fictional approved public services and outbound connectivity under controlled conditions.
Strong controls
Only approved subnets and services, narrow security rules, monitored egress, documented business purpose, and owner approval.
Common gap
A default route appears in a subnet that was intended to remain private.
Review evidence
Route table, gateway attachment, subnet association, interface address, rules, flow records, and owner design.
Service gateway or provider route
Purpose
Connects fictional workloads to managed provider services without using the normal public internet path.
Strong controls
Limited service destinations, approved source subnets, resource policy, monitoring, and private design review.
Common gap
The route is wider than the documented service dependency and increases reachable resource scope.
Review evidence
Gateway policy, route, service destination, source subnet, resource policy, flow records, and business requirement.
Network monitoring path
Purpose
Collects fictional flow, DNS, load-balancer, gateway, endpoint, and service-access records for defense and investigation.
Strong controls
Source coverage, delivery health, protected storage, retention, owner, detection rules, and review.
Common gap
A subnet or endpoint is outside flow coverage, making negative conclusions unreliable.
Review evidence
Logging configuration, source matrix, delivery status, retention, access, alert history, and source-health records.
Exposure Analysis
Eight Questions before Calling a Service Exposed
Is the fictional service addressable?
Strong method
Identify public or private addresses, names, endpoints, interfaces, load balancers, and provider service paths.
Analysis risk
Treating the existence of a public-capable service as proof of practical reachability.
Which routes make the path possible?
Strong method
Map source subnet, route association, next hop, gateway, destination prefix, provider route, and return path.
Analysis risk
Reviewing only security rules while ignoring routing.
Which security rules apply?
Strong method
Evaluate fictional subnet, interface, workload, load-balancer, gateway, endpoint, and service controls together.
Analysis risk
Assuming one allow rule is enough when another layer denies or narrows the path.
Which identity or application controls remain?
Strong method
Separate network reachability from authentication, authorization, resource policy, application role, and object access.
Analysis risk
Treating a reachable service as proof that data or functions are accessible.
What does DNS or service discovery show?
Strong method
Use fictional name resolution to understand intended destination and path while preserving cache, source, and coverage limits.
Analysis risk
Treating name resolution as proof of successful connection or use.
What do flow and application records show?
Strong method
Correlate fictional source, destination, action, bytes, duration, process or service, request, response, and identity.
Analysis risk
Treating a flow record as proof of payload content or human intent.
Which dependencies require the path?
Strong method
Connect fictional business workflow, application tier, data store, monitoring, recovery, administration, and third-party needs.
Analysis risk
Removing a route or rule without understanding service continuity.
How will the change be validated?
Strong method
Use fictional staged rollout, owner approval, expected success and failure cases, rollback, monitoring, and completion evidence.
Analysis risk
Making a one-step network change with no recovery or observation plan.
Segmentation Zones
Six Fictional Trust Zones
Public edge zone
Assets
Fictional public load balancer, content-delivery service, and approved public DNS.
Allowed paths
Public user traffic to approved listeners and health checks to approved targets.
Blocked paths
Direct public access to private application, database, storage, monitoring, and administration services.
Evidence
Listener rules, target mapping, DNS, access logs, health checks, security rules, and architecture.
Application zone
Assets
Fictional learning portal workloads and export orchestration services.
Allowed paths
Public edge to application listeners; application to required private services and monitoring.
Blocked paths
Unnecessary peer-to-peer traffic, direct database administration, and broad outbound access.
Evidence
Subnet routes, workload rules, application dependencies, identities, flow records, and change approvals.
Data zone
Assets
Fictional managed database, confidential object storage, and approved private service endpoints.
Allowed paths
Approved application and recovery identities from documented private paths.
Blocked paths
Direct public access, unrelated workloads, broad partner paths, and unapproved administrative sources.
Evidence
Private endpoints, resource policies, database rules, storage policies, DNS, and flow records.
Management zone
Assets
Fictional temporary administration service, deployment control, and security operations access.
Allowed paths
Approved privileged identities from controlled sources for limited time and documented tasks.
Blocked paths
Daily user traffic, broad standing access, direct public management, and unmonitored sessions.
Evidence
Access request, identity activation, source network, route, rule, session log, and expiration.
Monitoring zone
Assets
Fictional audit, flow, DNS, detection, and security-event storage.
Allowed paths
Cloud services writing approved records and security operations reading under least privilege.
Blocked paths
Application modification of logs, public access, and unapproved deletion or retention changes.
Evidence
Source configuration, delivery, access, retention, health, alert, and integrity records.
Recovery zone
Assets
Fictional backup vault, recovery targets, configuration archives, and restoration workflow.
Allowed paths
Protected service identities and approved recovery administrators during tests or incidents.
Blocked paths
Routine application write access, broad network paths, and shared administrative credentials.
Evidence
Backup network path, identity, key, restore plan, test record, monitoring, and owner approval.
Network Review
Northbridge Fictional Network and Exposure Records
NLC-NET-01
learning-public-edge
Source
Public network
Destination
Application load balancer
Path
Public DNS → approved listener → application targets
Controls
Encrypted connection concept, health checks, narrow listener, application logging
Finding
The public entry matches the approved learner-facing service design.
Limitation
Application security and user authorization require separate evidence.
NLC-NET-02
application-subnet
Source
Application workloads
Destination
Private database and storage endpoints
Path
Application subnet → private service subnet
Controls
Service-specific rules and private DNS
Finding
The primary application-to-data path is private and limited to required services.
Limitation
One wider provider-service route remains available.
NLC-NET-03
archive-secondary-storage
Source
Application subnet
Destination
Managed object-storage service
Path
Private endpoint plus wider provider-service route
Controls
Resource policy and role authorization
Finding
The wider route increases network reachability beyond the approved private-only design.
Limitation
Public internet reachability and object access are not established.
NLC-NET-04
student-progress-database
Source
Application and recovery zones
Destination
Managed database private interface
Path
Private DNS and private endpoint
Controls
Narrow source rules, database identities, encrypted connection concept
Finding
The database path aligns with the confidential-data design.
Limitation
Query authorization and database logging require separate review.
NLC-NET-05
temporary-admin-service
Source
Management zone
Destination
Application and data administration interfaces
Path
Approved temporary session through controlled source
Controls
Just-in-time role, expiration, session monitoring, target restrictions
Finding
The temporary path is safer than broad standing administrative reachability.
Limitation
The last emergency-path validation is overdue.
NLC-NET-06
export-function-egress
Source
Export automation
Destination
Approved storage and monitoring services
Path
Private endpoints and provider-service gateway
Controls
Destination restriction and workload identity
Finding
The function has an additional general outbound route not required by the documented workflow.
Limitation
No supplied flow shows use of the additional route.
NLC-NET-07
monitoring-pipeline
Source
Cloud services and network components
Destination
Restricted monitoring workspace
Path
Service delivery path
Controls
Protected destination, retention, security-operations access
Finding
Flow logging is missing for one private-service subnet.
Limitation
Negative network conclusions for that subnet are weaker until coverage is restored.
NLC-NET-08
partner-integration
Source
Fictional school partner
Destination
Approved application API
Path
Partner identity → public API edge → limited application route
Controls
Approved partner role, request logging, rate limits, and application authorization
Finding
The current partner path is documented, but the role expiration is approaching.
Limitation
Network reachability does not prove access to unrelated application functions.
Defensive Workflow
Complete a Fictional Cloud Exposure Review
Confirm the fictional network question
Restate the approved services, sources, destinations, identities, data, accounts, regions, time window, owners, evidence, privacy limits, and prohibited real-network actions.
Output: Network-review objective and scope.
Build the architecture and dependency map
Record fictional virtual networks, subnets, routes, gateways, endpoints, load balancers, services, DNS, identities, applications, data stores, monitoring, and recovery dependencies.
Output: Cloud network and dependency diagram.
Calculate effective reachability
Compare fictional addressability, routes, return paths, security rules, endpoint policies, resource policies, identity controls, application authorization, and source conditions.
Output: Reachability and exposure matrix.
Correlate observed traffic
Use fictional DNS, flow, gateway, load-balancer, application, identity, storage, database, and source-health records to distinguish capability from observed use.
Output: Observed-traffic and evidence-correlation table.
Evaluate segmentation and egress
Compare fictional public edge, application, data, management, monitoring, and recovery zones with required inbound, east-west, and outbound paths.
Output: Segmentation and egress gap register.
Test alternatives and impact
Consider fictional operational exceptions, migration paths, recovery needs, provider routes, application dependencies, and compensating controls without overstating exposure.
Output: Alternatives, confidence, limitations, and impact boundaries.
Plan safe network changes
Assign fictional owners, approvals, staged rules or routes, expected tests, rollback, monitoring, communication, residual risk, and completion evidence.
Output: Cloud network remediation plan.
Review and communicate
Confirm fictional evidence lineage, source health, change control, privacy, reviewer approval, owner decisions, and portfolio-safe reporting.
Output: Reviewed service-exposure package.
Fake Dashboard
Fake Northbridge Cloud Network Dashboard
Training dashboard for fictional network evidence only.
Network assets reviewed
8
Public edge, application, data, administration, export, monitoring, recovery, and partner paths are mapped.
Exposure gaps
4
Wider storage route, general function egress, missing flow coverage, and overdue emergency validation require action.
Confirmed public data paths
0
The supplied fictional evidence supports design gaps but no confirmed public data-service path.
Fake SOC Alert
Private Storage Also Has a Wider Provider-Service Route
Source: Fake Cloud Network Review Console • Time: 11:06 AM
The fictional archive-secondary storage service has an approved private endpoint, but the application subnet also has a wider provider-service route that can address the service.
Defensive recommendation: Confirm route and return path, endpoint and resource policies, identity and application authorization, owner requirement, observed flows, source health, and dependencies. Do not claim public access or disclosure. Stage route reduction, validate expected application success and denied alternate paths, preserve rollback, monitor, and document completion.
Fake Log Panel
Fake Northbridge Network Review Records
training-log-viewer.log
09:00 REVIEW scope='cloud networking and exposure' 09:08 MAP zones='public,application,data,management,monitoring,recovery' 09:14 EDGE listener='approved' private_data_targets='none' 09:21 ROUTE storage='private endpoint + provider-service route' 09:28 EGRESS export-function='general outbound route present' 09:35 FLOW private-service-subnet='logging missing' 09:42 ADMIN access='temporary' session='monitored' test='overdue' 09:49 DNS database='private name' storage='private name' 09:56 FLOW observed='application to approved storage and database' 10:02 FINDING public_data_path='not supported' 10:12 FINDING wider_route='supported' use='not proven' 10:20 ACTION owners='network,application,storage,identity,monitoring' 10:32 VALIDATE expected='allow approved path' denied='alternate path' 10:44 ROLLBACK route='preserved' monitoring='enabled' 11:06 PORTFOLIO fictionalization='required'
Training note: this is fake data for defensive analysis practice only.
Findings Matrix
Northbridge Network Findings and Limits
NLC-NET-F01
The fictional learner-facing public edge is limited to the approved application entry and does not directly expose the private data services.
HighEvidence support
Architecture, DNS, listener configuration, target groups, subnet routes, security rules, and access logs.
Alternative
An undocumented alternate path is possible but not supported by the supplied records.
Limitation
Application-layer vulnerabilities and user authorization are outside this network-only conclusion.
NLC-NET-F02
Archive-secondary storage remains reachable through a wider provider-service route in addition to the approved private endpoint.
HighEvidence support
Route table, endpoint configuration, provider-service gateway policy, storage policy, application subnet association, and owner design.
Alternative
The route may support an undocumented operational exception.
Limitation
Public internet reachability, object access, and disclosure are not established.
NLC-NET-F03
The export function has a general outbound route beyond the documented storage and monitoring destinations.
Medium-HighEvidence support
Function subnet route, workload inventory, destination requirement, endpoint map, flow coverage, and application owner record.
Alternative
A software-update or provider dependency may require controlled outbound access, but no approved requirement is supplied.
Limitation
No supplied flow record shows use of the general outbound route.
NLC-NET-F04
One private-service subnet lacks flow-log coverage, reducing confidence in negative network conclusions for that zone.
HighEvidence support
Logging configuration, source matrix, subnet association, delivery status, retention, and security-operations ownership.
Alternative
Application or provider service logs may supply partial evidence.
Limitation
Missing flow coverage does not prove suspicious activity.
NLC-NET-F05
The temporary administration path follows stronger controls than permanent broad administrative reachability, but its emergency validation is overdue.
HighEvidence support
Identity activation, source restriction, routes, target rules, session monitoring, expiration, and test schedule.
Alternative
Normal administrative paths may remain sufficient, but emergency readiness still requires validation.
Limitation
No real emergency access or live validation is performed.
NLC-NET-F06
The safest correction requires coordinated application, network, storage, identity, monitoring, change, and recovery owners.
HighEvidence support
Dependency map, route ownership, endpoint ownership, workload identity, storage policy, logging ownership, rollback, and validation requirements.
Alternative
A single-team change may be faster but risks service disruption or incomplete evidence.
Limitation
Final implementation depends on approved fictional change procedures.
Analyze the Evidence
What Does the Wider Storage Route Prove?
The fictional storage collection has a private endpoint.
The application subnet also has a provider-service route that can address the storage service.
The storage resource policy and workload role still control object access.
Observed flow records show the approved application using the private path.
No supplied flow, application, identity, or storage record supports public internet use or external disclosure.
The approved architecture expects private-only service access.
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Cloud Network Exposure Analysis
Treating the existence of a public-capable fictional service as proof that the resource is publicly reachable.
Reviewing only security rules and ignoring routes, return paths, gateways, endpoints, service policies, identities, and application authorization.
Treating DNS resolution as proof of successful connection or service use.
Treating a flow record as proof of payload content, user intent, or data disclosure.
Treating a private endpoint as proof that no wider provider or public path exists.
Treating one allowed port as proof that every source can reach the destination.
Ignoring east-west traffic, service-to-service dependencies, administrative paths, monitoring, and recovery networks.
Removing a route or rule without validating application, provider, update, backup, monitoring, and recovery dependencies.
Assuming no flow event means no activity without verifying source health, coverage, retention, and expected event generation.
Leaving broad outbound access because inbound access appears restricted.
Using the same fictional network zone for public applications, private data, administration, monitoring, and recovery.
Changing network exposure without named owners, approvals, staged validation, rollback, monitoring, and completion evidence.
Confusing network reachability with identity authorization, resource permission, application access, or business impact.
Using or exposing any real cloud network, subnet, route, gateway, endpoint, address, DNS name, log, account, owner, or private data.
Safe Practice Lab
Build the Northbridge Cloud Network Exposure Review
Your fictional assignment
Architecture, Reachability, Segmentation, Findings, and Change Plan
Use only the supplied fictional Northbridge records to complete an end-to-end cloud networking and exposure review.
Required deliverables
- Virtual-network, subnet, route, gateway, endpoint, load-balancer, DNS, and service map.
- Application, identity, data, monitoring, administration, recovery, and partner dependency map.
- Effective reachability matrix with return paths and service controls.
- Segmentation-zone and egress review.
- Observed-flow and source-health correlation table.
- Findings with alternatives, confidence, limitations, and impact boundaries.
- Staged network change plan with approval, tests, rollback, monitoring, and completion evidence.
- Technical summary, leadership summary, and portfolio-safety statement.
Do not scan, connect to, test, capture from, or modify any real cloud network. Complete the lab only with fictional records displayed in this lesson.
Scenario Decision Lab
A Wider Route Exists, but No Public Use Is Supported
The fictional storage service has both a private endpoint and a wider provider-service route, while observed traffic uses the private path.
Scenario Decision Lab
The Export Function Has General Outbound Access
The fictional export function requires only approved storage and monitoring destinations but also has a general outbound route.
Defender Habits
Cloud Networking and Service-Exposure Checklist
Check Your Understanding
I13.4 Mini Quiz: Cloud Networking and Service Exposure
Choose your answers first. Explanations appear only after submission.
1. What determines fictional effective network reachability?
2. What does a fictional private endpoint prove?
3. What can a fictional flow record most directly support?
4. Which statement about a wider provider-service route is strongest?
5. Why should fictional outbound access be reviewed?
6. What is the safest way to reduce a fictional network path?
7. What makes a fictional cloud networking finding defensible?
Portfolio Prompt
Portfolio Prompt
Create a fictional Cloud Networking and Service-Exposure Review for the Northbridge Learning Cloud. Include architecture, virtual networks, subnets, routes, gateways, endpoints, load balancers, DNS, trust zones, dependencies, effective reachability, inbound and outbound paths, flow evidence, source health, findings, alternatives, confidence, limitations, staged remediation, validation, rollback, monitoring, and a portfolio-safety statement.
Use only fictional networks, addresses, DNS names, routes, endpoints, services, identities, logs, owners, dates, and decisions.
Do not treat public capability, one route, one rule, DNS resolution, or a flow record as proof of confirmed public use or disclosure.
Map both intended architecture and effective reachability.
Make every network change approved, staged, reversible, validated, monitored, and documented.
Key Takeaways
What You Should Remember
1.Cloud service exposure depends on addressability, routing, return paths, rules, endpoints, service policies, identities, and application authorization.
2.A private endpoint can coexist with a wider alternate path.
3.A public-capable service is not automatically publicly reachable or usable.
4.DNS and flow evidence provide useful network context but do not independently prove payload, intent, or impact.
5.Segmentation should separate public, application, data, administration, monitoring, and recovery trust zones.
6.Outbound access deserves the same careful ownership and validation as inbound access.
7.Portfolio artifacts should use fully fictional cloud network evidence and never expose real architecture or addresses.
Navigation