Cloud & Container
Security Training

Cloud security training teaches engineers to treat the account and the image as security boundaries they configure deliberately, rather than as infrastructure that happens to isolate things.

These exercises cover what actually goes wrong in production: a bucket that answers anonymous requests, a wildcard policy on a role nobody thought was important, a key that leaked months ago and still works, a credential recorded in a build layer, and a container started with more host access than the workload needs.

Cloud Infrastructure Security runs against AWS: public storage buckets, over-permissive IAM and role-passing escalation, long-lived access keys, instance metadata abuse, security groups open to the internet, subdomain takeover, audit logging gaps, serverless over-privilege, and cross-account trust with service control policies.

Container & Image Security covers the layer underneath: image layers, the daemon, registries, base images, and container networking.

Because a cloud credential is not a key to one room. It is a key to everything that credential is permitted to reach, and the cloud API can create, read and delete the infrastructure the application runs on.

A wildcard policy on a build agent, a function with an administrative role, or a role that trusts a whole account each turn a small foothold into account-wide reach without a single exploit.

Not by default. Container isolation is a set of kernel features, and a deployment can switch nearly all of them off without anything looking broken.

Root inside a container is root on the host kernel, so a privileged flag plus a host mount turns code execution in a low-value service into control of the machine underneath it. The boundary is something you configure, not something you get.

Image layers are append-only. A credential passed into one RUN is recorded in that layer, and a later RUN that removes the file only stacks a new layer on top.

Anyone who pulls the image gets every layer, so the value is still readable. Rotation is the step that cuts access; a multi-stage build or a BuildKit secret mount is what stops it happening again.

Cloud and platform engineers who hold account credentials, DevOps engineers and SREs who own the build pipeline and the infrastructure it deploys, and developers who write Dockerfiles or ship serverless functions.

Most of the fixes here are not application code. They are IAM policies, bucket settings, security group rules, trust policies, base-image pins, and daemon configuration, which makes the exercises useful for the people who own those settings as much as for the people writing the service.

Yes. Every exercise runs in your browser with no sign-up required.

Enterprise features such as completion analytics, SCORM and LTI packaging for your LMS, SSO, and custom content are available on paid plans.