Cloud Environment Health Assessment Lab

A cloud environment can be online and still be unhealthy. Operational health means the environment is available, secure, resilient, observable, recoverable, supportable, and appropriately governed.

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

In the previous lab, you learned how to troubleshoot individual cloud failures:

Symptom
   ↓
Scope
   ↓
Evidence
   ↓
Hypothesis
   ↓
Root Cause
   ↓
Remediation

Now you will move from:

Reactive Troubleshooting

to:

Proactive Cloud Health Assessment

Instead of waiting for something to fail, you will systematically evaluate the environment and identify weaknesses before they become incidents.

🎯 Mission Information

Item	Details
Lab	26 — Cloud Environment Health Assessment Lab
Difficulty	Intermediate
Estimated Time	180–240 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud Operational Health Assessment
Previous Lab	25 — Cloud Troubleshooting Lab
Career Alignment	Cloud Engineer, Cloud Administrator, Cloud Operations Engineer, Cloud Consultant
Major Skills	Assessment, Monitoring, Security, Resilience, Backup, Cost, Operations
Deliverable	Cloud Health Assessment Report + Findings Register + Remediation Plan

🏢 Scenario

Your organization operates a production cloud environment.

Management asks:

“Is our cloud environment healthy?”

A simple check shows:

Application:
ONLINE

Virtual Machines:
RUNNING

Database:
RUNNING

An inexperienced engineer might conclude:

Environment Healthy

But further investigation reveals:

CPU frequently reaches 95%

Storage is 92% full

Backups have not been tested

Several users have excessive permissions

One administrative port is publicly exposed

Monitoring covers only some workloads

Certificates expire soon

No disaster recovery test exists

Unused resources are increasing costs

The environment is:

RUNNING

but not necessarily:

HEALTHY

Your mission is to perform a structured cloud environment health assessment.

🎯 Lab Objectives

By completing this lab, you should be able to:

• define cloud operational health

• establish assessment scope

• inventory cloud resources

• understand architecture dependencies

• assess compute health

• assess network health

• assess storage health

• assess identity and access

• assess security controls

• assess availability

• assess scalability

• assess monitoring

• assess logging

• assess backup

• assess disaster recovery

• assess automation

• assess configuration management

• identify configuration drift

• assess operational readiness

• assess cloud costs

• identify unused resources

• review quotas and limits

• assess certificates and secrets

• review incident readiness

• classify findings

• prioritize remediation

• create a cloud health scorecard

• create an executive health report

• build a reusable health-assessment runbook

01 — Understand Cloud Environment Health

Cloud health is broader than:

Resource Running?

A useful health model is:

                  CLOUD HEALTH
                       |
     +-----------------+-----------------+
     |                 |                 |
     v                 v                 v
 Availability       Security         Performance
     |                 |                 |
     +-----------------+-----------------+
                       |
              +--------+--------+
              |                 |
              v                 v
          Resilience       Observability
              |                 |
              +--------+--------+
                       |
                       v
                   Operations

02 — Define the Assessment Domains

Assess:

Architecture

Compute

Networking

Storage

Identity

Security

Availability

Performance

Scalability

Monitoring

Logging

Backup

Disaster Recovery

Automation

Configuration

Cost

Governance

Operations

03 — Establish Assessment Scope

Before starting, define:

Cloud Account / Subscription / Project

Region

Environment

Applications

Resources

Business Services

Assessment Period

Example:

Environment:
Production

Region:
Primary Region

Application:
Customer Portal

Assessment:
Operational Health Review

04 — Build the Assessment Scope Sheet

Assessment Name:

Cloud Platform:

Account / Subscription / Project:

Environment:

Region(s):

Applications:

Business Services:

Resource Groups / Projects:

Assessment Owner:

Technical Contacts:

Start Date:

Assessment Date:

05 — Understand Business Context

Not every workload has the same requirements.

Example:

Development Sandbox

Availability Requirement:
LOWER

versus:

Payment Application

Availability Requirement:
HIGH

Assessment findings should consider business importance.

06 — Identify Critical Services

Classify workloads:

Service	Criticality	Availability Requirement	Owner
Customer Portal	High	High
Internal Wiki	Medium	Medium
Development VM	Low	Low
Production Database	Critical	Very High

07 — Build the Resource Inventory

You cannot assess what you do not know exists.

Inventory:

Virtual Machines

Containers

Databases

Storage

Networks

Load Balancers

Public IPs

DNS

Identity Resources

Security Services

Monitoring

Backup Resources

08 — Resource Inventory Template

Resource	Type	Environment	Region	Owner	Criticality

09 — Identify Resource Ownership

Every important resource should ideally have:

Technical Owner

Business Owner

Purpose

Environment

Criticality

Resources without owners create operational risk.

10 — Review Resource Metadata

Where supported, review:

Tags

Labels

Naming

Environment

Application

Owner

Cost Center

Data Classification

11 — Assess Architecture

Document:

Users
  ↓
DNS
  ↓
Load Balancer
  ↓
Application
  ↓
Database
  ↓
Storage

Then identify dependencies.

12 — Build the Dependency Map

Example:

                  Internet
                     |
                     v
                    DNS
                     |
                     v
               Load Balancer
                     |
             +-------+-------+
             |               |
             v               v
          App-01           App-02
             |               |
             +-------+-------+
                     |
                     v
                  Database
                     |
                     v
                   Storage

13 — Identify Single Points of Failure

Look for:

Single VM

Single Database

Single Network Path

Single Availability Zone

Single Authentication Dependency

Single Storage Dependency

Ask:

What happens if this component fails?

14 — Assess Compute Health

Review:

Resource State

Platform Health

CPU

Memory

Disk

Network

Instance Size

Operating System

Patching

Availability

Scaling

15 — Build the Compute Health Table

Compute Resource	CPU	Memory	Disk	Health	Finding
App-01
App-02

16 — Review CPU Utilization

Look for:

Sustained High CPU

Frequent Spikes

Very Low Utilization

Unexpected Changes

High utilization may indicate:

Capacity Issue

Application Issue

Traffic Increase

Scaling Failure

17 — Review Memory

Look for:

Memory Pressure

Swap Usage

OOM Events

Memory Leaks

Incorrect Limits

18 — Review Compute Sizing

Possible findings:

Under-Provisioned

or:

Over-Provisioned

Example:

VM Capacity:
16 vCPU

Average CPU:
4%

This may represent an optimization opportunity.

19 — Review Compute Availability

Ask:

Multiple Instances?

Multiple Availability Zones?

Autoscaling?

Health Checks?

Automatic Replacement?

20 — Review Operating System Health

Assess:

Supported OS?

Patching Current?

Disk Healthy?

Agents Running?

Logging Working?

Monitoring Working?

21 — Assess Network Health

Review:

Virtual Networks

Subnets

Routes

Firewalls

Security Rules

Public IPs

DNS

Load Balancers

Private Connectivity

Network Logs

22 — Build the Network Architecture

Internet
   |
   v
Public Endpoint
   |
   v
Firewall / Security Controls
   |
   v
Load Balancer
   |
   v
Application Subnet
   |
   v
Database Subnet

23 — Review Public Exposure

Inventory:

Public IP Addresses

Internet-Facing Load Balancers

Public Storage

Public Databases

Administrative Ports

Ask:

Does this resource actually need to be publicly accessible?

24 — Review Administrative Access

Pay particular attention to:

SSH — TCP 22

RDP — TCP 3389

Check whether access is:

Restricted

or unnecessarily:

Internet-Wide

25 — Review Firewall Rules

Look for:

Any → Any

0.0.0.0/0

Overly Broad Ports

Unused Rules

Duplicate Rules

Temporary Rules

Unowned Rules

26 — Review Network Segmentation

Determine whether:

Web

Application

Database

Management

workloads are appropriately separated.

27 — Review Routes

Check for:

Incorrect Routes

Unexpected Internet Routes

Missing Private Routes

Asymmetric Routing

Obsolete Routes

28 — Review DNS Health

Assess:

Records

Resolution

TTL

Private Zones

Public Zones

Ownership

Redundancy

29 — Review Load Balancers

Check:

Listeners

Backend Health

Health Checks

Certificates

Logging

Availability

Session Configuration

30 — Assess Storage Health

Inventory:

Block Storage

Object Storage

File Storage

Database Storage

Snapshots

Backup Storage

31 — Review Storage Capacity

Check:

Used Capacity

Available Capacity

Growth Rate

Thresholds

Alerts

Example:

Capacity:
1 TB

Used:
920 GB

Utilization:
92%

Finding:

Capacity risk.

32 — Review Storage Performance

Assess:

IOPS

Throughput

Latency

Queue Depth

Compare performance with workload requirements.

33 — Review Storage Availability

Determine whether storage provides the required:

Redundancy

Replication

Durability

Availability

34 — Review Storage Security

Check:

Encryption at Rest

Encryption in Transit

Access Policies

Public Access

Logging

Versioning

35 — Review Storage Lifecycle

Look for:

Old Logs

Old Backups

Unused Snapshots

Temporary Data

Old Object Versions

Apply lifecycle policies where appropriate.

36 — Assess Identity Health

Inventory:

Users

Groups

Roles

Service Accounts

Managed Identities

Applications

Privileged Accounts

37 — Review Privileged Access

Identify:

Administrators

Owners

Global Roles

Root-Level Access

Highly Privileged Service Identities

Ask:

Does each identity still require this level of access?

38 — Review Least Privilege

Poor:

Application
    ↓
Administrator Role

Better:

Application
    ↓
Required Permissions Only

39 — Review Dormant Identities

Look for:

Inactive Users

Former Employees

Unused Service Accounts

Old API Credentials

Unused Application Identities

40 — Review MFA

Verify appropriate MFA coverage for:

Administrators

Privileged Users

Remote Access

Sensitive Operations

41 — Review Service Identities

Check:

Purpose

Owner

Permissions

Credential Type

Credential Age

Last Used

42 — Review Long-Lived Credentials

Identify:

Static Access Keys

API Keys

Passwords

Certificates

Tokens

Prefer managed or short-lived identity mechanisms where supported.

43 — Assess Security Health

Review:

Identity

Network

Data

Compute

Configuration

Logging

Vulnerability Management

Threat Detection

44 — Review Security Baseline

Create:

[ ] MFA enabled
[ ] Least privilege implemented
[ ] Public exposure reviewed
[ ] Encryption enabled
[ ] Logging enabled
[ ] Security monitoring enabled
[ ] Vulnerability scanning enabled
[ ] Patch management defined
[ ] Backup protected
[ ] Security alerts reviewed

45 — Review Encryption

Assess:

Data at Rest

Data in Transit

Database Encryption

Storage Encryption

Backup Encryption

Key Management

46 — Review Vulnerability Management

Check whether:

VMs

Containers

Images

Dependencies

Applications

are appropriately scanned.

47 — Review Patching

Determine:

Patch Policy

Patch Frequency

Current Patch Status

Exceptions

Unsupported Systems

48 — Review Security Findings

Inspect available security-management services for:

Critical Findings

High Findings

Misconfigurations

Threat Detections

Exposure

49 — Assess Availability

Ask:

What happens if a VM fails?

What happens if an availability zone fails?

What happens if the database fails?

What happens if a network dependency fails?

50 — Review High Availability

Check:

Multiple Instances

Multiple Zones

Load Balancing

Database Redundancy

Storage Redundancy

Automatic Failover

51 — Identify Availability Risk

Example:

Internet
   ↓
Load Balancer
   ↓
Single VM

Finding:

Single Point of Failure

52 — Review Autoscaling

Assess:

Minimum Capacity

Maximum Capacity

Scaling Trigger

Cooldown

Health

Quota

53 — Test Scaling Assumptions

Ask:

Can the environment actually scale when required?

A configured scaling policy may still fail because of:

Quota

Permissions

Capacity

Configuration

Network Limits

54 — Assess Monitoring Health

Monitoring should answer:

Is It Available?

Is It Performing Normally?

Is Capacity Healthy?

Are Errors Increasing?

Are Dependencies Healthy?

55 — Review Monitoring Coverage

Inventory:

Resource	Metrics	Logs	Alerts	Dashboard
VM
Database
Load Balancer
Storage

56 — Review Alerting

Check:

CPU

Memory

Disk

Availability

Latency

Errors

Failed Backups

Certificate Expiry

Security Events

57 — Review Alert Quality

Determine whether alerts are:

Actionable

Owned

Prioritized

Tested

Escalated

58 — Identify Alert Fatigue

Too many alerts:

Alert
Alert
Alert
Alert
Alert
   ↓
Noise
   ↓
Ignored Alerts

Tune alerts appropriately.

59 — Assess Logging Health

Check:

Application Logs

System Logs

Security Logs

Network Logs

Audit Logs

Database Logs

60 — Review Centralized Logging

Prefer:

VM Logs --------\
Application -----\
Firewall ---------> Central Log Platform
Database --------/
Cloud Audit -----/

rather than isolated logs across resources.

61 — Review Log Retention

Determine:

Retention Period

Security Requirements

Compliance Requirements

Cost

Archive Requirements

62 — Review Audit Logging

Ensure important administrative activities are recorded.

Examples:

Resource Creation

Resource Deletion

IAM Changes

Network Changes

Security Changes

Policy Changes

63 — Assess Backup Health

A backup configuration is not enough.

Review:

Backup Enabled?

Backup Successful?

Retention Correct?

Encrypted?

Protected?

Restore Tested?

64 — Review Backup Status

Resource	Backup	Last Backup	Retention	Restore Tested
Database
VM
Storage

65 — Look for Backup Failures

Examples:

Backup Job Failed

Backup Agent Offline

Storage Full

Permission Failure

Retention Misconfigured

66 — Understand the Restore Principle

Remember:

A backup that has never been successfully restored is an unverified recovery capability.

67 — Perform a Safe Restore Test

In an approved non-production location:

Backup
   ↓
Restore
   ↓
Validate Data
   ↓
Validate Application

Do not overwrite production data during a lab restore test.

68 — Review RPO

RPO asks:

How much data can the organization tolerate losing?

Example:

RPO:
1 Hour

The backup/recovery design should support that requirement.

69 — Review RTO

RTO asks:

How long can the service remain unavailable?

Example:

RTO:
4 Hours

70 — Compare Recovery Requirements

Business Requirement
        ↓
RPO + RTO
        ↓
Backup / Replication / DR Design

71 — Assess Disaster Recovery

Review:

Recovery Region

Data Replication

Infrastructure Recovery

Application Recovery

DNS Failover

Identity Dependencies

Runbooks

Testing

72 — Review DR Documentation

Ask:

Who Declares Disaster?

Who Performs Recovery?

Where Is Infrastructure Recreated?

How Is Data Restored?

How Is Traffic Redirected?

How Is Recovery Validated?

73 — Review DR Testing

A documented plan without testing may contain unknown assumptions.

Record:

Last DR Test:

Result:

RTO Achieved:

RPO Achieved:

Failures:

Actions:

74 — Assess Automation

Review:

Provisioning

Patching

Backup

Scaling

Monitoring

Deployment

Remediation

Identify unnecessarily manual processes.

75 — Review Infrastructure as Code

Determine:

What Is Managed by IaC?

What Is Manual?

Where Is State Stored?

Who Can Change Infrastructure?

Is Code Reviewed?

76 — Assess Configuration Drift

Compare:

Desired State
     ↓
Actual State

Example:

IaC:
Port 443

Actual:
Port 443 + Port 22 Public

Finding:

Configuration drift.

77 — Review Automation Safety

Automation should include:

Validation

Logging

Error Handling

Permissions

Rollback

Approval Where Required

78 — Assess CI/CD Health

Review:

Source Control

Build

Testing

Security Scanning

Artifacts

Deployment

Approval

Rollback

Monitoring

79 — Review Pipeline Identity

Ask:

Does the pipeline use administrator access?

If yes:

High-Risk Finding

Apply least privilege.

80 — Review Secrets Management

Look for secrets in:

Source Code

Configuration Files

Scripts

Pipeline Files

Logs

Images

81 — Assess Certificate Health

Inventory:

TLS Certificates

Application Certificates

Client Certificates

Signing Certificates

Record:

Owner

Expiration

Renewal Method

Monitoring

82 — Identify Certificate Risk

Example:

Certificate Expiration:
14 Days

Alert:
NONE

Finding:

Potential service outage.

83 — Review Secret Expiration

Check:

Client Secrets

API Tokens

Keys

Passwords

Certificates

Identify credentials approaching expiration.

84 — Assess Cloud Cost Health

Operational health also includes financial efficiency.

Review:

Compute

Storage

Data Transfer

Snapshots

Public IPs

Databases

Licensing

Managed Services

85 — Identify Idle Compute

Example:

VM:
8 vCPU

Average CPU:
2%

Business Use:
Unknown

Investigate whether the resource is:

Oversized

Unused

Required for Standby

86 — Identify Orphaned Resources

Look for:

Unused Disks

Unused Public IPs

Old Snapshots

Old Load Balancers

Unused Network Interfaces

Abandoned Development Resources

87 — Do Not Delete Based on Cost Alone

Before removing:

Confirm Owner

Confirm Purpose

Confirm Dependency

Confirm Backup

Confirm Change Approval

88 — Review Storage Cost

Investigate:

Old Snapshots

Old Backups

Unused Object Versions

Incorrect Storage Tier

Excessive Log Retention

89 — Review Data Transfer

Unexpected transfer costs may indicate:

Architecture Inefficiency

Cross-Region Traffic

Internet Egress

Unexpected Workload Behavior

90 — Review Reserved Capacity and Commitments

Where applicable, evaluate whether predictable workloads could benefit from appropriate pricing commitments.

Do not optimize cost at the expense of required flexibility.

91 — Review Quotas

Assess:

Compute Quota

Storage Quota

IP Limits

API Limits

Database Limits

92 — Identify Quota Risk

Example:

vCPU Quota:
100

Current:
96

Risk:

Autoscaling / Deployment Failure

93 — Assess Operational Documentation

Check whether teams have:

Architecture Diagrams

Runbooks

Recovery Procedures

Deployment Procedures

Escalation Procedures

Ownership Information

94 — Assess Incident Readiness

Ask:

Who receives alerts?

Who is on call?

How are incidents declared?

Where are logs?

How is escalation performed?

Who communicates business impact?

95 — Review Runbooks

Important services should have runbooks for:

Application Failure

VM Failure

Database Failure

Network Failure

Backup Failure

Security Incident

Capacity Issue

Certificate Expiry

96 — Review Change Management

Assess:

How Changes Are Requested

How Changes Are Reviewed

How Changes Are Approved

How Changes Are Deployed

How Changes Are Rolled Back

97 — Review Manual Changes

Uncontrolled console changes can cause:

Configuration Drift

Security Exposure

Audit Gaps

Deployment Inconsistency

98 — Assess Resource Lifecycle

Determine how resources are:

Created

Owned

Monitored

Updated

Backed Up

Decommissioned

99 — Identify Abandoned Resources

Possible indicators:

No Owner

No Tags

No Traffic

No Recent Use

Old Creation Date

No Monitoring

Investigate before removal.

100 — Assess Governance

Review whether standards exist for:

Naming

Tagging

Regions

Identity

Networking

Encryption

Logging

Backup

Resource Creation

101 — Review Policy Enforcement

Where supported, cloud policies can help prevent:

Public Storage

Unapproved Regions

Missing Encryption

Missing Tags

Prohibited Resource Types

102 — Assess Security Governance

Determine whether the organization has defined requirements for:

Privileged Access

MFA

Public Exposure

Encryption

Secrets

Vulnerability Management

Logging

Incident Response

103 — Build the Findings Register

Create:

ID	Domain	Finding	Risk	Priority	Recommendation
F-001	Compute
F-002	Network
F-003	Identity

104 — Classify Findings

Use:

Critical

High

Medium

Low

Informational

105 — Understand Critical Findings

Examples may include:

Exposed Administrative Interface

Compromised Credential

Public Sensitive Data

No Recovery for Critical System

Critical Security Vulnerability

These may require immediate action.

106 — Understand High Findings

Examples:

Excessive Privileges

Missing MFA for Privileged Access

No Tested Backup

Single Point of Failure

Missing Critical Monitoring

107 — Understand Medium Findings

Examples:

Missing Tags

Over-Provisioned VM

Incomplete Documentation

Old Snapshots

Alert Tuning Required

108 — Prioritize by Risk

Do not simply fix:

Easiest Finding First

Prioritize using:

Likelihood
     +
Impact
     +
Business Criticality

109 — Build the Risk Matrix

Likelihood	Impact	Priority
High	High	Critical
Medium	High	High
High	Medium	High
Medium	Medium	Medium
Low	Low	Low

110 — Consider Business Context

Example:

Single VM

may be:

LOW RISK

for a disposable development system.

But:

CRITICAL RISK

for a revenue-generating production application.

111 — Create Remediation Recommendations

Recommendations should be:

Specific

Actionable

Prioritized

Owned

Measurable

Poor:

Improve security.

Better:

Remove direct internet SSH access from production application servers and require approved administrative connectivity.

112 — Build the Remediation Plan

Finding	Action	Owner	Priority	Target Date	Status

113 — Separate Quick Wins

Some findings may be:

High Value
+
Low Complexity

Examples:

Enable Missing Alert

Remove Unused Public IP

Add Resource Owner Tag

Configure Certificate Expiry Alert

114 — Identify Strategic Improvements

Other findings require longer projects:

Multi-Region DR

Identity Redesign

Network Segmentation

Centralized Logging

IaC Migration

115 — Create a Cloud Health Scorecard

Example:

Domain	Score	Status
Compute	8/10	Good
Networking	6/10	Needs Improvement
Storage	7/10	Good
Identity	5/10	Needs Improvement
Security	6/10	Needs Improvement
Availability	7/10	Good
Monitoring	5/10	Needs Improvement
Backup	4/10	High Risk
Automation	7/10	Good
Cost	6/10	Needs Improvement

116 — Do Not Treat Scores as Absolute Truth

The scorecard should:

Summarize Findings

not replace:

Detailed Technical Analysis

117 — Build Overall Health Status

You may use:

HEALTHY

NEEDS IMPROVEMENT

HIGH RISK

CRITICAL

Example:

Overall Status:
NEEDS IMPROVEMENT

118 — Create an Executive Summary

Executives generally need:

Overall Health

Business Risk

Critical Findings

High Findings

Major Recommendations

Remediation Priorities

not hundreds of raw technical observations.

119 — Example Executive Summary

Overall Environment Health:
Needs Improvement

Critical Findings:
0

High Findings:
4

Primary Risks:
- Untested database recovery
- Excessive privileged access
- Single application availability zone
- Incomplete production monitoring

Immediate Priorities:
1. Validate backup restoration
2. Reduce privileged access
3. Improve workload redundancy
4. Expand monitoring coverage

120 — Create the Technical Assessment Report

Use:

Cloud Environment Health Assessment

Executive Summary:

Scope:

Architecture:

Resource Inventory:

Compute Assessment:

Network Assessment:

Storage Assessment:

Identity Assessment:

Security Assessment:

Availability Assessment:

Monitoring Assessment:

Logging Assessment:

Backup Assessment:

Disaster Recovery Assessment:

Automation Assessment:

CI/CD Assessment:

Cost Assessment:

Governance Assessment:

Operational Readiness:

Critical Findings:

High Findings:

Medium Findings:

Low Findings:

Recommendations:

Remediation Roadmap:

Overall Health:

121 — Build the Health Assessment Runbook

Runbook:
Cloud Environment Health Assessment

Assessment Owner:

Environment:

Cloud Platform:

Business Services:

Criticality:

Step 1:
Confirm scope

Step 2:
Inventory resources

Step 3:
Document architecture

Step 4:
Map dependencies

Step 5:
Assess compute

Step 6:
Assess networking

Step 7:
Assess storage

Step 8:
Assess identity

Step 9:
Assess security

Step 10:
Assess availability

Step 11:
Assess monitoring and logging

Step 12:
Assess backup and DR

Step 13:
Assess automation and IaC

Step 14:
Assess CI/CD

Step 15:
Assess cost

Step 16:
Assess governance

Step 17:
Document findings

Step 18:
Prioritize risk

Step 19:
Build remediation plan

Step 20:
Create executive report

122 — Perform Final Integrated Assessment

Assume the following environment:

                     Internet
                        |
                        v
                       DNS
                        |
                        v
                  Load Balancer
                        |
                 +------+------+
                 |             |
                 v             v
              App-01         App-02
                 |             |
                 +------+------+
                        |
                        v
                    Database
                        |
                        v
                     Storage

123 — Initial Observations

You discover:

App-01 CPU:
42%

App-02 CPU:
45%

Database:
Healthy

Storage:
92% Full

Backup:
Enabled

Last Restore Test:
Never

SSH:
Publicly Accessible

Admin MFA:
Enabled

Application Monitoring:
Enabled

Database Monitoring:
Enabled

Storage Alert:
Missing

Certificate:
Expires in 21 Days

Autoscaling:
Not Configured

124 — Identify Findings

Possible findings:

F-001
Storage capacity approaching threshold

F-002
Backup restoration has never been validated

F-003
Administrative SSH publicly exposed

F-004
Storage capacity alert missing

F-005
Certificate approaching expiration

F-006
Application lacks autoscaling

125 — Prioritize

Example:

Finding	Priority
Public Administrative Access	High
Untested Recovery	High
Storage 92% Full	High
Certificate Expiry	High
Missing Storage Alert	Medium
No Autoscaling	Medium

Actual priority should reflect business context and existing compensating controls.

126 — Recommend Remediation

Public SSH
   ↓
Restrict Administrative Access

Untested Backup
   ↓
Perform Restore Test

Storage 92%
   ↓
Increase / Optimize Capacity

Certificate
   ↓
Renew + Configure Expiry Monitoring

Missing Alert
   ↓
Configure Capacity Alert

No Autoscaling
   ↓
Evaluate Workload Scaling Requirements

127 — Validate Remediation

After remediation:

[ ] Public administrative exposure removed
[ ] Restore successfully tested
[ ] Storage capacity healthy
[ ] Capacity alert working
[ ] Certificate renewed
[ ] Certificate monitoring enabled
[ ] Scaling requirement reviewed

128 — Understand Continuous Health Assessment

A health assessment should not necessarily happen only once.

Cloud environments continuously change:

Deployments

New Resources

New Users

New Permissions

Scaling

Certificates

Costs

Security Findings

Therefore:

Assess
   ↓
Remediate
   ↓
Monitor
   ↓
Reassess

129 — Define Assessment Frequency

Depending on organizational requirements:

Continuous Monitoring

Weekly Operational Review

Monthly Health Review

Quarterly Architecture Review

Annual DR Exercise

Different controls may require different frequencies.

130 — Build Health Indicators

Examples:

Availability

Error Rate

CPU

Memory

Storage Capacity

Backup Success

Restore Success

Security Findings

Certificate Expiration

Cost Variance

131 — Build the Cloud Health Dashboard

Conceptually:

+----------------------------------------+
|       CLOUD HEALTH DASHBOARD           |
+----------------------------------------+
| Availability       HEALTHY             |
| Compute            HEALTHY             |
| Network            HEALTHY             |
| Storage            WARNING             |
| Identity           HEALTHY             |
| Security           WARNING             |
| Monitoring         WARNING             |
| Backup             HIGH RISK           |
| Cost               HEALTHY             |
+----------------------------------------+

132 — Create the Final Lab Report

Use:

Lab:
Cloud Environment Health Assessment Lab

Cloud Platform:

Environment:

Business Service:

Assessment Date:

Assessment Scope:

Architecture:

Resource Inventory:

Compute Health:

Network Health:

Storage Health:

Identity Health:

Security Health:

Availability:

Scalability:

Monitoring:

Logging:

Backup:

Restore Validation:

RPO:

RTO:

Disaster Recovery:

Automation:

Infrastructure as Code:

CI/CD:

Configuration Drift:

Certificates:

Secrets:

Cloud Costs:

Unused Resources:

Quotas:

Operational Documentation:

Incident Readiness:

Governance:

Critical Findings:

High Findings:

Medium Findings:

Low Findings:

Quick Wins:

Strategic Improvements:

Overall Health:

Remediation Plan:

Lessons Learned:

🧪 Final Validation Checklist

Validation	Status
Assessment scope defined
Business criticality documented
Resource inventory created
Resource ownership reviewed
Architecture documented
Dependencies mapped
Single points of failure identified
Compute health assessed
CPU reviewed
Memory reviewed
Compute sizing reviewed
Network health assessed
Public exposure reviewed
Administrative access reviewed
Firewall rules reviewed
Segmentation reviewed
DNS reviewed
Load balancers reviewed
Storage capacity reviewed
Storage performance reviewed
Storage security reviewed
Identity inventory completed
Privileged access reviewed
Least privilege reviewed
Dormant identities reviewed
MFA reviewed
Service identities reviewed
Security baseline reviewed
Encryption reviewed
Vulnerability management reviewed
Patching reviewed
Availability reviewed
Autoscaling reviewed
Monitoring coverage reviewed
Alerting reviewed
Logging reviewed
Audit logging reviewed
Backup health reviewed
Restore tested
RPO reviewed
RTO reviewed
DR readiness reviewed
Automation reviewed
IaC reviewed
Configuration drift reviewed
CI/CD reviewed
Secrets reviewed
Certificates reviewed
Cost health reviewed
Idle resources reviewed
Quotas reviewed
Documentation reviewed
Incident readiness reviewed
Governance reviewed
Findings classified
Remediation prioritized
Health scorecard created
Executive summary created
Assessment runbook completed

🎯 Certification Connection

A Cloud+ scenario may say:

All production VMs are running, but storage utilization has reached 95%.

Think:

The environment may be available but has a capacity-health risk.

Another:

Backups complete successfully every night, but no restore has ever been performed.

Think:

Recovery capability has not been validated.

Another:

Production administrative ports are accessible from anywhere on the internet.

Think:

Reduce public exposure and restrict administrative access.

Another:

A workload uses 3% CPU but runs on a very large instance.

Think:

Review rightsizing and cost optimization.

Another:

Autoscaling is configured, but the account is close to its compute quota.

Think:

Capacity and quota risk could prevent scaling.

Another:

A critical TLS certificate expires next week.

Think:

Certificate lifecycle and operational availability risk.

Another:

Infrastructure differs from the approved IaC configuration.

Think:

Configuration drift.

🎤 Interview Questions

Practice without notes.

1. What makes a cloud environment healthy?

2. How would you perform a cloud health assessment?

3. Why create a resource inventory?

4. Why map application dependencies?

5. What is a single point of failure?

6. How would you assess compute health?

7. How would you assess network health?

8. How would you assess storage health?

9. How would you review IAM health?

10. Why review privileged access?

11. How would you assess cloud security?

12. How would you evaluate high availability?

13. Why review autoscaling and quotas together?

14. How would you assess monitoring?

15. Why centralize logging?

16. Why is successful backup completion not enough?

17. What are RPO and RTO?

18. How would you assess disaster recovery?

19. What is configuration drift?

20. How would you assess CI/CD health?

21. How would you identify cloud cost waste?

22. Why review certificates?

23. How do you prioritize findings?

24. What belongs in an executive cloud-health report?

25. How frequently should cloud health be reviewed?

🚨 Scenario Interview Question 1

Management asks whether production is healthy because every VM is running.

A strong answer:

VM state is only one health indicator.

Review:

Availability

Performance

Capacity

Security

Monitoring

Backup

Recovery

Dependencies

Cost

Operations

🚨 Scenario Interview Question 2

Production storage is 92% utilized but the application is still functioning normally.

Think:

Proactive capacity finding.

Do not wait for:

100%
   ↓
Application Failure

🚨 Scenario Interview Question 3

Nightly database backups show successful status.

Is recovery validated?

Not until restore capability has been appropriately tested.

🚨 Scenario Interview Question 4

A production application has two healthy VMs, but both are in the same availability zone.

Think:

Zone-level availability risk.

🚨 Scenario Interview Question 5

The organization has monitoring dashboards but nobody receives alerts.

Think:

Visibility
≠
Operational Response

Review alert ownership and escalation.

🚨 Scenario Interview Question 6

A CI/CD pipeline has full administrator access to the cloud environment.

Think:

Excessive privilege.

🚨 Scenario Interview Question 7

An unused disk has been generating charges for six months.

Before deletion:

Identify Owner
      ↓
Confirm Dependency
      ↓
Confirm Data Requirement
      ↓
Follow Change Process
      ↓
Remove if Approved

🚨 Scenario Interview Question 8

A certificate expires in ten days and no engineer owns the renewal process.

Think:

Operational ownership and certificate lifecycle risk.

🚨 Scenario Interview Question 9

IaC defines one firewall configuration, but production contains additional manually created rules.

Think:

Configuration drift.

🚨 Scenario Interview Question 10

You find 40 assessment issues. Which do you fix first?

Prioritize based on:

Likelihood
+
Impact
+
Business Criticality
+
Existing Controls

not simply the order discovered.

🧠 Cloud Health Assessment Framework

Remember:

SCOPE
  ↓
INVENTORY
  ↓
ARCHITECTURE
  ↓
DEPENDENCIES
  ↓
COMPUTE
  ↓
NETWORK
  ↓
STORAGE
  ↓
IDENTITY
  ↓
SECURITY
  ↓
AVAILABILITY
  ↓
MONITORING
  ↓
BACKUP & DR
  ↓
AUTOMATION
  ↓
COST
  ↓
GOVERNANCE
  ↓
FINDINGS
  ↓
RISK
  ↓
REMEDIATION
  ↓
REASSESS

💬 Interview Tip

Avoid:

“I would check whether all the cloud resources are running.”

A stronger answer is:

“I would begin by defining the assessment scope, business criticality, architecture, resource inventory, and dependencies. I would then assess compute capacity and health, network exposure and connectivity, storage capacity and performance, identity and privileged access, security controls, availability, monitoring and logging, backup and recovery, automation, configuration drift, CI/CD, quotas, certificates, cost efficiency, and operational readiness. I would document findings, prioritize them based on likelihood, impact, and business criticality, create a remediation roadmap, and establish continuous monitoring and reassessment.”

That demonstrates Cloud Engineer and Cloud Operations thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. Cloud Health Assessment Report

Include:

Scope

Architecture

Assessment Domains

Findings

Risk

Recommendations

2. Cloud Architecture Diagram

Show:

Users
  ↓
Network
  ↓
Application
  ↓
Data

plus major dependencies.

3. Resource Inventory

Include:

Resource

Type

Environment

Owner

Criticality

4. Cloud Health Scorecard

Cover:

Compute

Network

Storage

Identity

Security

Availability

Monitoring

Backup

Automation

Cost

5. Findings Register

Document:

Finding

Evidence

Risk

Priority

Recommendation

6. Remediation Roadmap

Separate:

Immediate

Short-Term

Medium-Term

Strategic

improvements.

7. Cloud Health Assessment Runbook

Create a reusable operational assessment procedure.

📝 Resume Examples

Instead of:

Performed cloud health checks.

Use:

Conducted comprehensive cloud environment health assessments across compute, networking, storage, IAM, security, availability, monitoring, backup, disaster recovery, automation, configuration management, and cost optimization.

Or:

Evaluated cloud operational readiness by inventorying resources, mapping service dependencies, identifying single points of failure, reviewing monitoring and recovery controls, assessing configuration drift, and prioritizing remediation based on business risk.

Or:

Developed cloud health scorecards, technical findings registers, executive assessment reports, and prioritized remediation roadmaps for simulated production cloud environments.

⭐ Job-Readiness Check

You should now be able to:

• define cloud environment health

• scope a cloud assessment

• inventory resources

• map architecture

• map dependencies

• identify single points of failure

• assess compute

• assess networking

• assess storage

• assess identity

• assess security

• assess availability

• assess scalability

• assess monitoring

• assess logging

• assess backups

• evaluate restore capability

• understand RPO

• understand RTO

• assess disaster recovery

• assess automation

• assess IaC

• identify configuration drift

• assess CI/CD

• review secrets

• review certificates

• assess cloud costs

• identify idle resources

• assess quotas

• review documentation

• assess incident readiness

• review governance

• classify findings

• prioritize risks

• build remediation plans

• create cloud health scorecards

• create executive reports

• build reusable assessment runbooks

🏆 Mission Complete

You have progressed from:

Is It Running?
      ↓
Yes
      ↓
Everything Must Be Fine

to:

Inventory
   ↓
Architecture
   ↓
Performance
   ↓
Capacity
   ↓
Security
   ↓
Availability
   ↓
Observability
   ↓
Recoverability
   ↓
Automation
   ↓
Operational Readiness
   ↓
Cloud Health

You now understand an important Cloud Engineer principle:

Operational health is not the absence of an outage. A healthy cloud environment is observable, secure, appropriately sized, resilient, recoverable, maintainable, and continuously assessed.

🚀 What’s Next?

You have now completed a broad operational assessment of a cloud environment.

The next step is to move from:

Assessing Current Health

to:

Preparing for Operational Failure

You will build a structured cloud incident-response workflow covering:

Detection

Triage

Severity

Containment

Evidence Collection

Service Restoration

Recovery

Validation

Root-Cause Analysis

Communication

Lessons Learned

You will learn to manage the complete lifecycle:

ALERT
  ↓
TRIAGE
  ↓
CLASSIFY
  ↓
INVESTIGATE
  ↓
CONTAIN
  ↓
RECOVER
  ↓
VALIDATE
  ↓
DOCUMENT
  ↓
IMPROVE

➡️ Next: Lab 27 — Cloud Incident Response Lab