Configure Cloud Routing and Internet Access

A subnet does not communicate with other networks simply because it exists. Routing determines where traffic goes, while security controls determine whether that traffic should be allowed.

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

In the previous lab, you created a segmented cloud network containing:

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

Now you will make that network behave like a real cloud environment.

You will configure and understand:

route tables
local routes
default routes
public internet access
internet gateways or provider equivalents
private outbound connectivity
NAT
subnet associations
traffic paths
return routes
routing troubleshooting

The objective is not simply:

Make the VM reach the internet.

The objective is:

Understand exactly how traffic leaves a workload, which routing decisions are made, which gateway is used, and why public and private subnets require different designs.

🎯 Mission Information

Item	Details
Lab	04 — Configure Cloud Routing and Internet Access
Difficulty	Beginner → Intermediate
Estimated Time	60–90 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud Routing & Internet Connectivity
Previous Lab	03 — Build a Segmented Cloud Network
Career Alignment	Cloud Administrator, Cloud Engineer, Cloud Security Engineer
Major Skills	Route Tables, Default Routes, Internet Gateways, NAT, Troubleshooting
Deliverable	Routed Cloud Network + Traffic Path Documentation

🏢 Scenario

Your three-tier network is ready.

The application team now has additional requirements.

The web tier must:

receive controlled internet traffic
access external services when required

The application tier must:

communicate with the web tier
communicate with the database tier
obtain software updates
remain directly inaccessible from the internet

The database tier must:

communicate with the application tier
remain private
avoid unnecessary direct internet exposure

Your manager asks you to configure the routing design.

The target architecture is:

                         Internet
                            |
                            v
                  Internet Gateway
                            |
                            v
                 +------------------+
                 | Public Subnet    |
                 | 10.10.10.0/24    |
                 +------------------+
                            |
                            v
                 +------------------+
                 | Application      |
                 | 10.10.20.0/24    |
                 +------------------+
                            |
                            v
                 +------------------+
                 | Database         |
                 | 10.10.30.0/24    |
                 +------------------+

For outbound private access, the application tier may use:

Application Subnet
       ↓
NAT / Outbound Gateway
       ↓
Internet

rather than receiving a public IP itself.

🎯 Lab Objectives

By completing this lab, you should be able to:

explain cloud route tables
understand destination and next-hop concepts
identify local routes
understand default routes
explain 0.0.0.0/0
understand internet-gateway concepts
identify what makes a subnet effectively public
understand private subnet routing
explain NAT
distinguish inbound and outbound internet access
configure subnet route associations
validate traffic paths
understand return routing
troubleshoot unreachable workloads
distinguish routing problems from security problems
document cloud routes professionally

🧠 Why This Lab Matters

A common beginner assumption is:

VM Has Public IP
      ↓
Internet Works

Cloud networking is more complex.

A working path may require:

Workload
   ↓
Network Interface
   ↓
Subnet
   ↓
Route Table
   ↓
Gateway
   ↓
Security Controls
   ↓
Internet

If any required component is missing, connectivity may fail.

🧠 Routing vs Security

This distinction is essential.

Routing asks:

Where should the packet go?

Security asks:

Should the packet be permitted?

A route may exist while a firewall blocks traffic.

A firewall may allow traffic while no valid route exists.

01 — Review the Existing Architecture

Your current network should resemble:

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

Confirm that these resources still exist.

🧪 Validation

Resource	Expected
Parent Network	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

02 — Understand a Route Table

A route table contains rules that tell the cloud network where traffic should go.

Each route typically contains:

Destination
+
Next Hop / Target

Example:

10.10.0.0/16
      ↓
Local

This may mean:

traffic destined for another subnet inside the same cloud network can remain within the virtual network.

03 — Understand Route Selection

Suppose a workload wants to reach:

10.10.20.15

The routing system checks the route table for the most appropriate destination match.

Conceptually:

Destination IP
      ↓
Route Table
      ↓
Best Matching Route
      ↓
Next Hop

🧠 Longest Prefix Match

Routing generally prefers the most specific applicable route.

Example:

10.10.20.0/24

is more specific than:

10.10.0.0/16

This principle becomes important in more advanced routing designs.

04 — Review the Existing Local Route

Open the route table associated with your cloud network or subnet.

Look for a route similar to:

Destination:
10.10.0.0/16

Target:
Local / Virtual Network

Provider terminology may differ.

🧠 What This Means

The route permits knowledge of destinations inside:

10.10.0.0/16

including:

10.10.10.0/24
10.10.20.0/24
10.10.30.0/24

Security controls can still restrict actual traffic.

05 — Create a Public Route Table

Create a route table for the public subnet.

Example name:

cloudplus-lab-rt-public-01

Apply your standard tags.

06 — Associate the Public Subnet

Associate:

cloudplus-lab-subnet-public-01

with:

cloudplus-lab-rt-public-01

🧠 Why Associations Matter

Creating a route table is not enough.

The subnet must actually use it.

07 — Understand the Default Route

A default IPv4 route is commonly represented as:

0.0.0.0/0

This means:

destinations not matched by a more specific route.

🧠 Example

Suppose your route table contains:

10.10.0.0/16 → Local

0.0.0.0/0 → Internet Gateway

Traffic destined for:

10.10.20.15

uses the local route.

Traffic destined for:

8.8.8.8

would use the default route.

08 — Understand the Internet Gateway

Cloud providers commonly provide a gateway mechanism that connects a virtual network to the public internet.

Conceptually:

Cloud Network
      ↓
Internet Gateway
      ↓
Internet

Different providers use different product names.

For Cloud+, focus on the concept.

09 — Create or Attach the Internet Gateway

Where required by your provider:

create the internet gateway
attach it to the cloud network

Example name:

cloudplus-lab-igw-01

📝 Record

Gateway Name:

Network:

Region:

Status:

10 — Add the Public Default Route

Add:

Destination:
0.0.0.0/0

Next Hop:
Internet Gateway

to the public route table.

The conceptual table becomes:

Destination	Target
10.10.0.0/16	Local
0.0.0.0/0	Internet Gateway

🧠 Important

This does not automatically make every workload publicly accessible.

A workload may also require:

public addressing
security rules
a listening service
appropriate OS configuration

11 — Understand What Makes a Subnet Public

A public subnet is generally one where workloads can have a direct route to/from the internet through an appropriate gateway and addressing model.

Conceptually:

Public Workload
      ↓
Public IP
      ↓
Public Subnet Route
      ↓
Internet Gateway
      ↓
Internet

🚨 Important

Do not define public subnet as:

a subnet containing public IPs.

Routing architecture is a major part of the definition.

12 — Place a Test Workload in the Public Subnet

Use the VM from Lab 02 if appropriate, or deploy a small test VM in:

10.10.10.0/24

Follow your existing naming and cost controls.

Example:

cloudplus-lab-web-01

13 — Review Its Addresses

Record:

Private IP:

Public IP:

Subnet:

Route Table:

14 — Validate Public Outbound Connectivity

Connect to the VM using your approved management path.

Test outbound connectivity to an approved external destination.

For example:

curl https://example.com

or another approved connectivity test.

🧠 Troubleshooting Reminder

If the test fails, do not immediately blame routing.

Check:

Route
Security
DNS
Application

15 — Validate DNS Separately

Test hostname resolution.

For example:

nslookup example.com

or:

dig example.com

depending on the system.

🧠 Why Test Separately?

If:

IP Connectivity Works

but:

Hostname Resolution Fails

the likely problem is DNS, not routing.

16 — Test Internet Reachability by IP

Where appropriate and permitted, test a known external IP.

This helps distinguish:

Routing

from:

DNS

17 — Understand Inbound Connectivity

Inbound communication follows the opposite direction conceptually:

Internet User
      ↓
Public IP
      ↓
Internet Gateway
      ↓
Public Subnet
      ↓
Workload

But the path must also satisfy:

network security rules
host firewall
application listener

18 — Review Administrative Exposure

If SSH is used, confirm that access is restricted.

Prefer:

Trusted Administrator IP
      ↓
TCP 22
      ↓
Web / Admin VM

instead of:

Internet
      ↓
TCP 22
      ↓
VM

from everywhere.

19 — Create the Application Route Table

Create:

cloudplus-lab-rt-app-01

Associate it with:

cloudplus-lab-subnet-app-01

20 — Review the Application Route Table

Initially, it may contain only local cloud-network routes.

For example:

Destination	Target
10.10.0.0/16	Local

This permits internal route awareness but provides no direct default internet path.

21 — Understand the Private Subnet Concept

The application subnet is intended to remain private.

A workload there should not require:

Public IP
+
Direct Public Route

for normal inbound internet access.

🧠 Private Does Not Mean Isolated

Private workloads may still need:

software updates
external APIs
package repositories

This creates the need for controlled outbound connectivity.

22 — Understand NAT

Network Address Translation can allow private workloads to initiate outbound internet connections without requiring direct public inbound exposure.

Conceptually:

Private VM
10.10.20.10
      ↓
NAT
      ↓
Public Address
      ↓
Internet

🧠 Important

NAT commonly allows:

Private → Internet

for initiated outbound sessions.

It does not automatically allow:

Internet → Private VM

as a directly initiated connection.

23 — Understand NAT Gateway / Equivalent

Cloud providers may offer managed outbound NAT services.

Conceptually:

Application Subnet
      ↓
Route Table
      ↓
NAT Gateway
      ↓
Public Network
      ↓
Internet

Provider terminology may differ.

24 — Determine Whether NAT Is Required

Ask:

Does the application subnet require outbound internet access?

If the answer is no:

do not create NAT unnecessarily.

If yes, continue.

🧠 Cost Awareness

Managed NAT services may create charges.

Review pricing before deployment.

Use only when appropriate for your lab.

25 — Create the Outbound NAT Component

Where appropriate and affordable in your lab environment:

create a NAT gateway or provider equivalent
place/configure it according to provider requirements

Example name:

cloudplus-lab-nat-01

⚠️ Alternative for Cost-Constrained Labs

If a managed NAT service would create unwanted charges, you may complete the architecture and routing analysis without leaving the resource deployed.

The learning objective is understanding:

private outbound connectivity.

26 — Add the Application Default Route

Configure the application route table conceptually as:

0.0.0.0/0
      ↓
NAT Gateway

The full table may resemble:

Destination	Target
10.10.0.0/16	Local
0.0.0.0/0	NAT Gateway

27 — Deploy or Use a Private Application VM

Create or place a small VM in:

10.10.20.0/24

Example:

cloudplus-lab-app-01

Do not assign a public IP unless your provider or lab design specifically requires one.

28 — Verify the Application VM Is Private

Record:

Private IP:

Public IP:
None / Not Assigned

Subnet:
Application

Route Table:
Application

29 — Determine How to Administer the Private VM

Because the VM has no public IP, direct SSH from the internet should not be expected.

Possible enterprise administration models include:

bastion/jump host
VPN
private management service
provider-managed session service

🧠 Architecture Lesson

Private workload administration should use:

a controlled management path.

Not:

assign a public IP temporarily every time.

30 — Understand a Bastion Concept

A bastion or jump host provides a controlled administrative path.

Conceptually:

Administrator
      ↓
Approved Public / Management Host
      ↓
Private Application VM

🚨 Important

A bastion itself must be:

hardened
restricted
monitored

31 — Validate Application Outbound Connectivity

From the private application VM, use your approved management path.

Test outbound connectivity.

If NAT is configured properly:

Private VM
      ↓
NAT
      ↓
Internet

should work.

32 — Validate the VM Has No Direct Inbound Public Path

Confirm:

no public IP
no direct internet gateway route assigned as a public workload
no unnecessary inbound exposure

🧠 Security Benefit

This reduces:

direct internet attack surface.

33 — Create the Database Route Table

Create:

cloudplus-lab-rt-db-01

Associate it with:

cloudplus-lab-subnet-db-01

34 — Decide Whether the Database Needs Internet Access

Ask:

Does the database actually require outbound internet connectivity?

Possible answer:

No.

If no requirement exists, keep the route table simple.

Example:

Destination	Target
10.10.0.0/16	Local

🧠 Least-Connectivity Principle

Do not provide network access simply because:

it might be useful later.

Provide it because:

there is a documented requirement.

35 — Understand the Database Traffic Path

The intended application path is:

Application VM
10.10.20.x
      ↓
Local Cloud Routing
      ↓
Database VM
10.10.30.x

No internet gateway is required for that communication.

36 — Understand East-West Routing

Traffic between:

10.10.20.0/24

and:

10.10.30.0/24

is east-west traffic.

This remains inside the cloud network.

37 — Understand North-South Routing

Traffic between:

Cloud Workload

and:

Internet

is generally north-south traffic.

🧠 Architecture View

Your routing now separates:

Internal Communication

from:

External Communication

38 — Build the Final Routing Architecture

Your target design may now resemble:

                              Internet
                                 |
                    +------------+-------------+
                    |                          |
                    v                          ^
             Internet Gateway                 |
                    |                          |
                    v                          |
          +--------------------+               |
          | Public Subnet      |               |
          | 10.10.10.0/24      |               |
          +--------------------+               |
                    |                          |
                    |                          |
                    v                          |
          +--------------------+               |
          | Application Subnet |------> NAT ---+
          | 10.10.20.0/24      |
          +--------------------+
                    |
                    v
          +--------------------+
          | Database Subnet    |
          | 10.10.30.0/24      |
          +--------------------+

39 — Create the Route Table Documentation

Public Route Table

Destination	Target	Purpose
10.10.0.0/16	Local	Internal Traffic
0.0.0.0/0	Internet Gateway	Internet

Application Route Table

Destination	Target	Purpose
10.10.0.0/16	Local	Internal Traffic
0.0.0.0/0	NAT	Outbound Internet

Database Route Table

Destination	Target	Purpose
10.10.0.0/16	Local	Internal Traffic

40 — Understand Route Table Associations

Document:

Subnet	Route Table
Public	cloudplus-lab-rt-public-01
Application	cloudplus-lab-rt-app-01
Database	cloudplus-lab-rt-db-01

🚨 Common Misconfiguration

A correctly configured route table associated with:

the wrong subnet

can still cause outages or exposure.

Always verify associations.

41 — Validate Public Routing

For the public workload check:

Public IP
      +
0.0.0.0/0 → Internet Gateway
      +
Required Security Rule

42 — Validate Private Application Routing

For the application workload check:

Private IP
      +
0.0.0.0/0 → NAT

where outbound internet access is required.

43 — Validate Database Routing

For the database tier verify:

Private IP
      +
Internal Routes
      +
No Unnecessary Public Path

44 — Understand Return Paths

Communication requires a valid return path.

Example:

Client
 ↓
Request
 ↓
Server
 ↓
Response
 ↓
Client

If the return path is incorrect, communication can fail even when the forward path looks valid.

🧠 Troubleshooting Principle

Always ask:

How does the response get back?

45 — Troubleshooting Scenario — Public VM Cannot Reach Internet

Use:

VM Running?
      ↓
Private/Public IP?
      ↓
Subnet?
      ↓
Route Table?
      ↓
0.0.0.0/0?
      ↓
Internet Gateway?
      ↓
Security?
      ↓
DNS?

46 — Troubleshooting Scenario — Private VM Cannot Reach Internet

Use:

Private VM
      ↓
Application Subnet
      ↓
Route Table
      ↓
Default Route
      ↓
NAT
      ↓
Public Connectivity

47 — Troubleshooting Scenario — Database Has Internet Access

Suppose the database unexpectedly reaches the internet.

Review:

route-table association
default route
public IP
NAT path
security policy

🧠 Design Question

Ask:

Is this connectivity actually required?

If not, remove it.

48 — Troubleshooting Scenario — App Cannot Reach DB

Do not immediately modify internet routing.

The communication is internal.

Check:

App IP
 ↓
App Subnet
 ↓
Internal Route
 ↓
Security Controls
 ↓
DB Service
 ↓
Return Path

49 — Troubleshooting Scenario — Hostname Fails, IP Works

This is most likely a:

DNS-related issue.

Do not modify the route table without evidence.

50 — Troubleshooting Scenario — Everything Looks Correct but Traffic Is Blocked

Remember:

Route Exists
≠
Traffic Allowed

Review security controls.

Detailed security-group work comes in the next lab.

🧠 Layered Troubleshooting

Use:

Routing
+
Network Security
+
Host Firewall
+
Application

51 — Temporarily Break the Public Route

In your isolated lab, remove or disable the public default route.

Do not modify production systems.

Attempt outbound connectivity.

Expected result:

external connectivity should fail.

52 — Investigate the Failure

Use your route table to identify the missing path.

Document:

Symptom:

Expected Route:

Observed Route:

Root Cause:

Corrective Action:

53 — Restore the Route

Restore:

0.0.0.0/0
      ↓
Internet Gateway

Validate connectivity.

🧠 Lab Principle

Breaking something deliberately teaches:

why the configuration exists.

54 — Simulate a Wrong Subnet Association

If safe in your lab, temporarily associate the application subnet with a route table that lacks its expected outbound route.

Observe the result.

Then restore the correct association.

55 — Document the Troubleshooting Case

Use:

Problem:

Affected Workload:

Expected Path:

Observed Path:

Root Cause:

Resolution:

Validation:

Lesson Learned:

56 — Build a Traffic-Path Diagram

For public internet access:

Web VM
 ↓
Public Subnet
 ↓
Public Route Table
 ↓
Internet Gateway
 ↓
Internet

For private outbound access:

App VM
 ↓
Application Subnet
 ↓
Application Route Table
 ↓
NAT
 ↓
Internet

For internal traffic:

App VM
 ↓
Local Route
 ↓
Database VM

57 — Create a Route Review Checklist

[ ] Correct subnet
[ ] Correct route table association
[ ] Internal route exists
[ ] Default route exists where required
[ ] Correct next hop
[ ] Gateway attached
[ ] NAT present where required
[ ] Public IP only where required
[ ] Return path considered
[ ] Security controls reviewed

58 — Review Cost Impact

Identify which routing components may create charges.

Potential examples include:

NAT services
gateways
data transfer
public IPs

🧠 Cost Question

Ask:

Do we need this network component running continuously for the lab?

59 — Update Your Resource Inventory

Add resources such as:

Resource	Type	Purpose	Cost Risk	Status
cloudplus-lab-rt-public-01	Route Table	Public Routing	Low	Active
cloudplus-lab-rt-app-01	Route Table	Application Routing	Low	Active
cloudplus-lab-rt-db-01	Route Table	Database Routing	Low	Active
cloudplus-lab-igw-01	Internet Gateway	Public Internet	Review	Active
cloudplus-lab-nat-01	NAT	Private Outbound	Higher	Review

60 — Review Security Architecture

Your design should now aim for:

Public Tier
      ↓
Direct Internet Route

Application Tier
      ↓
Private
      ↓
Controlled Outbound

Database Tier
      ↓
Private
      ↓
Internal Access Only

🧠 Key Security Lesson

Do not solve every connectivity requirement by:

adding a public IP.

Use architecture.

61 — Create Your Final Route Documentation

Record:

Cloud Network:
10.10.0.0/16

Public Subnet:
10.10.10.0/24

Public Default Route:
0.0.0.0/0 → Internet Gateway

Application Subnet:
10.10.20.0/24

Application Default Route:
0.0.0.0/0 → NAT

Database Subnet:
10.10.30.0/24

Database Default Route:
None unless required

Internal Route:
10.10.0.0/16 → Local

62 — Perform Final Validation

Verify:

Public VM
      ↓
Internet Access Works

Application VM
      ↓
Outbound Access Works if Required
      ↓
No Direct Public Exposure

Database
      ↓
Internal Only

🧪 Final Validation Checklist

Validation	Status
Public route table created
Public subnet associated
Internet gateway configured
Public default route created
Public VM connectivity validated
Application route table created
Application subnet associated
NAT understood/configured where required
Private outbound path validated
Database route table created
Database subnet associated
No unnecessary DB internet route
Internal route reviewed
Return path understood
Broken route tested
Troubleshooting documented
Resource inventory updated

63 — Cleanup Decision

Keep the network architecture if you are continuing the Cloud+ lab sequence.

You will need it for the next labs.

Retain:

Virtual Network
Public Subnet
Application Subnet
Database Subnet
Route Tables
Internet Gateway

⚠️ Cost-Sensitive Resource

If your NAT service is billable and is not required between labs:

delete it after documenting the configuration.

You can recreate it when required.

🎯 Certification Connection

A common Cloud+ scenario might say:

A private VM cannot download operating-system updates.

Think:

Private IP
 ↓
Subnet
 ↓
Route Table
 ↓
Default Route
 ↓
NAT
 ↓
Internet

Another question might say:

A public VM has a public IP but is unreachable.

Do not assume the public IP alone is enough.

Review:

Public IP
+
Route
+
Gateway
+
Security
+
Service

🎤 Interview Questions

Practice answering without notes.

1. What does a route table do?

2. What is a default route?

3. What does `0.0.0.0/0` mean?

4. What is a next hop?

5. What is an internet gateway?

6. What makes a subnet public?

7. What is a private subnet?

8. What is NAT?

9. Why use NAT for private workloads?

10. Does NAT automatically allow inbound internet access?

11. What is a route-table association?

12. Why does the return path matter?

13. Routing vs firewall policy?

14. Why might a database subnet have no internet route?

15. How would you troubleshoot a public VM that cannot reach the internet?

16. How would you troubleshoot a private VM that cannot reach the internet?

17. Why shouldn’t every cloud VM have a public IP?

18. What is north-south traffic?

19. What is east-west traffic?

20. What is longest prefix match?

🚨 Scenario Interview Question 1

A VM has a public IP but cannot reach the internet.

Investigate:

VM
 ↓
Subnet
 ↓
Route Table
 ↓
Default Route
 ↓
Internet Gateway
 ↓
Security
 ↓
DNS

🚨 Scenario Interview Question 2

A private application server needs access to software repositories.

Do not automatically assign a public IP.

Consider:

Private VM
 ↓
NAT
 ↓
Internet

🚨 Scenario Interview Question 3

A database server has 0.0.0.0/0 pointing to an internet gateway.

Ask:

Does the database actually need this route?

Review:

workload requirement
public addressing
security controls
attack surface

🚨 Scenario Interview Question 4

App and database servers are in the same virtual network but cannot communicate.

Do not assume an internet gateway problem.

Check:

Internal Route
 ↓
Security Rules
 ↓
Host Firewall
 ↓
Database Service
 ↓
Return Path

🚨 Scenario Interview Question 5

The network team created a NAT gateway, but the private VM still cannot reach the internet.

Check:

correct route table
0.0.0.0/0 target
subnet association
NAT placement/configuration
upstream internet path
DNS/security controls

🚨 Scenario Interview Question 6

A web VM can reach an external IP but cannot resolve domain names.

Likely focus:

DNS.

Do not modify routing without evidence.

🚨 Scenario Interview Question 7

A route table was correctly configured, but the subnet still uses a different route table.

The likely issue is:

route-table association.

🧠 Cloud Routing Interview Framework

Use:

Source
 ↓
Subnet
 ↓
Route Table
 ↓
Destination Match
 ↓
Next Hop
 ↓
Gateway
 ↓
Security
 ↓
Destination
 ↓
Return Path

💬 Interview Tip

Avoid:

“If the VM cannot reach the internet, I would add 0.0.0.0/0.”

A stronger answer is:

“I would first determine whether the workload is intended to be public or private, verify the subnet and route-table association, review the destination route and next hop, confirm the required gateway or NAT path exists, and then validate security controls, DNS, and the return path before making any routing changes.”

That demonstrates Cloud Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized versions of the following.

1. Routing Architecture Diagram

Show:

Public → Internet Gateway
Private → NAT
Database → Internal Only

2. Route Table Matrix

Document every route table and association.

3. Public vs Private Design

Explain why different tiers use different routes.

4. Troubleshooting Case

Document one deliberately broken route and your resolution process.

5. Cost Review

Explain which components may create ongoing cost.

📝 Resume Examples

Instead of:

Configured cloud routing.

Use:

Designed and validated cloud routing across public, application, and database subnets using local routes, default routes, internet-gateway connectivity, and controlled private outbound access through NAT.

Or:

Troubleshot cloud connectivity by validating subnet placement, route-table associations, destination routes, gateway configuration, security controls, DNS, and return paths.

⭐ Job-Readiness Check

You should now be able to:

explain route tables
identify route destinations
explain next hops
understand local routes
explain default routes
understand 0.0.0.0/0
explain internet gateways
distinguish public and private subnets
explain NAT
design private outbound internet access
associate route tables with subnets
understand return routing
troubleshoot missing routes
distinguish DNS from routing issues
distinguish routing from security-control problems
document a cloud traffic path clearly

🏆 Mission Complete

You have now progressed from:

Cloud Network

to:

Routed Cloud Architecture
      ↓
Public Internet Access
      ↓
Private Outbound Access
      ↓
Internal Tier Communication

The key lesson from this lab is:

Routing provides the path. Security determines whether that path should be used.

A professional cloud engineer understands both.

🚀 What’s Next?

Your traffic now has valid network paths.

The next question is:

Which traffic should actually be permitted?

The next lab moves into cloud network security.

You will work with:

security groups
virtual firewalls
inbound rules
outbound rules
source restrictions
destination restrictions
service and port controls
least-privilege network access
public exposure
security-rule validation
broken-rule troubleshooting

You will move from:

Can Traffic Get There?

to:

Should Traffic Be Allowed?

➡️ Next: Lab 05 — Cloud Security Groups and Network Access Controls