Module 11: Cloud security fundamentals
Estimated time: 3-4 hours (including the exercise) · Prerequisites: M2 (networking), M6 (identity)
Security+ SY0-701 domains supported: 3.0 Security Architecture (primary), plus cloud monitoring content from 4.0 Security Operations.
Almost every Australian organisation now runs something in the cloud, and a growing share of the alerts a SOC analyst works come from cloud platforms, not on-premises servers. This module gives you the mental model: what the cloud actually is, exactly who is responsible for securing what, and why most cloud breaches are boring mistakes rather than genius hacks.
What you'll get from this module
- Explain what "the cloud" actually is, without hand-waving.
- Tell IaaS, PaaS and SaaS apart using services you already know.
- Name the big three providers and which one dominates Australian job ads.
- Draw the shared responsibility model from memory, the single most examined cloud concept.
- List the real causes of cloud breaches (spoiler: misconfiguration, not exotic exploits).
- Know where cloud logs live and why SOC analysts care.
- Pick a sensible free-to-study cloud cert to sit alongside Security+.
1. What "the cloud" actually is
Strip away the marketing and the cloud is:
Someone else's data centre, rented over the internet, controlled through APIs.
When you "spin up a server in the cloud," a real physical machine in a real building (guarded, air-conditioned, powered) runs a virtual machine for you, exactly the VM concept from M1, just running on hardware you'll never see. You control it through a web console or an API (a programmatic interface: commands sent over the network).
Two consequences matter for security:
- You can't physically secure what you don't own. The provider handles guards, cameras and cabling. Your job moves up the stack.
- Everything is an API call. Creating servers, opening firewall ports, reading storage, it's all commands authenticated by credentials. Whoever holds the credentials holds the cloud. That's why identity (M6) is about to become the whole game.
2. IaaS, PaaS, SaaS: the three service models
| Model | What you rent | Plain example | Kitchen analogy |
|---|---|---|---|
| IaaS: Infrastructure as a Service | Virtual machines, networks, storage. You install and run everything on top. | An AWS EC2 or Azure virtual machine running your web server | Renting a bare commercial kitchen, you bring chefs, recipes, ingredients |
| PaaS: Platform as a Service | A managed platform to run your code or data. No OS to patch. | A managed database, or Azure App Service hosting your web app | A kitchen with equipment and staff, you just bring the recipe |
| SaaS: Software as a Service | A finished application. You just use it. | Gmail, Microsoft 365, Xero, Canva | Ordering the finished meal |
The further right you go (IaaS → SaaS), the less you manage, and, as we'll see, the less you're responsible for securing. But you're never responsible for nothing.
3. The big three, and the Australian angle
- AWS (Amazon Web Services), the largest globally, huge in startups and tech companies.
- Microsoft Azure, deeply tied into Microsoft 365 and Active Directory / Entra ID.
- Google Cloud, strong in data and analytics workloads.
All three run Sydney regions (physical data centre clusters in Australia), which matters because many Australian government and regulated workloads must keep data onshore.
The job-ad reality: because almost every Australian corporate and government environment already runs Microsoft 365 and Entra ID, Azure/M365 security skills appear most often in Australian entry-level job ads. AWS is a strong second. If you're optimising for employability here, Microsoft first is a defensible choice, but the concepts in this module transfer across all three.
4. The shared responsibility model: THE core concept
If you remember one thing from this module, make it this:
The provider secures the cloud. You secure what you put IN the cloud.
The provider will patch the hypervisor and guard the building. The provider will not stop you making your storage bucket public, giving every user admin rights, or leaving MFA off. Who secures each layer depends on the service model:
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical data centre | Provider | Provider | Provider |
| Network infrastructure (cabling, backbone) | Provider | Provider | Provider |
| Network security config (firewall rules, security groups) | You | Shared | Provider |
| Hypervisor / virtualisation | Provider | Provider | Provider |
| Operating system (patching) | You | Provider | Provider |
| Application | You | You | Provider |
| Identity & access | You | You | You |
| Data (classification, sharing, backup) | You | You | You |
Note the two network rows: the provider owns the physical network, but in IaaS you configure the network security controls (security groups, firewall rules, VPC design), and misconfiguring them is one of the most common cloud breach causes (see §5).
Notice the pattern: identity and data are always yours. No matter how "managed" the service, nobody but you decides who can log in and what data you upload. Exam questions love this table; so do interviewers.
"We moved to the cloud, so security is the provider's problem now." This sentence has preceded a remarkable number of breaches. The provider's half of the deal is generally kept; it's the customer's half that fails.
5. How the cloud actually gets breached
The real-world cloud breach causes are consistently unglamorous:
- Misconfiguration, the number one cause. The classic is a public storage bucket: cloud storage (AWS S3, Azure Blob) accidentally set so anyone on the internet can read it. Entire customer databases have leaked this way, no "hacking" required, just a browser.
- Leaked credentials and keys: API keys accidentally committed to public GitHub repositories, passwords reused from breached sites, access tokens stolen by malware. Attackers run automated scanners for exposed keys constantly; a leaked key can be exploited within minutes.
- Over-privileged identities: accounts and service identities granted far more access than they need, so one compromised login unlocks everything. This is the least privilege principle from M1 and M6 being ignored at scale.
What's mostly missing from that list: exotic zero-day exploits against the providers themselves. Those are rare. The defender's takeaway is encouraging: most cloud security is careful configuration and identity hygiene, which is exactly the kind of work an entry-level analyst can learn and do.
6. Cloud IAM: the new perimeter
On-premises, the "perimeter" was the office network: firewall at the edge, trusted inside. In the cloud there is no inside. Your admin console is on the public internet, reachable from anywhere, protected only by identity.
That's why cloud security leans so hard on the M6 toolkit:
- MFA everywhere, especially on admin accounts, the single highest-value control.
- Least privilege roles: grant narrow, specific permissions, not broad admin.
- Conditional access: block or challenge sign-ins from unexpected countries or devices.
- Short-lived credentials over permanent keys, so a stolen credential expires fast.
In cloud, identity is the perimeter. If you enjoyed M6, cloud security will feel like home.
7. Cloud logging and monitoring: where SOC work is heading
Every action in a cloud platform (every login, every API call, every setting change) can be logged:
- AWS CloudTrail records API activity across an AWS account: who did what, when, from where.
- Azure Monitor (with Entra ID sign-in and audit logs) does the equivalent for Azure and Microsoft 365.
- Google Cloud has its equivalent audit logging.
These logs feed the SIEM you met in M8, and they're why SOC analysts increasingly triage cloud alerts: impossible-travel sign-ins, a storage bucket flipped to public, an unusual burst of API calls from a new key. Same triage discipline as M8, different, and richer, log source. "Can you read cloud logs?" is fast becoming a standard L1 interview question.
8. Cloud certs for career changers: an honest guide
You do not need a cloud cert to get your first job, Security+ plus a portfolio remains the core plan. But an entry cloud cert is a cheap, genuine differentiator, and the study is free even where the exam isn't:
- Microsoft SC-900 (Security, Compliance & Identity Fundamentals): the best fit for this course: it's security-flavoured and maps to the Microsoft-heavy Australian market. Free official learning paths on Microsoft Learn.
- Microsoft AZ-900 (Azure Fundamentals): the general Azure entry cert; also free to study on Microsoft Learn.
- AWS Certified Cloud Practitioner: AWS's entry cert; free digital training via AWS Skill Builder (free tier, some content is paid; the fundamentals aren't). General training info at aws.amazon.com/training.
- Google Cloud Skills Boost (now part of Google Skills), Google's learning platform, with free content; relevant if you're targeting a Google Cloud shop.
Be honest with your budget: the exams cost money (check current pricing with each vendor, it changes). A sensible sequence for most learners here: finish this course → Security+ → then SC-900 if you want a cloud tick on the resume. Don't collect certs instead of building the portfolio (M12).
🧪 Exercise: map the shared responsibility model to your own life
No account, no cost, just thinking clearly. You already use cloud services; now analyse them like a professional.
Steps:
- Pick three services you personally use, for example: Gmail (SaaS), a web/VPS host if you have one (IaaS-ish), and OneDrive (SaaS). Any three real services work.
- For each, build a six-row table and mark each layer Provider, Me, or Shared:
- Physical security · Network · Operating system · Application · Identity · Data
- For every row you marked Me, write one sentence on what you actually do about it today (e.g. "Identity: I have MFA on Gmail but not on my web host").
- Finish with the takeaway question: which of your "Me" rows is weakest right now? Fix at least one this week (turning on MFA counts).
Optional stretch (free tier, with a warning): create a free-tier Azure or AWS account and locate the audit-log service (Azure Monitor / Entra audit logs, or CloudTrail). Just finding and reading the log of your own sign-in is a genuine portfolio note.
Free tiers are free only within limits. Before you create anything: set a spending alert/budget (both Azure and AWS support this in their billing settings), delete every resource when you finish, and never paste your card details into anything beyond the official sign-up. Forgotten cloud resources are how learners get surprise bills.
Exercise success = three completed responsibility tables, one weakness identified and fixed.
Self-check
Answer before you reveal, the attempt is what makes it stick. Your score and card ratings are saved on this device only.
Check your understanding
Commit to an answer before you check: the attempt is what makes it stick. Your first answer to each question is the one scored; practising again afterwards doesn't change it. Saved on this device only.
Interviewers and the exam assume the shared responsibility rows and the IAM vocabulary are automatic, rate yourself honestly and the cards come back on a spaced schedule.
Drill the key terms
Say your answer out loud (or in your head) before revealing. Recall is the workout. "Knew it" pushes a card's next review further out; "Review again" brings it back today.
Card 1 of 18
What is “the cloud”, stripped of the marketing?
Next module
➡️ M12: Capstone, put it all together: build the portfolio piece that gets you interviews: a technical CTF write-up track or a GRC mini-assessment track.