Cloud did not remove the old security problems. It moved them into a control plane where a single API call can do what used to require physical access to a data center.
Week 12 covers what changes, what stays the same, and the handful of mistakes responsible for most real cloud incidents.
Shared Responsibility, Stated Plainly
Every major provider publishes a shared responsibility model. The provider secures the infrastructure. You secure what you put on it and how you configure it.
The boundary shifts by service type. With raw virtual machines you own the operating system, the patching, and the network rules. With managed services you own much less, but you always own identity, permissions, and data configuration.
Almost every publicized cloud breach has landed on the customer side of that line. Not because providers are perfect, but because misconfiguration is a much larger and much easier target.
Cloud IAM Is the Real Perimeter
In a traditional network, reaching a system required a network path. In a cloud account, an identity with the right permissions can reach almost anything from anywhere with an API call.
That makes identity and access management the actual security boundary. The recurring failures are wildcard permissions granted during a rushed deployment, roles that can assume other roles in a chain nobody mapped, long lived access keys checked into a repository, and no multi factor authentication on privileged accounts.
You learn to read a policy document and answer the only question that matters, which is what can this identity actually do, including everything it can reach indirectly.
Where the Data Leaks
Three places account for a large share of exposure. Object storage set to public, either directly or through a policy nobody read carefully. Secrets committed to source control or baked into container images. And the instance metadata service.
The metadata service is worth understanding in detail because it is a genuinely elegant attack. A workload can query a local address to get temporary credentials for its assigned role. If that workload can be made to fetch a URL of an attacker's choosing, which is a server side request forgery flaw, the attacker gets those credentials. Version two of the service on AWS and the equivalent protections elsewhere exist specifically to make that harder.
Seeing in the Cloud
You cannot investigate what was not logged. The core sources are the control plane audit log, which records every API call, plus network flow logs, storage access logs, and identity provider logs. On AWS the control plane log is CloudTrail, on Azure it is the Activity Log, and on Google Cloud it is Cloud Audit Logs.
Cloud security posture management tools continuously check configuration against known bad patterns. Well known options include Wiz, Palo Alto Prisma Cloud, and the providers own services such as AWS Security Hub and Microsoft Defender for Cloud. There are also free open source scanners such as Prowler and CloudSploit.
Containers and Kubernetes
Containers add their own surface. Images pull in dependencies with known vulnerabilities, registries are often more open than intended, and a container running as root with the host filesystem mounted is not really isolated at all.
Kubernetes adds a control plane with its own identity system, its own network policy model, and a long list of defaults that favor convenience. The specific items that come up again and again are exposed dashboards and API servers, over-permissive role bindings, secrets stored as base64 encoded text rather than encrypted, and no network policy at all, which means every pod can talk to every other pod.
The Center for Internet Security publishes benchmarks for Kubernetes and the major cloud providers, and they make a good starting checklist. See the CIS Controls guide for how benchmarks relate to the controls.
The Challenge: Audit a Cloud Account
You get an account with problems in it and produce a real assessment: the identities and what they can reach, the public exposure, the logging gaps, and a ranked list of what to fix.
The ranking matters again. A public bucket with test data is not the same finding as an access key with administrative permissions sitting in a public repository, and being able to explain why is the skill.
Learn This at HackRange
Cloud security is one of the highest demand specialties in the field, and it rewards people who understand both the traditional fundamentals and the control plane.