Build a Segmented Cloud Network

Cloud networking is not only about giving workloads IP addresses. A well-designed cloud network separates workloads by purpose, trust level, and exposure so that only required communication is allowed.

Welcome to Lab 03 of the CompTIA Cloud+ practical lab sequence.

In the previous lab, you deployed and managed a cloud virtual machine.

You worked with:

compute
operating systems
virtual disks
network interfaces
private IP addresses
public IP addresses
administrative access
monitoring
VM lifecycle
troubleshooting

Now you will move deeper into cloud networking.

The objective of this lab is to build:

Cloud Virtual Network
        |
        ├── Public Subnet
        |
        ├── Application Subnet
        |
        └── Database Subnet

This structure introduces one of the most important ideas in cloud architecture:

Different workloads should not automatically live in the same network or have the same level of exposure.

🎯 Mission Information

Item	Details
Lab	03 — Build a Segmented Cloud Network
Difficulty	Beginner → Intermediate
Estimated Time	60–90 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud Networking & Segmentation
Previous Lab	02 — Deploy and Manage a Cloud Virtual Machine
Career Alignment	Cloud Administrator, Cloud Engineer, Cloud Security Engineer
Major Skills	CIDR, Subnets, Segmentation, Workload Placement, Traffic Flows
Deliverable	Segmented Cloud Network + Network Design Documentation

🏢 Scenario

Your development team is expanding the lab environment.

The application will eventually contain:

an internet-facing web tier
an internal application tier
a database tier

Your manager does not want all systems placed into the same flat network.

Instead, you have been asked to design a basic three-tier cloud network.

The expected architecture is:

Internet
   ↓
Public Subnet
   ↓
Application Subnet
   ↓
Database Subnet

The requirements are:

web resources may require controlled internet exposure
application resources should remain private
database resources should remain private
network ranges must not overlap
addressing must be documented
communication requirements must be clearly defined

🎯 Lab Objectives

By completing this lab, you should be able to:

explain cloud virtual networks
understand CIDR notation
plan a cloud network address range
create multiple subnets
distinguish public and private subnet concepts
understand workload placement
explain network segmentation
create a traffic-flow matrix
document IP address allocation
understand routing boundaries
validate subnet creation
identify common segmentation mistakes
troubleshoot basic subnet-placement issues
explain the design during a technical interview

🧠 Why This Lab Matters

A beginner may design:

Cloud Network
      |
      ├── Web Server
      ├── Application Server
      ├── Database
      └── Management

Everything exists in one network.

That may work technically.

But it provides limited separation.

A more mature design uses:

Cloud Network
      |
      ├── Public / Web Tier
      |
      ├── Application Tier
      |
      ├── Database Tier
      |
      └── Management Tier

This improves:

organization
traffic control
security
troubleshooting
architecture clarity

🧠 Segmentation Principle

A useful principle is:

Separate systems that have different trust levels or communication requirements.

01 — Understand the Cloud Virtual Network

Cloud providers offer logically isolated networking environments.

Depending on the platform, they may be called:

Virtual Private Cloud
Virtual Network
VPC/VNet
project network

Provider terminology differs.

The underlying concept is:

Cloud Environment
      ↓
Virtual Network
      ↓
Subnets
      ↓
Workloads

🧠 Provider-Neutral Thinking

For Cloud+, focus on:

Address Space
 ↓
Subnets
 ↓
Routes
 ↓
Security Controls
 ↓
Workloads

rather than memorizing one provider’s console.

02 — Review CIDR Notation

CIDR defines IP network ranges.

Example:

10.10.0.0/16

This describes an IPv4 network.

A /16 provides a much larger range than a /24.

🧠 Simple Comparison

/16
Large Network

/24
Smaller Network

/28
Much Smaller Network

For this lab, exact provider-reserved addresses may vary.

The objective is understanding:

how a larger network is divided into smaller subnets.

03 — Choose the Parent Network

For this lab, use an example parent range such as:

10.10.0.0/16

This will represent:

the entire Cloud+ lab network.

📝 Record

Cloud Network Name:
cloudplus-lab-net-01

CIDR:
10.10.0.0/16

Environment:
Lab

Purpose:
CompTIA Cloud+ Network Labs

04 — Plan the Subnets Before Creating Them

Do not immediately click:

Create Subnet.

First create an addressing plan.

A simple plan:

Subnet	Purpose	CIDR
Public	Internet-facing workloads	10.10.10.0/24
Application	Internal application workloads	10.10.20.0/24
Database	Database workloads	10.10.30.0/24

🧠 Address Planning

This gives you:

10.10.0.0/16
    |
    ├── 10.10.10.0/24
    │      Public
    |
    ├── 10.10.20.0/24
    │      Application
    |
    └── 10.10.30.0/24
           Database

05 — Check for Overlapping Networks

Subnet ranges must not overlap.

Good:

10.10.10.0/24
10.10.20.0/24
10.10.30.0/24

Incorrect:

10.10.10.0/24
10.10.10.0/25

if they are being created as independent sibling subnets inside the same address space.

🧠 Why Overlap Is a Problem

Routing depends on knowing:

which network owns the destination IP.

Overlapping addressing creates ambiguity and operational complexity.

06 — Understand the Public Subnet Concept

A public subnet is typically a network intended for workloads that may need controlled external connectivity.

Conceptually:

Internet
   ↓
Public Routing
   ↓
Public Subnet
   ↓
Web Workload

🚨 Important

A subnet does not become securely public merely because it has a route to the internet.

Security also depends on:

workload addressing
network security rules
firewalls
services
authentication

07 — Understand the Private Application Subnet

The application tier should generally not require unrestricted inbound internet access.

Conceptually:

Web Tier
   ↓
Required Application Port
   ↓
Application Tier

The application tier may still require outbound connectivity for:

updates
APIs
dependencies

but this should be controlled according to design requirements.

08 — Understand the Database Subnet

The database tier should generally have the narrowest exposure.

Concept:

Application Tier
      ↓
Required Database Service
      ↓
Database Tier

Avoid:

Internet
   ↓
Database

unless there is a specific and carefully controlled architecture requiring it.

🧠 Database Security Principle

Ask:

Which application actually needs to communicate with this database?

Then design access around that requirement.

09 — Create the Virtual Network

Navigate to the virtual-networking service.

Create the primary network using your documented plan.

Example:

Name:
cloudplus-lab-net-01

CIDR:
10.10.0.0/16

Region:
Primary Lab Region

10 — Apply Tags

Use the standards from Lab 01.

Example:

Tag	Value
Environment	Lab
Course	CompTIA-CloudPlus
Purpose	Networking
Owner	Student

11 — Create the Public Subnet

Create:

Name:
cloudplus-lab-subnet-public-01

CIDR:
10.10.10.0/24

Purpose:
Public / Web Tier

12 — Create the Application Subnet

Create:

Name:
cloudplus-lab-subnet-app-01

CIDR:
10.10.20.0/24

Purpose:
Application Tier

13 — Create the Database Subnet

Create:

Name:
cloudplus-lab-subnet-db-01

CIDR:
10.10.30.0/24

Purpose:
Database Tier

14 — Verify All Subnets

You should now have:

cloudplus-lab-net-01
      |
      ├── cloudplus-lab-subnet-public-01
      │      10.10.10.0/24
      |
      ├── cloudplus-lab-subnet-app-01
      │      10.10.20.0/24
      |
      └── cloudplus-lab-subnet-db-01
             10.10.30.0/24

🧪 Validation Table

Subnet	CIDR	Created?
Public	10.10.10.0/24
Application	10.10.20.0/24
Database	10.10.30.0/24

15 — Understand Reserved Addresses

Cloud providers may reserve some addresses inside each subnet.

Do not assume every IP in a /24 is always available for workload assignment.

🧠 Cloud+ Principle

Always check:

provider-specific reserved addresses

before doing detailed capacity planning.

16 — Understand Workload Placement

Now decide where different workload types belong.

Use:

Workload	Recommended Tier
Internet-facing Web Server	Public
Application Server	Application
Database	Database
Management Workload	Separate/Controlled Management Tier

🧠 Placement Matters

A workload’s network placement determines:

which routes apply
which controls apply
which systems can reach it
how exposed it may become

17 — Place the Previous VM Into the Design

The VM from Lab 02 may conceptually become:

cloudplus-lab-vm-01
      ↓
Public Subnet

if you are using it as a temporary web/administrative workload.

If your cloud platform makes moving an existing VM between networks difficult, you do not need to rebuild it purely for this lab.

Document its intended placement.

18 — Build the Logical Application Architecture

Your target design is now:

Internet
   ↓
Public Subnet
10.10.10.0/24
   ↓
Application Subnet
10.10.20.0/24
   ↓
Database Subnet
10.10.30.0/24

19 — Create the Traffic Requirements

Before creating security controls, define what communication should be required.

Example:

Internet
   ↓
HTTPS
   ↓
Web Tier

Web Tier
   ↓
Application Service
   ↓
Application Tier

Application Tier
   ↓
Database Service
   ↓
Database Tier

20 — Build a Traffic-Flow Matrix

Create:

Source	Destination	Service	Required?
Internet	Web Tier	HTTPS	Yes
Internet	App Tier	Any	No
Internet	Database	Any	No
Web Tier	App Tier	Application Port	Yes
Web Tier	Database	Database Port	Usually No
App Tier	Database	Database Port	Yes
Database	Internet	Unrestricted	Review

🧠 Why Build the Matrix First?

Security rules become easier when you know:

what the application actually needs.

Do not begin with:

Allow Any
 ↓
Any

and tighten later if you can design correctly first.

21 — Understand North-South Traffic

North-south traffic generally refers to traffic entering or leaving the environment.

Example:

Internet
   ↓
Web Tier

22 — Understand East-West Traffic

East-west traffic generally refers to communication between internal workloads or tiers.

Example:

Web
 ↓
Application
 ↓
Database

🧠 Security Importance

Many attacks begin externally but then move:

east-west.

Segmentation can reduce lateral movement.

23 — Understand Routing Between Subnets

Different subnets require routing to communicate.

Conceptually:

10.10.10.0/24
      ↓
Routing
      ↓
10.10.20.0/24

In many cloud environments, local routes may be automatically provided inside the same virtual network.

🚨 Important

Routing enables a path.

It does not necessarily mean:

traffic should be allowed.

Security policy is a separate decision.

24 — Review the Default Route Table

Locate the network’s routing information.

Look for:

local network routes
internet/default routes if configured
subnet associations where applicable

🧠 Routing Question

Ask:

If a workload in the application subnet sends traffic to the database subnet, which route will be used?

25 — Document Existing Routes

Create:

Destination	Next Hop / Target	Purpose
10.10.0.0/16	Local/Internal	Inter-subnet

Do not add an internet route yet unless your provider requires it for your intended design.

That comes deeper in the next lab.

26 — Understand Internet Routing

Internet access commonly involves some combination of:

Subnet
 ↓
Route Table
 ↓
Internet Gateway / Equivalent
 ↓
Internet

The exact terminology varies by provider.

🧠 Important

A route such as:

0.0.0.0/0

commonly represents:

all IPv4 destinations not matched by a more specific route.

27 — Do Not Make Every Subnet Public

Avoid:

Public Subnet
Application Subnet
Database Subnet
      ↓
Internet Gateway
      ↓
Direct Public Exposure

unless the design explicitly requires it.

🛡️ Better Principle

Public Tier
      ↓
Controlled Internet Exposure

Application Tier
      ↓
Private

Database Tier
      ↓
Private

28 — Understand Private Subnet Internet Access

Private workloads may still need outbound access for:

package updates
external APIs
software repositories

This can be provided through controlled outbound mechanisms without directly exposing those workloads inbound.

You will explore this further in:

Lab 04 — Configure Cloud Routing and Internet Access

29 — Consider a Management Tier

An enterprise design may also use:

Cloud Network
      |
      ├── Public
      ├── Application
      ├── Database
      └── Management

A possible management range could be:

10.10.40.0/24

For this lab, you do not need to deploy it unless desired.

Document it as:

future architecture.

🧠 Why Separate Management?

Administration has a different trust requirement from application traffic.

Prefer:

Approved Administrator
      ↓
Management Path
      ↓
Workload Administration

rather than exposing administration throughout the normal user/application network.

30 — Plan for Availability

In a production architecture, you may eventually distribute workloads across multiple failure domains.

Example:

Region
 |
 ├── Zone A
 │    ├── Public Subnet
 │    ├── App Subnet
 │    └── DB Subnet
 |
 └── Zone B
      ├── Public Subnet
      ├── App Subnet
      └── DB Subnet

🧠 For This Lab

Keep the design simple.

You will explore high availability later in the Cloud+ lab sequence.

31 — Review Subnet Capacity

A /24 provides far more addresses than this small lab requires.

That is acceptable for learning.

But in enterprise planning, consider:

expected workload growth
reserved addresses
load balancers
scaling
management interfaces

🧠 Capacity Planning Principle

Do not size a subnet only for:

what exists today.

Consider:

what may exist later.

32 — Create an IP Address Plan

Use:

Tier	CIDR	Example Workload IP
Public	10.10.10.0/24	10.10.10.10
App	10.10.20.0/24	10.10.20.10
DB	10.10.30.0/24	10.10.30.10
Management	10.10.40.0/24	Future

33 — Create a Workload Inventory

Plan:

Workload	Tier	Public IP Needed?
Web VM	Public	Possibly
App VM	Application	No
DB VM	Database	No
Admin VM	Management	Review

🧠 Public IP Principle

Do not assign public IP addresses because:

it makes administration easier.

Use them only when the architecture requires them.

34 — Review Security Boundaries

Your network now contains three trust areas.

Internet
  |
  v
[ PUBLIC ]
  |
  v
[ APPLICATION ]
  |
  v
[ DATABASE ]

🧠 Trust Principle

As you move deeper into the environment:

exposure should generally become more restricted.

35 — Identify Potential Attack Paths

Consider this poor design:

Internet
 ↓
Web Server
 ↓
Database

If the web server is compromised and has unrestricted database access, the attacker may gain a direct path to sensitive data.

🛡️ Better Design

Internet
 ↓
Web Tier
 ↓
Required App Service
 ↓
Application Tier
 ↓
Required DB Service
 ↓
Database

Each step becomes an opportunity to enforce:

routing
network policy
authentication
logging

36 — Perform a Segmentation Review

Ask:

Public Tier

Should it communicate directly with the database?

Usually:

No.

Application Tier

Should it be reachable directly from the internet?

Usually:

No.

Database Tier

Should users directly connect?

Usually:

No.

37 — Build a Segmentation Checklist

[ ] Public subnet created
[ ] Application subnet created
[ ] Database subnet created
[ ] Networks do not overlap
[ ] App tier intended as private
[ ] DB tier intended as private
[ ] Traffic requirements documented
[ ] Public IP requirements documented
[ ] Network routes reviewed
[ ] Management access considered

38 — Validate the Cloud Console

Confirm that your provider shows all expected network resources.

Check:

Virtual Network
      ↓
Three Subnets
      ↓
Correct CIDRs
      ↓
Correct Region
      ↓
Correct Tags

39 — Inspect Subnet Associations

Where applicable, identify which:

route table
security control
availability location

is associated with each subnet.

Record:

Subnet	Route Table	Security Association	Zone
Public
Application
Database

40 — Identify Default Resources

Your cloud provider may automatically create:

default routes
default network rules
default ACLs

🧠 Important

Do not assume:

default = secure.

Review what the defaults actually allow.

41 — Identify Unnecessary Default Networks

Some providers may automatically create a default cloud network.

You may now have:

Default Network
+
cloudplus-lab-net-01

Do not delete provider defaults unless:

you understand their use
nothing depends on them
deletion is appropriate for your lab

🧠 Operational Principle

Do not delete resources simply because:

you did not create them.

Understand dependencies first.

42 — Simulate a Workload Placement Decision

Your manager asks:

Where should we deploy an internet-facing web application?

Answer:

Public-facing tier/subnet, with controlled internet routing and security policy.

43 — Simulate an Application Placement Decision

Your manager asks:

Where should the internal application service run?

Answer:

Application/private subnet.

44 — Simulate a Database Placement Decision

Your manager asks:

Where should the production database be deployed?

Answer:

Private database tier with access limited to required application sources.

45 — Simulate a Bad Architecture

Consider:

Internet
 ↓
Public IP
 ↓
Database

Ask:

What risks does this create?

Potential concerns:

unnecessary exposure
direct attack surface
brute-force attempts
vulnerability targeting

46 — Troubleshooting Scenario — VM in Wrong Subnet

Suppose a database VM was accidentally deployed into:

Public Subnet

instead of:

Database Subnet

Do not only change a security rule.

First identify:

workload placement is incorrect.

🧠 Root Cause Thinking

Differentiate:

Security Rule Problem

from:

Architecture / Placement Problem

47 — Troubleshooting Scenario — Overlapping Address Plan

Suppose someone proposes:

Public:
10.10.20.0/24

Application:
10.10.20.0/25

Identify the overlap before deployment.

🧠 Cloud Engineer Habit

Architecture review before deployment prevents:

expensive rework later.

48 — Troubleshooting Scenario — Wrong CIDR

Suppose your parent network is:

10.10.0.0/16

and someone attempts to create:

10.20.10.0/24

inside it.

This child range is outside the parent network.

The provider should reject it or require another address space.

49 — Build the Final Network Diagram

Create:

                   Internet
                      |
                      v
              Public Connectivity
                      |
                      v
          +----------------------+
          | Public Subnet        |
          | 10.10.10.0/24        |
          | Web Tier             |
          +----------------------+
                      |
                      | Required Application Traffic
                      v
          +----------------------+
          | Application Subnet   |
          | 10.10.20.0/24        |
          | Application Tier     |
          +----------------------+
                      |
                      | Required DB Traffic
                      v
          +----------------------+
          | Database Subnet      |
          | 10.10.30.0/24        |
          | Database Tier        |
          +----------------------+

50 — Create the Network Design Record

Document:

Network Name:
cloudplus-lab-net-01

Parent CIDR:
10.10.0.0/16

Public Subnet:
10.10.10.0/24

Application Subnet:
10.10.20.0/24

Database Subnet:
10.10.30.0/24

Management Subnet:
Future / Optional

Primary Region:

Purpose:
CompTIA Cloud+ Lab

Segmentation Strategy:
Three-Tier

51 — Create the Communication Requirements

Document:

Internet → Web:
Required

Internet → Application:
Not Required

Internet → Database:
Not Required

Web → Application:
Required

Web → Database:
Not Required

Application → Database:
Required

Management → Workloads:
Controlled Administrative Access

52 — Review Security Expectations

Although detailed network security rules come in Lab 05, define expectations now.

Public Tier

Potentially:

Internet
 ↓
HTTPS
 ↓
Web

Application Tier

Potentially:

Web Tier
 ↓
Required Application Port
 ↓
App

Database Tier

Potentially:

Application Tier
 ↓
Required Database Port
 ↓
Database

🧠 Design Before Configuration

This is an important professional habit:

Application Requirement
      ↓
Traffic Flow
      ↓
Architecture
      ↓
Security Policy

not:

Create Random Rules
      ↓
See What Works

53 — Update Your Resource Inventory

Add:

Resource	Type	CIDR	Purpose	Cleanup Status
cloudplus-lab-net-01	Virtual Network	10.10.0.0/16	Cloud+ Lab	Active
cloudplus-lab-subnet-public-01	Subnet	10.10.10.0/24	Public Tier	Active
cloudplus-lab-subnet-app-01	Subnet	10.10.20.0/24	App Tier	Active
cloudplus-lab-subnet-db-01	Subnet	10.10.30.0/24	DB Tier	Active

54 — Capture Evidence

Capture sanitized evidence of:

virtual network
CIDR
public subnet
application subnet
database subnet
tags
route-table view where applicable

Do not expose:

account identifiers
secrets
private credentials

55 — Perform Final Validation

Verify:

Correct Account
      ↓
Correct Region
      ↓
Network Created
      ↓
Parent CIDR Correct
      ↓
Public Subnet Correct
      ↓
Application Subnet Correct
      ↓
Database Subnet Correct
      ↓
No Overlap
      ↓
Traffic Flows Documented

🧪 Final Validation Checklist

Validation	Status
Virtual network created
Parent CIDR correct
Public subnet created
Application subnet created
Database subnet created
No overlapping CIDRs
Region verified
Tags applied
Workload placement defined
Public/private intent documented
Traffic-flow matrix created
Routing reviewed
Management tier considered
Architecture diagram created
Resource inventory updated

56 — Cleanup Decision

Unlike the VM lab, do not immediately delete this network if you plan to continue the Cloud+ sequence.

The following labs will build on it.

Retain:

cloudplus-lab-net-01

cloudplus-lab-subnet-public-01

cloudplus-lab-subnet-app-01

cloudplus-lab-subnet-db-01

unless you are intentionally ending the lab environment.

🧠 Lab Dependency

These resources will support later exercises involving:

routing
internet access
security groups
DNS
load balancing
three-tier applications

🎤 Interview Questions

Practice without notes.

1. What is a cloud virtual network?

2. What is CIDR?

3. Why do we subnet a cloud network?

4. What is network segmentation?

5. What is a public subnet?

6. What is a private subnet?

7. Why should a database normally be private?

8. What is a three-tier architecture?

9. What is north-south traffic?

10. What is east-west traffic?

11. Why should subnet ranges not overlap?

12. What does a route table do?

13. Does routing automatically mean traffic is allowed?

14. Why separate application and database tiers?

15. Why create a traffic-flow matrix before firewall rules?

16. What is workload placement?

17. Why should not every VM have a public IP?

18. What is the purpose of a management subnet?

19. What is lateral movement?

20. How can segmentation reduce security risk?

🚨 Scenario Interview Question 1

An application has web, application, and database components. How would you segment them?

A strong answer:

Public / Web Tier
      ↓
Application Tier
      ↓
Database Tier

Then limit communication to required services between tiers.

🚨 Scenario Interview Question 2

A database server has been deployed into the public subnet.

Do not simply say:

block the internet.

Discuss:

workload placement
private subnet
required application sources
public IP removal where applicable
security-policy review

🚨 Scenario Interview Question 3

The web server needs to reach the database.

Ask first:

Does the architecture actually require direct Web → Database communication?

If not, prefer:

Web
 ↓
Application
 ↓
Database

🚨 Scenario Interview Question 4

Two subnets cannot communicate.

Investigate:

Source IP
 ↓
Subnet
 ↓
Route
 ↓
Security Policy
 ↓
Destination
 ↓
Return Path

🚨 Scenario Interview Question 5

A developer wants all workloads in one subnet because it is easier.

Explain the operational and security benefits of segmentation:

clearer architecture
reduced exposure
better policy enforcement
smaller blast radius

🚨 Scenario Interview Question 6

A private application server needs software updates from the internet.

Do not automatically assign it a public IP.

Consider controlled outbound connectivity.

This will be explored in the next lab.

🧠 Cloud Networking Interview Framework

Use:

Requirement
 ↓
Network
 ↓
Subnet
 ↓
Workload Placement
 ↓
Route
 ↓
Security Policy
 ↓
Validation

💬 Interview Tip

Avoid:

“I would create three subnets because that is best practice.”

A stronger answer is:

“I would first understand the application’s trust boundaries and communication requirements. I would place internet-facing resources in the public tier, application workloads in a private application tier, and databases in a more restricted private tier. I would then define required traffic flows, routing, and security controls so each tier can communicate only as required.”

That demonstrates Cloud Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized copies of:

1. Network Architecture Diagram

Show:

Internet
 ↓
Public
 ↓
Application
 ↓
Database

2. IP Address Plan

Include:

parent CIDR
subnet CIDRs
purpose

3. Traffic-Flow Matrix

Document required communication.

4. Workload Placement Table

Show where different systems belong.

5. Segmentation Checklist

Document your design review.

📝 Resume Examples

Instead of:

Created cloud subnets.

Use:

Designed a segmented cloud network using dedicated public, application, and database subnets with documented CIDR planning, workload placement, trust boundaries, and traffic-flow requirements.

Or:

Built a three-tier cloud-network architecture and documented east-west and north-south communication requirements to support least-privilege network-security controls.

⭐ Job-Readiness Check

You should now be able to:

explain cloud virtual networks
understand CIDR
create a basic IP addressing plan
create subnets
identify overlapping ranges
explain public and private subnet concepts
place workloads appropriately
explain three-tier architecture
understand basic routing concepts
distinguish routing from security policy
document traffic flows
explain north-south traffic
explain east-west traffic
identify risky public exposure
explain why databases should usually be private
create a network architecture diagram

🏆 Mission Complete

You have now moved from:

Single VM

to:

Structured Cloud Network
      ↓
Public Tier
      ↓
Application Tier
      ↓
Database Tier

The most important lesson from this lab is:

Cloud-network design begins with communication requirements and trust boundaries—not with firewall rules.

A well-designed network makes later security easier.

🚀 What’s Next?

Your subnets now exist, but you have not yet fully defined:

how traffic gets in, out, and between the networks.

The next lab focuses on routing and internet connectivity.

You will work with:

route tables
default routes
internet gateways or equivalents
public connectivity
private subnet outbound access
NAT concepts
route associations
traffic-path validation
broken-route troubleshooting

You will follow:

Workload
 ↓
Subnet
 ↓
Route Table
 ↓
Gateway / Next Hop
 ↓
Destination

➡️ Next: Lab 04 — Configure Cloud Routing and Internet Access