Cloud Security Groups and Network Access Controls

Routing decides whether a network path exists. Security controls decide whether traffic is allowed to use that path.

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

In the previous lab, you configured:

route tables
default routes
internet connectivity
private outbound access
NAT concepts
subnet associations
traffic-path validation

You can now answer:

Can traffic reach the destination?

This lab introduces the next question:

Should that traffic be allowed?

You will build and validate cloud network-security controls around the architecture created in the previous labs.

The target environment is:

Internet
   ↓
Public / Web Tier
   ↓
Application Tier
   ↓
Database Tier

Your goal is to transform that architecture into:

Internet
   ↓
HTTPS Only
   ↓
Web Tier
   ↓
Required Application Port Only
   ↓
Application Tier
   ↓
Required Database Port Only
   ↓
Database Tier

🎯 Mission Information

Item	Details
Lab	05 — Cloud Security Groups and Network Access Controls
Difficulty	Beginner → Intermediate
Estimated Time	60–90 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud Network Security
Previous Lab	04 — Configure Cloud Routing and Internet Access
Career Alignment	Cloud Administrator, Cloud Engineer, Cloud Security Engineer
Major Skills	Security Groups, Inbound/Outbound Rules, Least Privilege, Troubleshooting
Deliverable	Least-Privilege Cloud Network Policy + Validation Report

🏢 Scenario

Your organization has completed the basic cloud-network design.

The application contains:

public web workloads
private application workloads
private database workloads

Routing is already configured.

However, the current network-security rules are too broad.

Your manager asks you to implement a least-privilege access model.

The requirements are:

Internet
   ↓
HTTPS
   ↓
Web Tier

Web Tier
   ↓
Application Service
   ↓
Application Tier

Application Tier
   ↓
Database Service
   ↓
Database Tier

Everything else should be reviewed and restricted unless there is a documented requirement.

🎯 Lab Objectives

By completing this lab, you should be able to:

explain cloud security groups
understand virtual-firewall concepts
distinguish inbound and outbound rules
define source and destination controls
use protocol and port restrictions
implement least-privilege network access
restrict administrative access
identify excessive public exposure
understand stateful firewall behavior conceptually
distinguish security groups from routing
distinguish network controls from host firewalls
validate allowed and denied traffic
troubleshoot broken security rules
document traffic requirements
explain cloud-network security during interviews

🧠 Why This Lab Matters

A route such as:

0.0.0.0/0
   ↓
Internet Gateway

creates a network path.

But that does not mean every port should be reachable.

A weak design might allow:

Internet
   ↓
ANY
   ↓
Web Server

A better design starts with:

Internet
   ↓
TCP 443
   ↓
Web Server

The principle is:

Allow only the communication required for the workload to function.

01 — Understand Cloud Security Groups

Cloud providers commonly provide virtual network-security controls attached to:

instances
network interfaces
subnets
workloads

Provider terminology varies.

Conceptually:

Traffic
   ↓
Cloud Security Policy
   ↓
Allow / Deny
   ↓
Workload

🧠 Provider-Neutral Thinking

For CompTIA Cloud+, focus on:

Source
+
Destination
+
Protocol
+
Port
+
Direction
=
Security Decision

02 — Understand Inbound Rules

Inbound rules control traffic entering a protected resource.

Example:

Source:
Internet

Protocol:
TCP

Port:
443

Destination:
Web Server

Action:
Allow

03 — Understand Outbound Rules

Outbound rules control traffic leaving a protected resource.

Example:

Source:
Application Server

Destination:
Database

Protocol:
TCP

Port:
Database Service

Action:
Allow

The exact control model depends on the provider.

04 — Understand Stateful Firewall Concepts

Many cloud security-group implementations behave statefully.

Conceptually:

Client
   ↓
Allowed Request
   ↓
Server
   ↓
Return Traffic

The return traffic may be automatically recognized as part of the established connection.

🧠 Important

Do not assume every cloud network control behaves exactly the same.

Some controls may be:

stateful
stateless
workload-level
subnet-level

Always understand the provider’s implementation.

05 — Review the Existing Network

Confirm:

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

06 — Review the Traffic Requirements

Before creating security rules, use the traffic matrix from Lab 03.

A recommended starting point:

Source	Destination	Service	Required?
Internet	Web	HTTPS	Yes
Internet	Web	SSH	Restricted
Internet	App	Any	No
Internet	DB	Any	No
Web	App	Application Service	Yes
Web	DB	Database	No
App	DB	Database Service	Yes
Admin	Workloads	Management	Controlled

🧠 Security Rule Design

Use:

Business Requirement
      ↓
Required Traffic
      ↓
Security Rule

not:

Allow Everything
      ↓
Application Works
      ↓
Try to Secure Later

07 — Create a Web-Tier Security Group

Create a security policy for the public web workload.

Example name:

cloudplus-lab-sg-web-01

Apply your standard tags.

08 — Allow HTTPS to the Web Tier

Create:

Direction:
Inbound

Source:
Internet / Approved Sources

Protocol:
TCP

Port:
443

Action:
Allow

🧠 Why TCP 443?

HTTPS commonly uses:

TCP 443

This allows encrypted web traffic.

09 — Review HTTP Requirement

Ask:

Does the application require TCP 80?

If HTTP is required only for redirecting users to HTTPS, document that requirement.

If not:

do not open it unnecessarily.

10 — Restrict SSH Administration

Administrative access should be restricted.

Prefer:

Trusted Admin Source
      ↓
TCP 22
      ↓
Web VM

Avoid:

0.0.0.0/0
      ↓
TCP 22
      ↓
Web VM

where a narrower source is practical.

11 — Record the Web-Tier Rules

Example:

Direction	Source	Protocol	Port	Purpose
Inbound	Internet	TCP	443	HTTPS
Inbound	Trusted Admin IP	TCP	22	Administration

12 — Review Web-Tier Outbound Access

Ask what the web workload actually needs outbound.

Possible requirements:

application-tier communication
DNS
software updates
logging

Avoid assuming:

unrestricted outbound access is always necessary.

13 — Create an Application-Tier Security Group

Create:

cloudplus-lab-sg-app-01

The application tier should not accept direct arbitrary internet traffic.

14 — Allow Web-to-App Traffic

Suppose your lab application uses a test service on:

TCP 8080

Then conceptually allow:

Source:
Web Tier

Destination:
Application Tier

Protocol:
TCP

Port:
8080

🧠 Important

Use the actual port required by your application.

Do not copy port 8080 into production designs simply because it appears in this lab.

15 — Prefer Security-Group Referencing Where Supported

Some cloud platforms allow one security group or workload identity to be used as the source instead of a broad IP range.

Conceptually:

Web Security Group
      ↓
TCP 8080
      ↓
Application Security Group

This can be easier to maintain than hard-coding many workload IPs.

16 — Block Direct Internet-to-App Access

Validate that the application tier does not have a rule like:

Internet
   ↓
ANY
   ↓
Application Server

The target design is:

Internet
   X
Application Tier

for direct inbound access.

17 — Review Administrative Access to the App Tier

The private application VM should ideally use a controlled management path.

For example:

Administrator
   ↓
Bastion / VPN / Managed Session
   ↓
Application VM

not:

Internet
   ↓
SSH
   ↓
Private App VM

18 — Create a Database-Tier Security Group

Create:

cloudplus-lab-sg-db-01

This should be the most restrictive tier in the current design.

19 — Define the Database Service

For a lab database, identify the actual service port.

Examples may include database technologies using ports such as:

TCP 3306
TCP 5432
TCP 1433

Use only the one required by your chosen test environment.

🚨 Important

Do not open every database port.

20 — Allow App-to-Database Traffic

Conceptually:

Application Tier
      ↓
Required Database Port
      ↓
Database Tier

Example:

Source:
Application Security Group

Protocol:
TCP

Port:
Database Service

21 — Deny Web-to-Database Communication

Your desired architecture is:

Web
   X
Database

unless the application design explicitly requires direct communication.

🧠 Why This Matters

If a public web workload is compromised, direct database access creates a shorter attack path.

Prefer:

Web
 ↓
Application
 ↓
Database

22 — Deny Direct Internet-to-Database Access

Verify:

Internet
   X
Database

There should be no unnecessary public database exposure.

23 — Build the Final Security Model

Your desired architecture becomes:

                     Internet
                        |
                        | TCP 443
                        v
               +----------------+
               | Web Tier       |
               +----------------+
                        |
                        | App Port
                        v
               +----------------+
               | App Tier       |
               +----------------+
                        |
                        | DB Port
                        v
               +----------------+
               | Database Tier  |
               +----------------+

24 — Review Administrative Paths

Administrative traffic should be treated separately from application traffic.

Example:

Administrator
      ↓
Trusted Management Path
      ↓
Web / App / DB

🧠 Management Plane Principle

Avoid mixing:

Application Traffic
+
Administrative Traffic

without reason.

25 — Understand Source Restrictions

Suppose SSH access is needed.

Weak rule:

Source:
0.0.0.0/0

Port:
22

Better:

Source:
Trusted Administrator IP

Port:
22

Better enterprise architecture may use:

Admin Identity
      ↓
VPN / Bastion / Session Service
      ↓
Private Workloads

26 — Understand Destination Restrictions

Outbound security policy should also consider:

where workloads need to communicate.

Example:

App Server
      ↓
Database Only

may be stronger than unrestricted access to all internal systems.

27 — Understand Protocol Restrictions

Common protocols include:

TCP
UDP
ICMP

Do not select:

all protocols

unless required.

28 — Understand Port Ranges

A security policy may allow:

TCP 443

or a range.

Avoid broad ranges such as:

TCP 1-65535

without documented justification.

🧠 Least-Privilege Principle

Prefer:

Required Source
+
Required Destination
+
Required Protocol
+
Required Port

29 — Review Default Security Rules

Some cloud environments create default security policies.

Review whether they allow:

all internal traffic
all outbound traffic
broad inbound traffic

🚨 Important

Do not assume:

default = least privilege.

30 — Validate the Web-Tier Policy

From an approved external client, test:

HTTPS

to the web workload.

Expected:

Allowed.

31 — Test an Unapproved Port

Use a safe test port where no service is expected.

Expected:

blocked or unreachable.

🧠 Validation Principle

Do not merely inspect the configuration.

Test the expected behavior.

32 — Validate Restricted SSH

Attempt SSH from:

approved source
unapproved source where safely possible

Expected:

Approved Source
      ↓
Allowed

and:

Unapproved Source
      ↓
Blocked

33 — Validate Web-to-App Traffic

From the web workload, test the required application port.

For example:

nc -vz <app-private-ip> 8080

if nc is available and your test service is listening.

Use the actual configured test service.

34 — Validate Web-to-Database Restriction

From the web workload, attempt the database service connection.

Expected:

denied or unreachable.

35 — Validate App-to-Database Traffic

From the application workload, test the required database service.

Expected:

allowed.

36 — Validate Internet-to-App Restriction

Confirm there is no direct public inbound path to the application tier.

Check:

public IP
route design
security-group rules

37 — Validate Internet-to-Database Restriction

Confirm:

Internet
   X
Database

38 — Build a Validation Matrix

Test	Expected	Result
Internet → Web HTTPS	Allow
Internet → Web SSH from trusted source	Allow
Internet → Web SSH from untrusted source	Deny
Internet → App	Deny
Internet → DB	Deny
Web → App	Allow
Web → DB	Deny
App → DB	Allow

39 — Understand Security Groups vs Route Tables

This distinction is critical.

Route Table

Answers:

Where does traffic go?

Security Group

Answers:

Is traffic allowed?

🧠 Example

You can have:

Valid Route
+
Blocked Security Rule
=
No Connectivity

You can also have:

Allowed Security Rule
+
Missing Route
=
No Connectivity

40 — Understand Cloud Security vs Host Firewall

Your workload may also have an operating-system firewall.

Conceptually:

Network
   ↓
Cloud Security Rule
   ↓
OS Firewall
   ↓
Application

All layers must support the intended communication.

🧠 Troubleshooting Principle

If the cloud security group allows TCP 443 but the OS firewall blocks it:

the service remains unreachable.

41 — Review Listening Services

On a Linux test workload, inspect:

ss -tuln

Confirm the expected service is actually listening.

42 — Understand the Complete Traffic Path

For HTTPS:

Internet Client
      ↓
DNS
      ↓
Public IP
      ↓
Route
      ↓
Cloud Security Rule
      ↓
OS Firewall
      ↓
TCP 443 Listener
      ↓
Web Application

43 — Deliberately Break the HTTPS Rule

In the isolated lab, temporarily remove the inbound HTTPS rule.

Test again.

Expected:

HTTPS fails.

44 — Troubleshoot the Failure

Use:

Route?
 ↓
Security Group?
 ↓
OS Firewall?
 ↓
Service?

Identify:

missing security-group rule.

45 — Restore the HTTPS Rule

Recreate the required rule.

Test again.

Expected:

service restored.

46 — Document the Security Incident

Record:

Problem:
Web application unreachable.

Expected Traffic:
Internet → TCP 443 → Web

Observed Behavior:

Root Cause:
Missing/incorrect security-group rule.

Remediation:

Validation:

47 — Deliberately Create an Overly Broad Rule

In the lab only, temporarily create something broad such as:

Source:
Anywhere

Protocol:
All

Review how much access this potentially creates.

Then remove it.

🚨 Important

Do not leave the broad rule active.

The objective is to understand:

why broad rules create unnecessary attack surface.

48 — Perform a Public Exposure Review

For every public workload ask:

Which Ports Are Open?
 ↓
Why?
 ↓
From Which Sources?
 ↓
Is Each One Required?

49 — Perform an East-West Security Review

Review:

Web → App
App → DB
Web → DB

The goal is not merely:

internal = trusted.

Internal traffic also requires policy.

🧠 Lateral Movement Connection

If one workload is compromised, excessive east-west access can allow attackers to move toward other systems.

50 — Review Database Exposure

The database tier should ideally satisfy:

Internet:
No

Web:
No

Application:
Required DB Port Only

Administration:
Controlled

51 — Review Outbound Access

For each workload ask:

Web Tier

What external destinations are required?

App Tier

Does it need:

repositories
APIs
logging destinations?

Database Tier

Does it need external access at all?

🧠 Outbound Security

Inbound security receives most attention, but uncontrolled outbound access can also create risk.

52 — Create a Least-Privilege Traffic Matrix

Document:

Source	Destination	Protocol	Port	Action	Business Reason
Internet	Web	TCP	443	Allow	User Access
Admin	Web	TCP	22	Allow	Administration
Web	App	TCP	App Port	Allow	Application
App	DB	TCP	DB Port	Allow	Database
Web	DB	Any	Any	Deny	Not Required
Internet	App	Any	Any	Deny	Private Tier
Internet	DB	Any	Any	Deny	Private Tier

53 — Create a Security Rule Naming Standard

Where your provider supports descriptions or rule names, use meaningful labels.

Example:

allow-https-from-internet
allow-ssh-from-admin
allow-web-to-app
allow-app-to-db

Avoid:

rule1
rule2
test

54 — Add Rule Descriptions

For each rule document:

purpose
owner
source
destination
service

🧠 Why Descriptions Matter

Six months later, someone should be able to answer:

Why does this rule exist?

55 — Identify Stale Rules

Suppose a rule exists for:

TCP 8080

but the application moved to:

TCP 8443

The old rule may now be unnecessary.

🧠 Security Rule Lifecycle

Use:

Create
 ↓
Use
 ↓
Review
 ↓
Modify
 ↓
Remove

56 — Review Temporary Rules

Temporary administrative rules should not become permanent by accident.

Document:

Temporary Rule:

Owner:

Reason:

Created:

Expiration:

57 — Understand Network ACL Concepts

Some providers also support subnet-level network controls or ACL-style mechanisms.

Conceptually:

Subnet Traffic
      ↓
Network ACL / Equivalent
      ↓
Workload Security Group
      ↓
Host Firewall

🧠 Security Layers

Cloud environments may use multiple layers:

Routing
+
Subnet-Level Controls
+
Workload-Level Controls
+
Host Firewall
+
Application Security

58 — Stateful vs Stateless Review

Understand the broad distinction.

Stateful

Tracks connection state.

Stateless

Evaluates traffic independently according to rules.

🧠 Why This Matters

With stateless controls, you may need to consider:

both directions explicitly.

59 — Troubleshooting Scenario — HTTPS Does Not Work

Use:

DNS
 ↓
Public IP
 ↓
Route
 ↓
Security Group
 ↓
OS Firewall
 ↓
Application Listener

60 — Troubleshooting Scenario — App Cannot Reach DB

Check:

Source IP
 ↓
Source Security Rule
 ↓
Route
 ↓
DB Security Rule
 ↓
Host Firewall
 ↓
DB Listener
 ↓
Return Path

61 — Troubleshooting Scenario — Rule Looks Correct

Suppose the rule says:

Source:
10.10.10.0/24

Port:
8080

but the web workload actually resides in:

10.10.11.0/24

The rule is technically valid but does not match the real source.

🧠 Troubleshooting Lesson

Always compare:

intended architecture

with:

actual deployed state.

62 — Troubleshooting Scenario — Wrong Port

Suppose the security group allows:

TCP 8080

but the application listens on:

TCP 8443

No amount of route-table changes will solve the problem.

63 — Troubleshooting Scenario — OS Firewall Blocking

Cloud rule:

TCP 443 Allowed

but service remains unavailable.

Review the host firewall.

64 — Troubleshooting Scenario — Service Not Listening

Both network and host firewall allow the traffic.

Still unavailable.

Check:

ss -tuln

If no service listens on the expected port:

the issue is application/service related.

65 — Troubleshooting Scenario — Everything Open but App Still Fails

Avoid opening more ports.

Review:

application
dependencies
DNS
authentication
logs

🧠 Cloud Security Troubleshooting Framework

Use:

Source
 ↓
Route
 ↓
Cloud Network Control
 ↓
Host Firewall
 ↓
Listening Port
 ↓
Application
 ↓
Return Path

66 — Perform a Security Review of the Web Tier

Check:

[ ] HTTPS required
[ ] Administrative access restricted
[ ] No unnecessary ports
[ ] Source restrictions documented
[ ] Outbound requirements reviewed

67 — Perform a Security Review of the App Tier

Check:

[ ] No direct public exposure
[ ] Web-to-app traffic limited
[ ] Admin access controlled
[ ] Outbound requirements reviewed

68 — Perform a Security Review of the DB Tier

Check:

[ ] No public IP
[ ] No direct internet access
[ ] App-to-db only
[ ] Web-to-db blocked
[ ] Administrative access controlled

69 — Update the Architecture Diagram

Your final design should show both routes and security policy.

                    Internet
                       |
                    TCP 443
                       |
                       v
             +------------------+
             | Web Tier         |
             | 10.10.10.0/24    |
             +------------------+
                       |
                   App Port
                       |
                       v
             +------------------+
             | Application Tier |
             | 10.10.20.0/24    |
             +------------------+
                       |
                    DB Port
                       |
                       v
             +------------------+
             | Database Tier    |
             | 10.10.30.0/24    |
             +------------------+

70 — Create Your Network Security Record

Document:

Web Security Group:
cloudplus-lab-sg-web-01

Application Security Group:
cloudplus-lab-sg-app-01

Database Security Group:
cloudplus-lab-sg-db-01

Public HTTPS:
Allowed

Public SSH:
Trusted Sources Only

Internet → App:
Blocked

Internet → DB:
Blocked

Web → App:
Required Port Only

Web → DB:
Blocked

App → DB:
Required Port Only

71 — Update the Resource Inventory

Add:

Resource	Type	Purpose	Status
cloudplus-lab-sg-web-01	Security Group	Web Tier	Active
cloudplus-lab-sg-app-01	Security Group	App Tier	Active
cloudplus-lab-sg-db-01	Security Group	DB Tier	Active

72 — Capture Evidence

Capture sanitized evidence of:

web security rules
application security rules
database security rules
validation tests
denied traffic tests

Do not capture:

secrets
private keys
sensitive account identifiers

73 — Perform Final Validation

Verify:

Internet → Web HTTPS
            ALLOW

Internet → App
            DENY

Internet → DB
            DENY

Web → App
            ALLOW

Web → DB
            DENY

App → DB
            ALLOW

🧪 Final Validation Checklist

Validation	Status
Web security group created
App security group created
DB security group created
HTTPS allowed
SSH restricted
Internet-to-app blocked
Internet-to-db blocked
Web-to-app allowed
Web-to-db blocked
App-to-db allowed
Public exposure reviewed
Host firewall considered
Listening services validated
Broad rule tested and removed
Security matrix documented
Troubleshooting case completed
Resource inventory updated

74 — Cleanup Decision

Keep these security groups if you are continuing the Cloud+ lab sequence.

They will be useful for later:

DNS
three-tier architecture
load balancing
monitoring
incident investigation

Remove only temporary test rules.

🎯 Certification Connection

Cloud+ questions may ask:

A VM has correct routing but remains unreachable.

Think:

Route
   ↓
Network Security Rule
   ↓
Host Firewall
   ↓
Service

Another scenario may ask:

Which control best reduces unnecessary exposure?

Look for:

Least Privilege
+
Specific Source
+
Specific Port

instead of broad ANY access.

🎤 Interview Questions

Practice without notes.

1. What is a cloud security group?

2. What is a virtual firewall?

3. Inbound vs outbound rule?

4. Why restrict source IP ranges?

5. Why restrict ports?

6. What does least-privilege network access mean?

7. Why should SSH not normally be open to everyone?

8. Why should databases not be publicly exposed?

9. Why separate web, application, and database security policies?

10. Routing vs security group?

11. Cloud security group vs host firewall?

12. What is a stateful firewall?

13. What is a stateless control?

14. Why validate denied traffic?

15. Why review outbound rules?

16. Why document business reasons for firewall rules?

17. What is a stale security rule?

18. What is east-west security?

19. How can excessive internal access enable lateral movement?

20. How would you troubleshoot a blocked cloud connection?

🚨 Scenario Interview Question 1

A web server has HTTPS open to the internet and SSH open to 0.0.0.0/0.

What would you change?

Keep:

HTTPS
Internet → TCP 443

Review and restrict:

SSH
Trusted Admin Source → TCP 22

🚨 Scenario Interview Question 2

The application server is reachable directly from the internet even though it should be private.

Review:

public IP
routing
security rules
workload placement

Do not treat this as only a firewall issue.

🚨 Scenario Interview Question 3

Web users cannot reach the application.

Use:

Route
 ↓
Web Security Group
 ↓
App Security Group
 ↓
App Host Firewall
 ↓
Listening Port

🚨 Scenario Interview Question 4

The web tier can access the database directly.

Ask:

Is that required by the architecture?

If not, remove the path and require:

Web
 ↓
Application
 ↓
Database

🚨 Scenario Interview Question 5

A developer requests ANY protocol from ANY source because the application is not working.

Do not immediately approve it.

Determine:

Required Source
+
Required Destination
+
Required Port
+
Actual Failure

🚨 Scenario Interview Question 6

The cloud rule allows TCP 443, but HTTPS still fails.

Check:

route
host firewall
service status
listening port
application health

🚨 Scenario Interview Question 7

The database security group allows only the app tier, but connectivity still fails.

Check whether:

the app is using the expected source identity/IP
the database listener uses the expected port
host firewall permits it
routes and return paths are valid

🧠 Cloud Network Security Interview Framework

Use:

Business Requirement
      ↓
Source
      ↓
Destination
      ↓
Protocol
      ↓
Port
      ↓
Network Path
      ↓
Security Rule
      ↓
Validation

💬 Interview Tip

Avoid:

“I would open the port and see if it works.”

A stronger answer is:

“I would first confirm the required source, destination, protocol, and port from the application architecture. I would verify the routing path, review workload and subnet-level security controls, check the host firewall and listening service, and then implement the narrowest rule required before validating both allowed and denied traffic.”

That demonstrates Cloud Security Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. Security Architecture Diagram

Show:

Internet
 ↓ HTTPS
Web
 ↓ App Port
Application
 ↓ DB Port
Database

2. Traffic Matrix

Document every required communication flow.

3. Security Rule Register

Include:

source
destination
protocol
port
business reason

4. Public Exposure Review

Show which services are externally accessible and why.

5. Troubleshooting Record

Document one intentionally broken security rule and its remediation.

📝 Resume Examples

Instead of:

Configured cloud security groups.

Use:

Implemented least-privilege cloud network-security controls across public web, private application, and database tiers using source restrictions, protocol and port filtering, controlled administrative access, and validated allowed/denied traffic paths.

Or:

Troubleshot cloud connectivity across routing, workload security groups, host firewalls, listening services, and application dependencies while documenting root cause and remediation.

⭐ Job-Readiness Check

You should now be able to:

explain cloud security groups
understand inbound and outbound rules
define source restrictions
define port restrictions
apply least privilege
restrict administrative access
secure public web workloads
protect private application tiers
protect database tiers
distinguish routing from network security
distinguish cloud controls from host firewalls
understand stateful firewall concepts
review public exposure
review east-west communication
identify broad security rules
validate allowed traffic
validate denied traffic
troubleshoot security-rule failures
document security policy professionally

🏆 Mission Complete

You have now progressed from:

Routing
      ↓
Traffic Has a Path

to:

Security Policy
      ↓
Only Required Traffic Uses That Path

Your current environment now reflects a much stronger cloud design:

Internet
   ↓
HTTPS
   ↓
Web
   ↓
Application Service
   ↓
Application
   ↓
Database Service
   ↓
Database

The key lesson is:

Good cloud security is not about blocking everything. It is about permitting exactly what the workload requires and being able to explain why every access path exists.

🚀 What’s Next?

Your compute, subnets, routing, and network-security controls are now established.

The next lab focuses on DNS and cloud name resolution.

You will work with:

DNS architecture
hostname-to-IP resolution
public DNS
private DNS
DNS records
resolver concepts
workload name resolution
DNS testing
broken DNS troubleshooting
distinguishing DNS failures from routing failures

You will move from:

10.10.20.15

to:

app.cloudplus.lab

and understand how that name is resolved to the correct destination.

➡️ Next: Lab 06 — Cloud DNS and Name Resolution