06 Cloud Security Practice

Welcome to the Cloud Security Practice Path.

Cloud security brings together many of the skills you have already developed:

identity
networking
Linux
Windows
web applications
authentication
authorization
logging
monitoring
incident response
ethical hacking
attack-path analysis

But cloud environments introduce a major change:

Identity and configuration often become more important than the underlying server.

In traditional environments, you may think primarily about:

User
  ↓
Computer
  ↓
Network
  ↓
Server

In cloud environments, the security relationship often looks more like:

Identity
   ↓
Permission
   ↓
Cloud Service
   ↓
Resource
   ↓
Workload
   ↓
Data

Understanding these relationships is one of the most important skills in modern cloud security.

Path Objective

By completing this practice path, you should develop practical understanding of:

cloud shared responsibility
cloud identity and access management
users, roles and service identities
permissions
cloud networking
public exposure
storage security
compute security
secrets
metadata services
logging and monitoring
cloud misconfigurations
cloud privilege escalation concepts
attack-path analysis
cloud incident investigation
multi-cloud security thinking
cloud security reporting
remediation

The objective is not to memorize the interface of one provider.

The objective is to understand cloud security principles that transfer across AWS, Azure and Google Cloud.

Recommended Cloud Security Journey

Follow this sequence:

Cloud Fundamentals
       ↓
Shared Responsibility
       ↓
Cloud Identity
       ↓
IAM Permissions
       ↓
Cloud Networking
       ↓
Storage Security
       ↓
Compute & Workloads
       ↓
Secrets & Credentials
       ↓
Logging & Monitoring
       ↓
Cloud Misconfigurations
       ↓
Privilege Escalation Concepts
       ↓
Cloud Attack Paths
       ↓
Incident Investigation
       ↓
Remediation
       ↓
Cloud Challenges

Stage 01 — Understand Cloud Computing

Before studying cloud security, understand what cloud environments provide.

Cloud platforms commonly offer services for:

compute
storage
networking
databases
identity
containers
serverless
logging
monitoring
security
artificial intelligence
application hosting

Instead of purchasing and managing every physical system yourself, organizations consume these resources as services.

A simplified environment might look like:

Users
  ↓
Cloud Identity
  ↓
Cloud Platform
  ├── Compute
  ├── Storage
  ├── Network
  ├── Database
  └── Applications

Each service creates different security responsibilities.

Stage 02 — Shared Responsibility

One of the most important cloud-security concepts is the Shared Responsibility Model.

The cloud provider secures the underlying cloud infrastructure.

The customer remains responsible for many areas such as:

identities
permissions
workloads
data
configuration
application security
access management

Conceptually:

Cloud Provider
      +
Customer
      ↓
Cloud Security

The exact division depends on the service being used.

Security Question

For every cloud service, ask:

Which security responsibilities belong to the provider, and which still belong to us?

This question should become automatic.

Stage 03 — Understand Cloud Accounts and Tenants

Cloud resources usually exist within some administrative boundary.

Examples include:

AWS accounts
Azure tenants and subscriptions
Google Cloud organizations and projects

A simplified structure may look like:

Organization
    ↓
Account / Subscription / Project
    ↓
Resources

Larger organizations may operate hundreds of these environments.

Security therefore requires both individual-resource protection and governance across the broader cloud estate.

Stage 04 — Cloud Identity Fundamentals

Identity is often the most important security boundary in cloud environments.

Cloud platforms may contain:

human users
administrators
roles
service accounts
applications
managed identities
workloads
automation identities

Think:

Identity
   ↓
Authentication
   ↓
Permission
   ↓
Cloud Resource

If the identity layer is compromised, attackers may not need to exploit a traditional operating-system vulnerability at all.

Stage 05 — Human and Workload Identities

Separate identities into two broad categories.

Human Identities

Examples:

Cloud Administrator

Developer

Security Analyst

Database Administrator

Workload Identities

Examples:

Virtual Machine Role

Application Identity

Service Account

Container Identity

Automation Identity

Workload identities require the same level of security attention as human accounts.

In many modern environments, they may have extremely powerful permissions.

Stage 06 — Authentication Security

Cloud platforms commonly support:

passwords
MFA
federation
SSO
access tokens
API credentials
temporary credentials
workload identities

A strong cloud environment should reduce dependency on long-lived static credentials wherever possible.

Think:

User
 ↓
Identity Provider
 ↓
MFA
 ↓
Cloud Platform
 ↓
Temporary Session

This is generally stronger than relying on permanent credentials alone.

Stage 07 — IAM Permissions

Identity and Access Management determines what identities can do.

Conceptually:

Identity
   ↓
Role / Policy
   ↓
Permission
   ↓
Resource

A permission might allow an identity to:

read data
modify configuration
start workloads
create users
assign roles
access secrets
delete resources

The key question is:

Does this identity really need this permission?

Stage 08 — Least Privilege

Cloud IAM should follow the principle of least privilege.

Instead of:

Developer
   ↓
Full Administrator

prefer:

Developer
   ↓
Required Development Permissions

The challenge is that cloud permissions can become complex very quickly.

Over time, organizations often accumulate excessive privileges.

This creates opportunities for unintended access and privilege escalation.

Stage 09 — Effective Permissions

Do not look only at one policy or role.

An identity’s actual access may come from several sources.

Conceptually:

Direct Permission
      +
Group Membership
      +
Role Assignment
      +
Inherited Permission
      +
Resource Policy
      ↓
Effective Access

Always think about the effective permissions, not just the most obvious assignment.

Stage 10 — Cloud Privilege Levels

Begin categorizing identities by privilege.

For example:

Read Only
   ↓
Operator
   ↓
Developer
   ↓
Resource Administrator
   ↓
Security Administrator
   ↓
Identity Administrator
   ↓
Organization Administrator

Exact role names vary by cloud provider.

The principle does not.

Higher privileges should receive stronger protection and monitoring.

Stage 11 — Cloud Networking

Cloud networking introduces virtual networking constructs.

Depending on the platform, these may include:

virtual networks
VPCs
subnets
routing tables
security groups
network security groups
firewall rules
gateways
load balancers

Conceptually:

Internet
   ↓
Cloud Firewall
   ↓
Virtual Network
   ↓
Subnet
   ↓
Workload

Network configuration can significantly affect cloud exposure.

Stage 12 — Public and Private Resources

One of the first cloud-security questions should be:

Is this resource publicly reachable?

Resources may be:

Public
Private
Restricted
Internal

Public access is not always wrong.

A public website obviously needs Internet access.

But a database, administrative interface or management service may not.

Always evaluate exposure in context.

Stage 13 — Security Groups and Firewall Rules

Cloud firewall controls commonly restrict traffic based on:

source
destination
protocol
port

A rule might conceptually state:

Source: Internet

Destination: Web Server

Port: 443

Action: Allow

That may be perfectly valid.

But something like:

Source: Internet

Destination: Administrative Service

Port: Management Port

Action: Allow

may deserve closer investigation.

Stage 14 — Cloud Storage Security

Cloud object storage is widely used for:

application files
backups
logs
documents
media
data exports

Security questions include:

Is the storage public?

Who can read the data?

Who can modify the data?

Is encryption enabled?

Are access logs available?

Are sensitive files stored here?

Are old permissions still required?

Cloud storage exposures are frequently caused by configuration rather than software vulnerabilities.

Stage 15 — Data Security

Cloud security must protect data throughout its lifecycle.

Think in terms of:

Data at Rest

Data in Transit

Data in Use

Security controls may include:

encryption
access control
key management
classification
retention
monitoring
backups

Do not treat encryption as a substitute for access control.

Both matter.

Stage 16 — Cloud Compute

Cloud compute may include:

virtual machines
container platforms
managed applications
serverless functions

Each workload type introduces different security concerns.

A virtual machine may require attention to:

Operating System

Patching

Network Exposure

IAM Role

Secrets

Installed Software

Logging

A serverless workload shifts some responsibilities but still requires secure:

permissions
code
dependencies
secrets
event sources
logging

Stage 17 — Workload Identity

Cloud workloads frequently need access to other cloud services.

For example:

Application
    ↓
Workload Identity
    ↓
Storage

This is preferable to embedding permanent credentials inside application code.

However, the workload identity itself must still follow least privilege.

Stage 18 — Metadata Services

Cloud workloads may access metadata services that provide information about the instance or workload.

Depending on the environment, metadata may include temporary credentials.

Conceptually:

Workload
   ↓
Metadata Service
   ↓
Temporary Identity Information

This creates an important security boundary.

Applications should be designed so that untrusted input cannot unexpectedly access sensitive internal services.

Stage 19 — Secrets Management

Cloud applications require secrets such as:

API keys
database credentials
certificates
tokens
passwords

Avoid storing secrets directly in:

Source Code

Scripts

Images

Configuration Repositories

Public Storage

Use dedicated secrets-management mechanisms where possible.

Stage 20 — Static Credentials

Long-lived access keys can create significant risk.

Ask:

Who owns this credential?

When was it created?

Where is it stored?

When was it last used?

What permissions does it have?

Can it be replaced with temporary credentials?

Unused credentials should not remain active indefinitely.

Stage 21 — Cloud Logging

Cloud platforms generate rich audit information.

Important categories include:

authentication
administrative actions
resource creation
IAM changes
network activity
storage access
application activity
security alerts

Conceptually:

Cloud Activity
      ↓
Audit Logs
      ↓
Central Logging
      ↓
Detection
      ↓
SOC

Logging should be treated as a fundamental security control.

Stage 22 — Control Plane vs Data Plane

Begin understanding the distinction between:

Control Plane

Management operations.

Examples:

Create Resource

Delete Resource

Change Permissions

Modify Network Rule

Data Plane

Operations involving the data or workload itself.

Examples:

Read Object

Write Database Record

Access Application Data

Both may require monitoring.

Stage 23 — Cloud Security Monitoring

Cloud monitoring should help detect activities such as:

unusual authentication
privilege changes
new credentials
public exposure
disabled logging
suspicious API activity
unusual workload behavior
high-risk configuration changes

The exact detection mechanisms vary by platform.

The investigation methodology does not.

Stage 24 — Cloud Misconfigurations

Many cloud security issues originate from configuration weaknesses.

Examples include:

public storage
excessive IAM permissions
exposed administrative services
unrestricted network rules
unused credentials
missing MFA
insecure secrets
disabled logging
overly trusted roles

Think:

Configuration
      ↓
Security Assumption
      ↓
Unexpected Exposure
      ↓
Potential Attack Path

Stage 25 — Understand Cloud Enumeration

During an authorized assessment, enumeration helps you understand the cloud environment.

You may need to identify:

Current Identity

Account / Subscription / Project

Assigned Roles

Effective Permissions

Available Resources

Storage

Compute

Networking

Secrets

Logging

Security Services

Enumeration should always remain within authorized scope.

Stage 26 — Current Identity

One of the first questions in any cloud-security assessment is:

Who am I?

Determine:

Identity

Account

Role

Permissions

Session Context

Without understanding your current identity, it is difficult to understand the security boundary you are testing.

Stage 27 — Permission Enumeration

Next, ask:

What can this identity actually do?

Consider permissions involving:

IAM
compute
storage
secrets
networking
automation
deployment services

The security impact of one permission may depend heavily on another.

Stage 28 — Cloud Privilege Escalation Concepts

Cloud privilege escalation often occurs through permissions and trust relationships rather than operating-system exploits.

Conceptually:

Low-Privilege Identity
        ↓
Interesting Permission
        ↓
Modify Resource / Identity
        ↓
Assume or Obtain New Access
        ↓
Higher Privilege

The exact technique varies between platforms.

The important skill is recognizing relationships that allow privilege to increase.

Stage 29 — Think in IAM Relationships

Consider:

User
 ↓
Permission
 ↓
Role
 ↓
Resource

Now imagine the user can modify the role:

User
 ↓
Can Modify
 ↓
Privileged Role
 ↓
Sensitive Resource

This relationship may be much more important than the user’s direct permissions.

Stage 30 — Cloud Attack Paths

Cloud attacks often involve a chain of weaknesses.

For example:

Exposed Application
       ↓
Workload Identity
       ↓
Excessive Permission
       ↓
Access to Secrets
       ↓
Higher-Privilege Identity
       ↓
Sensitive Cloud Resource

The individual findings might seem moderate.

The combined attack path may be critical.

Stage 31 — Cross-Service Attack Paths

Cloud services are highly interconnected.

For example:

Compute
   ↓
IAM Role
   ↓
Secrets
   ↓
Database

or:

CI/CD
  ↓
Deployment Identity
  ↓
Cloud Account
  ↓
Production Resources

Security assessments should therefore examine relationships between services, not just each service individually.

Stage 32 — Cloud Workload Compromise

If a cloud workload is compromised, determine what the workload can access.

Ask:

Which identity does it use?

Which network can it reach?

Which secrets can it access?

Which APIs can it call?

Which storage can it read?

Can it change its own permissions?

This is where workload security and cloud IAM meet.

Stage 33 — Containers and Kubernetes

Cloud environments increasingly use containers and Kubernetes.

At this stage, understand the connection:

Cloud Account
    ↓
Kubernetes Cluster
    ↓
Node
    ↓
Pod
    ↓
Workload Identity
    ↓
Cloud Resource

A weakness inside a workload can sometimes affect the underlying cloud environment if identities and permissions are poorly designed.

Detailed Kubernetes security should remain in the dedicated Kubernetes security learning areas.

Stage 34 — Serverless Security

Serverless architectures remove some traditional infrastructure management but do not remove security responsibilities.

Review:

function permissions
event sources
secrets
APIs
dependencies
logging
input validation

Think:

Event
 ↓
Function
 ↓
Workload Identity
 ↓
Cloud Resource

Again, IAM becomes central.

Stage 35 — Infrastructure as Code Awareness

Modern cloud infrastructure is commonly created using code.

Examples include:

Terraform
CloudFormation
Bicep
ARM templates

This means cloud misconfigurations can originate before resources are deployed.

Think:

Infrastructure Code
       ↓
Deployment
       ↓
Cloud Configuration
       ↓
Security Exposure

Secure cloud engineering should therefore evaluate both deployed resources and the code that created them.

Stage 36 — Cloud Incident Investigation

Cloud investigations often begin with an identity or API event.

Example:

09:02 — Unusual Login

09:05 — New Access Credential Created

09:08 — IAM Permission Modified

09:11 — Storage Accessed

09:15 — Logging Configuration Changed

Instead of analyzing each event independently, build a timeline.

Stage 37 — Cloud Investigation Questions

When reviewing suspicious cloud activity, ask:

Which identity acted?

How did the identity authenticate?

What source IP was used?

Which API action occurred?

Which resource was affected?

Was the action successful?

What permissions made it possible?

What happened next?

Was logging altered?

Were additional identities created?

Stage 38 — Identity Investigation

Suppose you observe:

User: developer01

Action: Privileged Role Assignment

Result: Success

Do not immediately classify the activity as malicious.

Investigate:

Was this expected?
Who approved the change?
What role was assigned?
How long was it active?
What actions followed?
Did the same identity authenticate from unusual locations?

Context remains essential.

Stage 39 — Cloud Persistence Concepts

Persistence in cloud environments may involve maintaining future access through identity or configuration changes.

Security teams should monitor for unexpected creation or modification of:

users
credentials
roles
service identities
application identities
automation
access policies

The defensive principle is:

Unexpected identity changes deserve investigation.

Stage 40 — Logging Tampering

Attackers may attempt to reduce visibility.

Important events may include:

Audit Logging Disabled

Log Destination Changed

Security Service Disabled

Monitoring Rule Removed

Changes to logging infrastructure should receive strong scrutiny.

Stage 41 — Cloud Incident Timeline

Use a timeline such as:

08:55 — Authentication from new source

08:57 — Privileged role assumed

09:01 — Secret retrieved

09:04 — New resource created

09:07 — Storage accessed

09:10 — Logging modified

Then ask:

What was the first suspicious event?

Which identity initiated activity?

How did privileges change?

Which resources were accessed?

What is the scope?

Stage 42 — Multi-Cloud Thinking

Organizations may simultaneously use:

AWS

Microsoft Azure

Google Cloud

Do not become dependent on provider-specific terminology.

Translate concepts.

For example:

Security Concept	AWS	Azure	Google Cloud
Administrative boundary	Account	Subscription	Project
Human/workload access	IAM	Entra ID / RBAC	Cloud IAM
Virtual network	VPC	VNet	VPC
Object storage	S3	Blob Storage	Cloud Storage
Compute	EC2	Virtual Machines	Compute Engine

Names change.

Security principles remain similar.

Stage 43 — Cloud Security Assessment Methodology

Develop a repeatable assessment process.

1. Confirm Authorization

2. Identify Cloud Platform

3. Identify Account / Tenant / Project

4. Determine Current Identity

5. Enumerate Permissions

6. Identify Important Resources

7. Review IAM

8. Review Network Exposure

9. Review Storage

10. Review Compute

11. Review Workload Identities

12. Review Secrets

13. Review Logging

14. Identify Misconfigurations

15. Map Potential Attack Paths

16. Validate Findings Safely

17. Determine Business Impact

18. Collect Evidence

19. Recommend Remediation

20. Report

Stage 44 — Cloud Security Remediation

Typical cloud security improvements may include:

enforcing MFA
removing unused accounts
reducing IAM permissions
replacing static credentials
using workload identities
restricting public access
limiting network exposure
securing secrets
enabling audit logging
centralizing logs
protecting privileged identities
continuously reviewing configuration

Cloud security is not one configuration change.

It is an ongoing governance and engineering discipline.

Stage 45 — Cloud Security Finding

Use a professional structure.

Finding Title:

Cloud Platform:

Account / Subscription / Project:

Affected Identity:

Affected Resource:

Description:

Permission / Configuration:

Evidence:

Attack Path:

Security Impact:

Likelihood:

Risk:

Root Cause:

Recommended Remediation:

Validation:

Cloud Security Practice Worksheet

Use this during meaningful TryHackMe cloud exercises.

Cloud Platform:

Environment:

Account / Subscription / Project:

Current Identity:

Authentication Method:

Assigned Roles:

Effective Permissions:

Compute Resources:

Storage Resources:

Network Resources:

Public Resources:

Service / Workload Identities:

Secrets Identified:

Logging Status:

Security Services:

Potential Misconfigurations:

Potential Privilege Paths:

Validated Findings:

Attack Path:

Affected Data / Resources:

Detection Opportunities:

Security Impact:

Recommended Remediation:

Lessons Learned:

Build a Cloud Attack Map

For larger exercises, create a simple map.

Example:

Developer
   ↓
Cloud Role
   ↓
Virtual Machine
   ↓
Workload Identity
   ↓
Secret Store
   ↓
Database

Then add permissions.

Developer
   ↓
Can Modify
   ↓
Workload Identity
   ↓
Can Read
   ↓
Production Secrets

Now the security relationship becomes much easier to understand.

Cloud Security Skills Checklist

Before completing this path, evaluate yourself.

Cloud Fundamentals

I understand cloud computing
I understand shared responsibility
I understand cloud administrative boundaries
I understand common cloud service models

Identity

I understand cloud IAM
I understand human identities
I understand workload identities
I understand MFA
I understand temporary versus long-lived credentials

Permissions

I understand roles and policies
I understand least privilege
I understand effective permissions
I understand privilege relationships

Networking

I understand virtual networks
I understand subnets
I understand cloud firewall rules
I can recognize unnecessary public exposure

Workloads

I understand cloud virtual machines
I understand workload identity
I understand serverless security conceptually
I understand basic container-cloud relationships

Data

I understand storage security
I understand access control
I understand encryption concepts
I understand secrets management

Monitoring

I understand cloud audit logs
I understand control-plane activity
I can build a cloud investigation timeline
I understand why logging changes are security-sensitive

Attack Paths

I understand cloud misconfigurations
I understand IAM privilege escalation conceptually
I can identify relationships between identities and resources
I understand cross-service attack paths

Incident Response

I can identify a suspicious cloud identity
I can investigate related API actions
I can determine potentially affected resources
I understand cloud containment considerations

Reporting

I can document a cloud security finding
I can describe an attack path
I can explain business impact
I can recommend remediation

Think Like a Cloud Security Professional

Whenever you enter a cloud environment, train yourself to ask:

Which cloud environment am I in?

What is the administrative boundary?

Who am I?

How did I authenticate?

What permissions do I have?

What identities exist?

Which identities are privileged?

What resources exist?

Which resources are public?

Which workloads have cloud identities?

Where are secrets stored?

Which relationships create privilege?

What logging is enabled?

What changes would defenders see?

What attack paths are possible?

What is the actual business impact?

How should the environment be hardened?

This way of thinking transfers across cloud platforms.

From TryHackMe to GoHackersCloud Labs

TryHackMe should provide the practice and repetition layer.

Your progression should then move toward deeper cloud environments.

Cloud Fundamentals
       ↓
TryHackMe Cloud Practice
       ↓
Cloud Security Challenges
       ↓
GoHackersCloud Cloud Labs
       ↓
AWS / Azure / GCP Security Labs
       ↓
Cloud Security Runbooks
       ↓
Cloud Incident Scenarios
       ↓
Cloud Pentesting Projects
       ↓
Enterprise Cloud Security Assessments

The objective is to move from guided exercises toward environments where you must independently determine:

What exists?

Who has access?

What is exposed?

Which permissions matter?

What can be chained?

What evidence proves the risk?

How would defenders detect it?

How should it be fixed?

Path Complete

You have now completed the core TryHackMe Practice Paths:

00 Introduction
       ↓
01 Beginner Cybersecurity Path
       ↓
02 SOC Analyst Practice
       ↓
03 Ethical Hacking Practice
       ↓
04 Web Security Practice
       ↓
05 Active Directory Practice
       ↓
06 Cloud Security Practice

These paths are not intended to replace your main learning tracks.

They provide a structured hands-on practice layer between learning cybersecurity concepts and performing larger GoHackersCloud Labs, Runbooks and projects.

What’s Next?

➡️ Challenge Tracking

Your next step is to stop measuring progress only by completed rooms and begin tracking skills, investigations and independent capability.

In Challenge Tracking, you will create a simple system for recording:

completed practice
technology covered
skill category
difficulty
concepts learned
tools used
mistakes made
independent completion
areas requiring more practice
readiness for GoHackersCloud Labs

The goal is to answer one important question:

Am I just completing cybersecurity exercises, or am I becoming capable of performing the work independently?

This completes the six-path TryHackMe practice progression and gives us a clean transition into **`Challenge Tracking`**, followed by the final **`Labs`** section.