Cloud Security Essentials
Trace identity, public exposure, and audit evidence through an approachable cloud incident scenario.
Start here
Course introduction
Cloud incidents rarely fit inside one service. This course follows an approachable scenario across identity, storage exposure, and audit evidence without requiring access to a real cloud account.
The exercises use a mock identity trace and an embedded page clue. They reinforce checking the underlying evidence instead of trusting a summary label.
By the end of this course, you can
- Trace effective permissions across identities, functions, and storage.
- Investigate exposure using policy, configuration, and audit evidence.
- Contain a cloud incident while preserving the evidence needed to learn from it.
- Design guardrails that prevent unsafe defaults from returning.
Learn, then practice
Course lessons
Work through these 5 lessons in order. Each lesson introduces one concept, then gives you a practical activity or lab to apply it.
Permissions form a path
Not startedCloud risk often comes from several individually reasonable permissions that become dangerous when combined.
Review what an identity can read, what it can change, and which other role it can assume. A service account that cannot access data directly may still be able to update a function that runs as a stronger role.
Least privilege is not just a shorter action list. It also limits resources, conditions, session duration, and who may delegate the identity.
Allow: update function code
Resource: billing-exporter
billing-exporter runs as: finance-read-role
The effective path includes the permissions of the runtime role, not only the caller's policy.
Course challenge
Follow the permission path
The deploy bot cannot read invoices directly. Enter the role that gains the read permission when the function runs.
deploy-bot
└─ can update: billing-exporter
└─ runs as: finance-read-role
└─ can read: invoice-archive
Public is a state, not a label
Not startedA private resource can become reachable through a policy, signed URL, proxy, snapshot, or copied object.
Check the complete access path. Storage settings may say private while a content-delivery rule still allows anonymous reads. A database may reject public traffic while a snapshot is shared with another account.
When exposure is confirmed, preserve the relevant audit details while blocking the exposed path. Record configuration and access history before making broader cleanup changes so you can still determine what happened.
This is the part people usually overlook. Fixing the visible setting can erase context without answering who accessed the resource.
Course challenge
Inspect the evidence panel
The visible panel looks empty. Inspect its HTML and find the value of the data-evidence attribute. That is the role used by the mock export job.
Contain without going blind
Not startedFast containment matters, but deleting the affected resource can remove the evidence needed to understand the incident.
Disable the narrowest risky path first. Revoke a key, block a public policy, or detach a role while preserving logs, configuration history, and relevant snapshots.
Then trace the identity backward and the data forward. Ask how the credential was issued, what it accessed, and whether a replacement credential inherited the same weakness.
1. Block the exposed path
2. Preserve logs and configuration history
3. Rotate affected credentials
4. Trace access and data movement
5. Fix the policy pattern that allowed it
Rotation without policy repair often recreates the same incident with a new key.
Course challenge
Build the first-response order
The export role was exposed ten minutes ago. Put these four actions in the order that contains the path and preserves useful evidence.
Select the steps in the order they should happen.
Follow credential lineage
Not startedRotating a key helps only when you know which workload used it and whether an older copy still works.
Inventory the issuer, workload, last use, and replacement for every long-lived credential. A key with no clear owner is not harmless. It is a path nobody is watching.
During an incident, compare issue and use times. A credential used after its replacement became active may reveal a forgotten deployment or copied secret. Treat the audit trail like a small forensics puzzle: establish the rotation boundary, isolate the event that crosses it, then name the workload that still needs attention.
Course challenge
Identify the stale credential
The replacement became active at 09:20. Which credential was used afterward, and by which workload? Enter the finding as credential/workload.
09:12 key-201 export-job read invoice-archive
09:20 key-305 rotation replacement active
09:27 key-201 unknown-workload read invoice-archive
09:31 key-305 export-job read invoice-archive
Make the safe state the default
Not startedThe best incident fix also makes the same mistake harder to repeat.
Prefer organization-level controls for risks that should never be optional. Block public storage by default, require short-lived workload identities, and alert on policy changes that widen access.
A dashboard warning is useful, but it still depends on someone noticing it. A preventive control stops the unsafe state before it becomes an incident.
Course challenge
Choose the preventive control
Teams keep accidentally publishing storage buckets. Which control prevents the mistake instead of only reporting it?
Continue learning
Up next: Cryptography for Developers
Make safer engineering decisions about encoding, password storage, encryption, nonces, and signature verification.