Deploy and Manage a Cloud Virtual Machine

Virtual machines are one of the fundamental building blocks of cloud computing. A cloud engineer must understand not only how to launch a VM, but how compute, storage, networking, identity, security, monitoring, cost, and lifecycle management work together around that workload.

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

In Lab 01, you established your cloud lab environment.

You defined:

account security
MFA
primary region
naming standards
tagging standards
cost controls
documentation
cleanup procedures

Now you will deploy your first actual cloud workload.

You will follow the lifecycle:

Requirement
     ↓
Select Compute
     ↓
Select Operating System
     ↓
Configure Storage
     ↓
Configure Network
     ↓
Configure Security
     ↓
Deploy
     ↓
Connect
     ↓
Monitor
     ↓
Modify
     ↓
Troubleshoot
     ↓
Clean Up

The objective is not simply:

Launch a virtual machine.

The objective is:

Understand how a cloud engineer deploys, validates, operates, troubleshoots, and manages the complete lifecycle of a virtual machine.

🎯 Mission Information

Item	Details
Lab	02 — Deploy and Manage a Cloud Virtual Machine
Difficulty	Beginner
Estimated Time	60–90 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud Compute
Environment	Approved Cloud Lab
Previous Lab	01 — Build Your Cloud Lab Environment
Major Skills	Compute, Storage, Networking, Security, Monitoring, Troubleshooting
Career Alignment	Cloud Support Engineer, Cloud Administrator, Junior Cloud Engineer
Deliverable	Working VM + Deployment Documentation

🏢 Scenario

You are working as a junior cloud administrator.

A development team requires a small Linux server for testing an internal application.

The server does not require high performance.

Your manager asks you to:

deploy the virtual machine
use an appropriately sized instance
attach persistent storage
configure network connectivity
restrict administrative access
validate connectivity
monitor the workload
resize the VM
document the deployment
remove the resources when testing is complete

You must also ensure the environment remains:

secure
documented
cost-aware
easy to troubleshoot

🎯 Lab Objectives

By completing this lab, you should be able to:

explain cloud virtual machines
understand virtualization concepts
identify VM configuration components
select an appropriate machine size
select an operating-system image
configure virtual storage
understand virtual network interfaces
distinguish private and public IP addresses
configure basic network access
deploy a VM
connect securely to a VM
inspect VM resources
start and stop a VM
resize a VM
review basic monitoring
troubleshoot common VM connectivity problems
document the deployment
safely remove cloud resources

🧠 Before You Begin

You should have completed:

Lab 01 — Build Your Cloud Lab Environment

You should already have:

Cloud Account
      ↓
Secure Administrative Access
      ↓
Primary Lab Region
      ↓
Naming Standard
      ↓
Tagging Standard
      ↓
Cost Controls
      ↓
Cleanup Process

⚠️ Cost Notice

Virtual machines may generate cloud charges.

For this lab:

select a free-tier or smallest practical instance where available
avoid GPU instances
avoid high-memory instances
avoid large storage volumes
stop or delete resources after completing the exercise
verify associated resources during cleanup

Remember:

VM Deleted
≠
Everything Automatically Free

Storage, snapshots, IP addresses, backups, and other associated resources may have separate lifecycle or billing behavior.

01 — Understand What You Are Building

A cloud VM is essentially:

Physical Infrastructure
        ↓
Virtualization Platform
        ↓
Virtual Machine
        ↓
Operating System
        ↓
Applications

From your perspective, the VM normally contains:

Virtual Machine
      |
      ├── vCPU
      ├── Memory
      ├── Operating System
      ├── Virtual Disk
      ├── Network Interface
      └── IP Address

🧠 What Is a vCPU?

A virtual CPU represents compute capacity assigned to the VM.

Increasing vCPU can provide more processing capability.

But:

More CPU usually means higher cost.

Cloud engineering therefore requires:

Performance
+
Requirement
+
Cost

rather than simply choosing the largest VM available.

02 — Understand VM Sizing

Cloud providers normally provide multiple VM sizes.

They may be optimized for:

general purpose
compute
memory
storage
graphics
accelerated workloads

For this lab, choose:

the smallest practical general-purpose VM.

🧠 Right-Sizing Principle

Avoid:

Small Application
      ↓
Very Large VM
      ↓
Unused Capacity
      ↓
Higher Cost

Prefer:

Application Requirement
      ↓
Appropriate VM Size
      ↓
Monitor
      ↓
Resize When Required

03 — Record the Workload Requirements

Before deploying anything, document:

Application:
Cloud+ Test Workload

Environment:
Lab

Operating System:
Linux

Expected Users:
1

Performance Requirement:
Low

Availability Requirement:
Lab Only

Internet Exposure:
Administrative Access Only

Data Sensitivity:
None / Lab Data

💡 Job Tip

In a real environment, do not begin with:

Which VM should I create?

Begin with:

What does the workload actually require?

04 — Open the Cloud Compute Service

Navigate to the provider’s compute or virtual-machine service.

Depending on the platform, terminology may include concepts such as:

virtual machine
instance
compute instance

Do not deploy yet.

First review the available configuration options.

05 — Verify the Cloud Account

Before creating anything, verify:

Correct Account?
      ↓
Correct Subscription / Project?
      ↓
Correct Environment?

Accidentally deploying resources into the wrong environment is a common operational problem.

06 — Verify Your Region

Confirm that you are operating in the region selected during Lab 01.

Record:

Cloud Provider:

Account / Subscription:

Region:

Environment:
LAB

🧠 Why Region Matters

Your VM’s location can affect:

latency
availability
pricing
service compatibility
compliance
data residency

07 — Name the Virtual Machine

Follow the naming standard established during Lab 01.

Example:

cloudplus-lab-vm-01

Avoid names such as:

server1
test
vmnew
abc

08 — Apply Resource Tags

Apply your standard lab tags.

Example:

Tag	Value
Environment	Lab
Course	CompTIA-CloudPlus
Purpose	Training
Owner	Student
AutoDelete	Yes

🧠 Professional Habit

Every resource should answer:

What is this?

Who owns it?

Why does it exist?

09 — Select an Operating-System Image

Choose a supported Linux image suitable for a basic lab.

For example, use a current provider-supported Linux distribution.

Do not select an operating system simply because:

it is the first option.

Review:

OS family
version
architecture
support status
cost

🧠 What Is a VM Image?

A VM image provides the starting operating-system configuration.

Conceptually:

VM Image
   ↓
Operating System Template
   ↓
New Virtual Machine

10 — Understand Image Architecture

You may encounter processor architectures such as:

x86_64

or:

ARM64

Software compatibility may depend on architecture.

For beginner labs, choose the architecture that provides the simplest compatibility with your selected workload.

11 — Select the VM Size

Choose a small general-purpose VM.

Record:

VM Size:

vCPU:

Memory:

Estimated Cost:

🧠 Cloud+ Exam Concept

VM sizing is not simply about:

CPU.

Consider:

CPU
+
Memory
+
Storage
+
Network
+
Workload Type
+
Cost

12 — Configure the Boot Disk

The operating system requires storage.

Conceptually:

Virtual Machine
      ↓
Boot Volume
      ↓
Operating System

Choose the smallest practical storage size for the lab.

13 — Understand Cloud Block Storage

A VM commonly uses block storage.

Think of it as:

a virtual disk attached to the virtual machine.

Examples of workloads suited to block storage include:

operating-system disks
application disks
database volumes

🧠 Important Distinction

Later you will compare:

Block Storage
File Storage
Object Storage

Do not treat all cloud storage as the same technology.

14 — Review Storage Performance Options

Your provider may expose characteristics such as:

disk type
IOPS
throughput
capacity

For this lab:

use the standard low-cost/default option appropriate for training.

Do not increase performance settings unnecessarily.

15 — Configure the Network Interface

Your VM requires a virtual network interface.

Conceptually:

Virtual Machine
      ↓
Virtual Network Interface
      ↓
Virtual Network
      ↓
Subnet

The network interface may contain:

private IP
public IP
security rules
routing information

16 — Understand the Private IP Address

A private IP is typically used for communication inside private network environments.

Example concept:

VM-A
10.0.1.10
   ↓
Private Network
   ↓
VM-B
10.0.1.20

17 — Understand the Public IP Address

A public IP may allow communication from external networks when routing and security controls permit it.

Conceptually:

Internet
   ↓
Public IP
   ↓
Cloud VM

🚨 Important

A public IP does not automatically mean:

every service is accessible.

Access also depends on:

Route
+
Network Security Rules
+
Operating-System Firewall
+
Running Service

18 — Decide Whether Public Access Is Required

For this beginner lab, you may require temporary administrative access.

If a public IP is necessary:

use it only for the lab
restrict inbound administrative access
remove unnecessary exposure afterward

🧠 Security Principle

Do not ask:

Can I make this server public?

Ask:

Does this workload actually need to be public?

19 — Configure Administrative Access

For Linux, secure remote administration commonly uses:

SSH

Default SSH port:

TCP 22

Where possible, prefer key-based authentication rather than weak reusable passwords.

20 — Create or Select an SSH Key

Where required, create or select an SSH key pair.

Conceptually:

Private Key
      ↓
Kept Securely by Administrator

Public Key
      ↓
Placed on VM

🚨 Never

publish private keys
upload them to public repositories
share them unnecessarily
paste them into screenshots

21 — Configure the Network Security Rule

Allow only the access required for administration.

For example:

Source:
Your Trusted IP

Protocol:
TCP

Destination Port:
22

Action:
Allow

Avoid:

Source:
Anywhere

Port:
22

where a more restrictive rule is practical.

🧠 Least-Privilege Networking

Use:

Required Source
      ↓
Required Protocol
      ↓
Required Port
      ↓
Required Destination

22 — Review the Configuration Before Deployment

Before selecting Create, Launch, or equivalent, review:

Account
Region
Name
Image
VM Size
Storage
Network
IP Address
Security Rules
Authentication
Tags
Estimated Cost

🧠 Professional Habit

Use:

Review
 ↓
Deploy

not:

Deploy
 ↓
Discover Mistakes

23 — Deploy the Virtual Machine

Create the VM.

Observe the deployment process.

You may see states such as:

Creating
 ↓
Provisioning
 ↓
Running

📝 Record Deployment Evidence

Document:

VM Name:

Region:

VM Size:

Operating System:

Private IP:

Public IP:

Boot Disk:

Deployment Status:

24 — Inspect the VM Details

Open the VM details page.

Identify:

VM identifier
power state
region
zone/failure domain
image
VM size
network interface
private IP
public IP
attached storage

🧠 Cloud Administrator Habit

When troubleshooting a VM, first understand:

what is actually deployed.

25 — Connect to the VM

Use the secure connection method provided by your environment.

For a Linux SSH connection, the conceptual syntax is:

ssh -i <private-key> <username>@<public-ip>

Use the username and authentication method appropriate for your selected image.

26 — Validate the Operating System

After connecting, identify the OS.

Example:

cat /etc/os-release

Record:

Operating System:

Version:

Architecture:

27 — Check the Hostname

Run:

hostname

Understand the difference between:

cloud resource name

and:

operating-system hostname.

They may not always be identical.

28 — Check CPU Information

Run:

lscpu

Identify:

architecture
CPU count

Compare this with the VM size you selected.

29 — Check Memory

Run:

free -h

Review:

total memory
used memory
available memory

🧠 Troubleshooting Connection

If an application becomes slow, memory utilization may be one possible factor.

Never troubleshoot only:

the network.

30 — Check Storage

Run:

lsblk

Then:

df -h

Understand the difference between:

block devices
mounted filesystems
available filesystem capacity

31 — Check Network Interfaces

Run:

ip addr

Identify the VM’s private IP address.

Compare it with the value shown in the cloud console.

🧠 Important Observation

The VM operating system may primarily see:

Private IP

while the cloud platform provides public-IP translation or mapping externally.

This distinction becomes important during network troubleshooting.

32 — Review the Routing Table

Run:

ip route

Identify:

default route
local network route
gateway

🧠 Network Troubleshooting Model

Remember:

Source
 ↓
Network Interface
 ↓
Route
 ↓
Security Control
 ↓
Destination

33 — Test Basic Connectivity

Where appropriate, test network connectivity to an approved destination.

For example:

ping -c 4 <approved-destination>

Do not assume a failed ping automatically means:

the network is broken.

ICMP may be blocked while other services remain available.

34 — Update the Operating System

Where appropriate for your chosen distribution and lab environment, apply current package updates using its supported package-management process.

Examples may include:

sudo apt update

or:

sudo dnf check-update

Use the correct command for your distribution.

🧠 Cloud Operations Principle

A newly deployed VM is not automatically:

permanently secure.

Operating systems require lifecycle management.

35 — Review Running Processes

Run:

ps aux

Observe:

system processes
services
resource consumers

You do not need to understand every process yet.

The goal is becoming comfortable operating a Linux cloud workload.

36 — Review Listening Ports

Use an available tool such as:

ss -tuln

Identify listening services.

Ask:

Does every listening service actually need to be available?

🧠 Security Connection

Security should be evaluated at multiple layers:

Cloud Network Rule
       +
OS Firewall
       +
Application

37 — Create a Test File

Create simple evidence that you have administrative access.

Example:

echo "CompTIA Cloud+ Lab 02" > ~/cloudplus-lab.txt

Verify:

cat ~/cloudplus-lab.txt

38 — Review VM Monitoring

Return to your cloud console.

Locate the VM monitoring or metrics section.

Review available metrics such as:

CPU utilization
network activity
disk activity
VM health

🧠 Monitoring Principle

Do not wait for users to report:

the server is slow.

Monitoring should help detect operational conditions proactively.

39 — Generate Basic Activity

Reconnect to the VM and perform some basic operations.

Then review whether the cloud metrics change.

The objective is to connect:

Workload Activity
      ↓
Telemetry
      ↓
Monitoring

40 — Stop the Virtual Machine

Gracefully stop the VM using the provider’s supported method.

Observe the state transition.

For example:

Running
 ↓
Stopping
 ↓
Stopped

🧠 Stop vs Delete

Understand:

STOP
=
VM retained

DELETE
=
VM resource removed

But billing behavior depends on the provider and associated resources.

41 — Start the Virtual Machine

Start the VM again.

Observe:

Stopped
 ↓
Starting
 ↓
Running

Then reconnect.

42 — Check the IP Addresses Again

Compare:

Before Stop
vs
After Start

Determine whether:

private IP remained the same
public IP remained the same

🧠 Important Cloud Concept

Depending on configuration:

public addresses may change across lifecycle operations.

Applications should therefore not blindly depend on temporary addressing.

43 — Resize the Virtual Machine

You will now practice vertical scaling.

Record the current configuration:

Current vCPU:

Current Memory:

Current VM Size:

Select another small VM size.

Do not select an expensive configuration.

🧠 Vertical Scaling

Vertical scaling means:

VM
 ↓
More / Less CPU
More / Less Memory

This is also called:

scaling up or scaling down.

44 — Perform the Resize

Depending on the provider, resizing may require:

stopping the VM
selecting a new size
restarting the VM

Follow your provider’s supported workflow.

45 — Validate the New Configuration

Reconnect and run:

lscpu

and:

free -h

Compare the results with your previous values.

📝 Record

Resource	Before	After
vCPU
Memory
VM Size

🧠 Operational Lesson

Do not resize workloads blindly.

Use:

Monitoring
 ↓
Performance Requirement
 ↓
Capacity Decision
 ↓
Resize
 ↓
Validation

46 — Understand Horizontal Scaling

You did vertical scaling in this lab.

Horizontal scaling is different.

Vertical Scaling

VM
 ↓
Bigger VM

versus:

Horizontal Scaling

VM
 ↓
VM + VM + VM

Horizontal scaling will become important later when you work with:

load balancing
auto scaling
high availability

47 — Simulate VM Connectivity Failure

Now practice troubleshooting.

Temporarily modify your lab’s administrative network rule so your SSH connection is no longer allowed.

Do not delete the VM.

Attempt to reconnect.

Expected result:

connection should fail.

48 — Troubleshoot Systematically

Do not immediately rebuild the VM.

Use:

Is VM Running?
      ↓
Correct IP?
      ↓
Correct Route?
      ↓
Security Rule?
      ↓
OS Firewall?
      ↓
SSH Service?
      ↓
Credentials?

🧠 Troubleshooting Rule

Start with:

evidence.

Not:

assumptions.

49 — Restore the Security Rule

Restore the authorized SSH rule.

Attempt the connection again.

Confirm:

connectivity is restored.

📝 Document the Incident

Record:

Problem:
Unable to connect to VM using SSH.

Observation:

Root Cause:

Corrective Action:

Validation:

Lesson Learned:

50 — Understand the VM Connectivity Path

Your connection conceptually follows:

Administrator
      ↓
Internet
      ↓
Public IP
      ↓
Cloud Network
      ↓
Security Rule
      ↓
Network Interface
      ↓
Operating System
      ↓
SSH Service

Any component in that path can cause failure.

51 — Perform a Basic Security Review

Check:

[ ] Administrative access restricted
[ ] No unnecessary ports exposed
[ ] Authentication protected
[ ] OS updated where appropriate
[ ] Resource tagged
[ ] Correct region used
[ ] Correct VM size used
[ ] Monitoring available

52 — Perform a Basic Cost Review

Ask:

Is the VM larger than required?
Is it still running unnecessarily?
Is extra storage attached?
Is a public IP allocated?
Are any other billable resources attached?

💡 Job Tip

Cloud optimization often means:

security + performance + cost.

Not just:

reduce the bill.

53 — Update Your Resource Inventory

Add the VM to your Lab 01 inventory.

Example:

Resource	Type	Region	Purpose	Cost Risk	Cleanup Status
cloudplus-lab-vm-01	VM	Primary Lab Region	Training	Low	Active

Also record associated:

disk
network interface
public IP

where applicable.

54 — Create the Architecture Diagram

Document your deployment.

Administrator
      |
      | SSH
      v
Internet
      |
      v
Public IP
      |
      v
Cloud Network
      |
      v
Security Rule
      |
      v
Network Interface
      |
      v
cloudplus-lab-vm-01
      |
      ├── vCPU
      ├── Memory
      ├── Linux
      └── Boot Disk

55 — Capture Lab Evidence

Capture sanitized evidence of:

VM configuration
running state
CPU information
memory information
storage
private IP
monitoring metrics
resize results

🚨 Never Capture

Do not include:

passwords
private SSH keys
access tokens
secrets
sensitive account information

56 — Create Your VM Deployment Record

Document:

VM Name:

Purpose:

Provider:

Region:

OS:

Architecture:

VM Size:

vCPU:

Memory:

Boot Disk:

Private IP:

Public IP:

Authentication:

Administrative Port:

Security Rule:

Tags:

Monitoring:

Estimated Cost:

Cleanup Required:

57 — Perform Final Validation

Verify:

VM Deploys
   ↓
VM Boots
   ↓
Network Works
   ↓
Authentication Works
   ↓
Storage Works
   ↓
Monitoring Works
   ↓
Resize Works
   ↓
Troubleshooting Process Works

🧪 Validation Checklist

Validation	Status
VM successfully deployed
Correct region selected
Naming standard followed
Tags applied
Small VM size selected
OS identified
Storage identified
Private IP identified
Public access reviewed
SSH restricted
VM successfully accessed
CPU inspected
Memory inspected
Storage inspected
Routes inspected
Monitoring reviewed
VM stopped successfully
VM restarted successfully
VM resized
Resize validated
Connectivity failure tested
Root cause identified
Documentation completed

58 — Clean Up the Lab

If you are not immediately continuing to the next lab, remove unnecessary resources.

Review:

VM
 ↓
Attached Storage
 ↓
Network Interface
 ↓
Public IP
 ↓
Security Rules
 ↓
Snapshots / Backups

🚨 Do Not Blindly Delete Shared Resources

If you are reusing the same network or security resources for later labs, retain only what is intentionally required.

59 — Verify Resource Deletion

After cleanup:

refresh the compute inventory
review storage
review public IPs
review networking resources
review billing/cost dashboard

Update:

Cleanup Status:
Complete

🧠 Certification Connection

Cloud+ questions may present scenarios such as:

A VM is running but cannot be accessed.

Do not automatically choose:

restart the VM.

Think systematically:

Power State
 ↓
IP Address
 ↓
Routing
 ↓
Network Security
 ↓
OS Firewall
 ↓
Service
 ↓
Authentication

🎤 Interview Questions

Practice answering these without notes.

1. What is a cloud virtual machine?

2. What is a vCPU?

3. How do you choose a VM size?

4. What is a VM image?

5. What is block storage?

6. What is a network interface?

7. Private IP vs public IP?

8. Why should administrative ports be restricted?

9. What is vertical scaling?

10. What is horizontal scaling?

11. What happens when a VM is stopped?

12. Stop vs delete?

13. Why might a public IP change?

14. How would you troubleshoot an unreachable VM?

15. Why is VM monitoring important?

16. What factors influence VM cost?

17. Why should workloads be right-sized?

18. Why are tags important?

19. Why should cloud resources be documented?

20. What should be checked after deleting a VM?

🚨 Scenario Interview Question 1

A Linux VM is running but SSH does not work.

Walk through:

VM State
 ↓
IP
 ↓
Route
 ↓
Security Rule
 ↓
OS Firewall
 ↓
SSH Service
 ↓
Credentials

🚨 Scenario Interview Question 2

CPU utilization stays above 90% during business hours.

Do not immediately say:

buy the biggest VM.

Consider:

workload behavior
application issue
CPU trends
right-sizing
vertical scaling
horizontal scaling

🚨 Scenario Interview Question 3

A development VM runs only eight hours per day but remains powered on 24/7.

Possible improvement:

Usage Requirement
      ↓
Schedule
      ↓
Stop When Unused
      ↓
Reduce Cost

🚨 Scenario Interview Question 4

A VM has a public IP and SSH is open to the entire internet.

Identify:

unnecessary administrative exposure.

Recommend:

trusted source restriction
stronger access architecture
MFA/identity-aware administrative mechanisms where appropriate
monitoring

🚨 Scenario Interview Question 5

The VM was deleted, but the organization is still being charged.

Investigate:

disks
snapshots
IP addresses
load balancers
backup
other associated services

🚨 Scenario Interview Question 6

An application becomes slow after user demand increases.

Review:

CPU
Memory
Storage
Network
Application
Database

Do not assume the VM size is automatically the root cause.

🧠 VM Troubleshooting Framework

Memorize:

Compute
 ↓
Storage
 ↓
Network
 ↓
Security
 ↓
Operating System
 ↓
Application
 ↓
Monitoring

💬 Interview Tip

Avoid:

“If the VM doesn’t work, I would restart it.”

A stronger answer is:

“I would first verify the VM power and health state, then validate addressing, routing, network security controls, operating-system firewall rules, service availability, authentication, and relevant logs or monitoring data before making changes.”

That demonstrates Cloud Support Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. VM Architecture Diagram

Administrator
      ↓
Network
      ↓
Security Controls
      ↓
VM
      ↓
Storage

2. VM Deployment Record

Include:

configuration
sizing
operating system
networking
storage

3. Before/After Resize Evidence

Show:

Original VM
      ↓
Resize
      ↓
Updated VM

4. Troubleshooting Record

Document:

Problem
 ↓
Evidence
 ↓
Root Cause
 ↓
Remediation
 ↓
Validation

5. Cost Review

Explain why the VM size was appropriate for the workload.

📝 Resume Examples

Instead of:

Created cloud virtual machines.

Use:

Deployed and managed Linux cloud virtual machines including compute sizing, virtual storage, network interfaces, secure administrative access, lifecycle operations, monitoring, vertical scaling, troubleshooting, and resource cleanup.

Or:

Troubleshot cloud VM connectivity across IP addressing, routing, network security controls, operating-system services, and authentication while documenting root cause and remediation.

⭐ Job-Readiness Check

You should now be able to explain:

how a VM is created
how VM sizing works
what a VM image provides
how virtual storage attaches to compute
how a VM connects to a virtual network
private vs public addressing
how administrative connectivity works
why inbound access should be restricted
how to inspect CPU and memory
how to inspect storage
how to inspect networking
how VM monitoring works
how to stop/start a VM
how vertical scaling works
vertical vs horizontal scaling
how to troubleshoot an unreachable VM
how VM lifecycle affects cost
how to clean up associated resources

🏆 Mission Complete

You have now moved from simply having a cloud account to operating your first cloud workload.

You practiced:

Requirements
      ↓
Compute
      ↓
Operating System
      ↓
Storage
      ↓
Networking
      ↓
Security
      ↓
Deployment
      ↓
Administration
      ↓
Monitoring
      ↓
Scaling
      ↓
Troubleshooting
      ↓
Cleanup

The key lesson is:

Deploying a VM is easy. Professionally managing its compute, storage, networking, security, monitoring, cost, troubleshooting, and lifecycle is the real cloud engineering skill.

🚀 What’s Next?

You have worked with a single VM and its basic networking.

The next lab moves deeper into cloud networking.

You will build a segmented cloud network and learn how enterprise workloads are separated into different network tiers.

You will work with:

virtual networks
CIDR ranges
subnetting
public subnets
private subnets
application tiers
database tiers
IP address planning
segmentation
workload placement
traffic-flow documentation

You will build:

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

➡️ Next: Lab 03 — Build a Segmented Cloud Network