Cloud Security Fundamentals

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: The cloud did not just move servers somewhere else — it changed the fundamental rules of how systems are built, accessed, and secured. Concepts from earlier in the curriculum still apply, but they apply differently. The single most important shift: in the cloud, identity — not the network perimeter — becomes the primary security boundary. Understanding what the cloud changes, and what it does not, is the foundation of this entire track.

Part 1: The Problem

For most of computing’s history, organizations ran their own servers, in their own buildings or data centers — the world your On-Prem module describes. Security had a comfortable mental model: a perimeter. Inside the network was “trusted,” outside was “untrusted,” and a firewall (0.4) guarded the boundary.

The cloud broke that model. Organizations now run their systems on infrastructure owned and operated by cloud providers — accessed over the internet, configured through software, scaled and changed constantly. There is no longer a tidy building with a wall around it.

This is not a small change. It means much of what you learned about securing infrastructure (Phase 3, Phase 4.4) still applies — but applies differently, and some old assumptions (especially “the network perimeter is the security boundary”) are simply no longer true. An organization that moves to the cloud while still thinking in on-premises terms ends up insecure. This page establishes what the cloud actually changes — the foundation for everything else in Track C.

Part 2: The Concept — What the Cloud Is

Cloud computing is using computing resources — servers, storage, databases, networking, and much more — provided as a service over the internet by a cloud provider, rather than owning and running that infrastructure yourself.

The defining characteristics, and why each matters for security:

• Provider-operated infrastructure. The underlying hardware and data centers belong to the provider. This immediately raises the question of who secures what — answered in Part 3 (the shared responsibility model).
• Accessed and configured through software. Cloud resources are created, configured, and managed through software interfaces and APIs — not by physically racking a server. This is powerful, and it means misconfiguration through software becomes a central risk (5C.2).
• Elastic and dynamic. Cloud resources can be created, changed, and destroyed rapidly and at scale. Environments are not static — they change constantly, which has real security implications.
• Many services, not just servers. The cloud offers a vast array of services — storage, databases, serverless compute, managed services, and far more — each with its own configuration and its own security considerations.

You do not need to master a specific cloud provider’s full catalogue to do this track — Track C teaches the security principles that apply across cloud environments. (Deep, provider-specific expertise is a natural next step, and cloud security certifications, Phase 7.2, are provider-specific.) The principles are what transfer.

Part 3: The Concept — The Shared Responsibility Model

The single most important concept for cloud security — and the one most often misunderstood — is the shared responsibility model.

When you use the cloud, security is split between the cloud provider and you, the customer. Neither secures everything. Getting this split clear is foundational.

   THE SHARED RESPONSIBILITY MODEL

   CLOUD PROVIDER secures        →  security OF the cloud
     • the physical data centers
     • the underlying hardware
     • the core infrastructure
     • the foundational services

   YOU (the customer) secure     →  security IN the cloud
     • how you CONFIGURE your cloud resources
     • your identity & access management
     • your data
     • your applications
     • who can reach what

A useful way to remember it: the provider is responsible for the security of the cloud; you are responsible for security in the cloud.

Why this matters so much: the customer’s side is where most cloud breaches happen. Cloud providers operate the underlying infrastructure to a very high security standard — that part is rarely the problem. The breaches happen on the customer’s side: a misconfigured resource, over-broad access, an exposed data store, weak identity management (all of 5C.2). The dangerous misconception is “we are in the cloud, so the provider handles security.” The provider handles their part. Your part — configuration, identity, data, access — is entirely yours, and it is exactly where things go wrong.

The exact line between provider and customer responsibility shifts depending on which kind of cloud service you use — more managed services move more responsibility to the provider; less managed services leave more with you. But there is always a substantial customer-side responsibility. Knowing precisely where the line falls, for each service you use, is a core cloud security skill.

Part 4: The Concept — Identity Is the New Perimeter

This is the deepest conceptual shift in cloud security, and it deserves its own focus.

In the on-premises world, the primary security boundary was the network perimeter — inside the firewall was trusted, outside was not. Security was largely about the network: where things sat, what could reach what at the network level.

In the cloud, that perimeter dissolves. Cloud resources are accessed over the internet; environments are dynamic; the tidy inside/outside boundary is gone. What becomes the primary security boundary instead is identity — who (or what) is authenticated, and what they are authorized to do.

   ON-PREMISES                    CLOUD
   primary boundary:              primary boundary:
   the NETWORK PERIMETER          IDENTITY
   "is it inside the firewall?"   "who is this, and what may
                                   they do?"
   ────────────────────────────────────────────────────────
   "Identity is the new perimeter."

This is why Identity and Access Management (IAM) — the system controlling who and what can access cloud resources, and what they can do — is the centerpiece of cloud security. It connects directly back to authentication and authorization (1.4) and access control (2.7, 4.2): in the cloud, those concepts are not just one security control among many — they are the primary security boundary.

It also means least privilege (a principle since 0.2) becomes absolutely central. In the cloud, every identity — every user, and crucially every service and machine — has permissions defining what it can do. Over-broad permissions are one of the largest cloud risks (5C.2). The cloud version of least privilege: every identity, human and machine, should have the minimum permissions needed and no more.

Note that “identity” in the cloud is not only people. Services, applications, and machines all have identities and permissions too — and machine identities with excessive permissions are a major, often-overlooked risk. Securing cloud identity means securing all of it.

Part 5: The Concept — What Carries Over, and What Changes

A balanced view: the cloud changes a great deal, but it does not throw away the curriculum you have completed. Understanding what carries over and what changes prevents two opposite mistakes — thinking the cloud is “totally different so nothing applies,” and thinking it is “just someone else’s servers so nothing changes.”

What carries over (the principles still hold):

• The CIA triad, risk, the security mindset (Phase 1) — fully applicable.
• The vulnerability classes (Phase 2) — applications in the cloud have the same web vulnerabilities; injection, XSS, broken access control all still apply.
• Defense in depth, least privilege, secure design (4.3) — still the core principles, arguably more important in the cloud.
• Secure coding (4.1, 4.2) — cloud applications still need it.
• Monitoring, detection, incident response, vulnerability management (4.5–4.8) — all still apply, in cloud-adapted forms.
• Hardening (4.4) — still applies, but now largely configuration hardening of cloud resources rather than physical-server hardening.

What changes (the differences this track teaches):

• The shared responsibility model (Part 3) — a genuinely new concept; you must know your part.
• Identity over network perimeter (Part 4) — the fundamental boundary shift.
• Misconfiguration becomes the dominant risk — because everything is configured through software, getting configuration right is central (5C.2).
• Everything is software-defined and API-driven — infrastructure itself is configured through software, which opens both new risks and new opportunities (Infrastructure as Code, 5C.4).
• Dynamic, elastic environments — security must cope with environments that change constantly.
• New services, new attack surfaces — storage services, serverless, managed services each bring their own security considerations.

The honest framing: your Phases 0–4 foundation absolutely transfers — but the cloud reshapes how it is applied, adds genuinely new concepts (shared responsibility, the identity perimeter), and shifts where the risk concentrates (misconfiguration and identity). Track C is about that reshaping.

Part 6: The Concept — Why Cloud Security Is Built On, Not Bolted On

A final foundational principle, and a bridge to the rest of Track C.

Because cloud infrastructure is software-defined — created and configured through software and APIs — cloud security is most effective when it is built into how the cloud environment is defined and deployed, rather than inspected afterward. This is the same “shift left” principle from Track B (5B.1), now applied to infrastructure and delivery rather than to application code.

This is the bridge between the two halves of Track C:

• Cloud security (5C.1–5C.3) — securing cloud environments: understanding the model, fixing and preventing misconfiguration, securing the things that run in the cloud.
• DevSecOps (5C.4–5C.5) — building security into how cloud infrastructure and software are defined, built, and delivered: Infrastructure as Code security, and security woven into the delivery pipeline.

Together they say: in the cloud, security is most effective as something defined, automated, and built in — not manually applied and later inspected. This is also exactly why this track connects so directly to your On-Prem/DevOps module — DevSecOps is DevOps with security built in, and you already understand DevOps.

🔑 The deep lesson: the cloud did not just relocate infrastructure — it changed the rules. The shared responsibility model means you secure your part and the provider secures theirs, and your part — configuration, identity, data, access — is where breaches happen. The network perimeter dissolves and identity becomes the primary security boundary, making IAM and least privilege central. Your Phases 0–4 foundation transfers, but the cloud reshapes how it applies and shifts the risk toward misconfiguration and identity. And because the cloud is software-defined, security is most effective built in — the principle that carries through the rest of Track C.

📓 Key Terms

🧪 Hands-On Lab

Use a free-tier account on a major cloud provider (the major providers offer free tiers for learning). The principles transfer across providers; pick one and learn the concepts hands-on.

Task 1 — Set up a cloud learning account. Create a free-tier account on a major cloud provider. Explore the management console — see how resources are created and configured through software.

Task 2 — Study the shared responsibility model. Find your chosen provider’s official shared responsibility documentation. Read it. In Notion, write out — for a couple of different service types — exactly what the provider secures and what you secure. Make the split concrete.

Task 3 — Explore IAM. In your cloud account, find the Identity and Access Management section. Explore how identities (users, and service/machine identities) and permissions work. See how access is controlled by identity — the “new perimeter” in practice.

Task 4 — Create something with least privilege. Create a simple cloud resource and an identity that can access it. Deliberately configure that identity with the minimum permissions needed. Practice cloud least privilege (the 0.2 / 4.3 principle, in the cloud).

Task 5 — Map carryover and change. In Notion, take the Part 5 lists and, for a cloud environment you have set up, note concretely: which Phase 0–4 concepts apply unchanged, and which apply differently. Confirm the “transfers but reshaped” framing for yourself.

Task 6 — Connect to your DevOps module. Review your On-Prem/DevOps module notes. Write where cloud and DevOps concepts you already learned connect to this track — you are adding a security layer over things you already understand.

Task 7 — Write a cloud security foundation note. In Notion, create a “Cloud Security Fundamentals” page — what the cloud changes, the shared responsibility model, identity as the new perimeter, what carries over. The foundation for the rest of Track C.

⚠️ Common Mistakes

• “We’re in the cloud, so the provider handles security.” The provider handles their part. Your part — configuration, identity, data, access — is entirely yours, and it is where breaches happen. Know the shared responsibility split.
• Thinking in network-perimeter terms. In the cloud, identity, not the network perimeter, is the primary boundary. Carrying the on-premises mental model into the cloud produces insecure environments.
• Treating the cloud as “totally different, nothing applies.” Your Phases 0–4 foundation transfers — the CIA triad, vulnerability classes, defense in depth, monitoring, all still apply.
• Treating the cloud as “just someone else’s servers.” It genuinely changes the rules — shared responsibility, the identity perimeter, software-defined everything. Underestimating the change is as wrong as overestimating it.
• Ignoring machine/service identities. Identity in the cloud is not only people. Over-permissioned service and machine identities are a major, overlooked risk.
• Not applying least privilege to identity. In the cloud, least privilege on identities is central, not optional — over-broad permissions are a leading cloud risk.

✅ Recap & What’s Next

• The cloud changed the rules: infrastructure is provider-operated, software-defined, dynamic, and accessed over the internet — there is no tidy network perimeter.
• The shared responsibility model splits security between provider (“of the cloud”) and customer (“in the cloud”) — and the customer’s part is where breaches happen; identity becomes the new perimeter, making IAM and least privilege central.
• Your Phases 0–4 foundation transfers but is reshaped; risk shifts toward misconfiguration and identity; and because the cloud is software-defined, security is most effective built in — the bridge to the rest of Track C.

Next (5C.2): The shared responsibility model says the customer’s side is where breaches happen — and the specific cause is almost always misconfiguration. Page 5C.2 examines the common cloud misconfigurations: what actually goes wrong, and how to prevent it.