Security Foundations: Shared Responsibility & Defence-in-Depth
Two frameworks that change how you think about cloud security. Who's responsible for what — and why one lock on the front door isn't enough.
Who’s responsible for security in the cloud?
Renting a flat vs owning a house.
When you own a house, everything is your problem — the roof, the plumbing, the locks. When you rent a flat, the landlord handles the building structure and you handle your furniture and belongings.
Cloud works the same way. Microsoft (the landlord) secures the physical data centres, the network fabric, and the host operating systems. You (the tenant) secure your data, your identities, and your access policies.
The exact split depends on which cloud model you use — and that’s what the shared responsibility model is all about.
The shared responsibility model
The key concept: as you move from on-premises to IaaS to PaaS to SaaS, more responsibility shifts to Microsoft — but you always own your data and identities.
| Feature | On-Premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Physical data centre | You | Microsoft | Microsoft | Microsoft |
| Physical network | You | Microsoft | Microsoft | Microsoft |
| Physical hosts | You | Microsoft | Microsoft | Microsoft |
| Operating system | You | You | Microsoft | Microsoft |
| Network controls | You | You | Shared | Microsoft |
| Applications | You | You | Shared | Microsoft |
| Identity & access | You | You | You | You |
| Data | You | You | You | You |
Key exam concept: Identity and data are always the customer’s responsibility, regardless of the cloud model. Even in SaaS (like Microsoft 365), you control who can access what.
Scenario: Sam discovers shared responsibility
Sam runs BrightStar Retail and just moved from an on-premises email server to Microsoft 365 (SaaS).
What Sam no longer worries about:
- Physical servers, cooling, power, backups
- Operating system patches and updates
- Email application maintenance
What Sam still owns:
- Who has access to the email (identities and passwords)
- What data employees share externally
- Compliance with retail industry regulations
Sam thought “moving to the cloud” meant Microsoft handles everything. The shared responsibility model shows that’s only half the story.
Exam tip: IaaS vs PaaS vs SaaS questions
The exam loves asking “who is responsible for X in a Y model?”
Quick pattern:
- If the question mentions virtual machines → IaaS (you patch the OS)
- If the question mentions Azure SQL Database or App Service → PaaS (Microsoft patches the OS)
- If the question mentions Microsoft 365 or Dynamics 365 → SaaS (Microsoft handles almost everything)
The trap: students often think SaaS = zero responsibility. You always own identity, access, and data.
Defence-in-depth
Defence-in-depth uses multiple layers of security so that if one layer fails, the next one catches the threat.
Think of a medieval castle: a moat, then walls, then guards, then a locked treasury. An attacker has to get past every layer — not just one.
The seven layers
| Layer | What It Protects | Example |
|---|---|---|
| Physical | Data centre buildings | Locked facilities, biometric access, CCTV |
| Identity & access | Who can sign in | MFA, Conditional Access, least privilege |
| Perimeter | Network edge | DDoS protection, firewalls |
| Network | Internal traffic | Network segmentation, NSGs, private endpoints |
| Compute | VMs and servers | Patched OS, endpoint protection, secure configs |
| Application | Apps and APIs | Secure coding, vulnerability scanning, WAF |
| Data | Your actual information | Encryption at rest and in transit, sensitivity labels |
Key exam concept: Defence-in-depth is about layers, not a single product. No single solution protects everything. The exam tests whether you understand that each layer adds independent protection.
Scenario: BrightStar applies defence-in-depth
Sam decides to protect BrightStar’s new cloud setup with multiple layers:
- Physical: Microsoft handles (Azure data centres)
- Identity: MFA for all employees, strong passwords enforced
- Perimeter: Azure Firewall blocks unauthorised traffic
- Network: Store POS systems on a separate virtual network
- Compute: All devices managed with Intune, patches applied automatically
- Application: Web store protected by a Web Application Firewall
- Data: Customer credit card data encrypted, sensitivity labels on financial files
If an attacker phishes Tina’s password (identity breach), MFA stops them. If MFA is bypassed, network segmentation limits what they can reach. If they reach the data, encryption makes it unreadable.
Where does this fit? The three security pillars
SC-900 covers three product families. Here’s a preview of where everything lives:
| Feature | What It Does | Key Products |
|---|---|---|
| Microsoft Entra | Identity & access management | Entra ID, Conditional Access, PIM |
| Microsoft Defender | Threat protection & detection | Defender for Cloud, Sentinel, Defender XDR |
| Microsoft Purview | Compliance & data governance | DLP, sensitivity labels, Compliance Manager |
🎬 Video walkthrough
🎬 Video coming soon
Shared Responsibility & Defence-in-Depth — SC-900 Module 1
Shared Responsibility & Defence-in-Depth — SC-900 Module 1
~8 minFlashcards
Knowledge Check
Sam has moved BrightStar Retail's email to Microsoft 365 (SaaS). A phishing email tricks an employee into revealing their password. Who is responsible for this security breach?
BrightStar's web store is hosted on Azure App Service (PaaS). An unpatched vulnerability in the host operating system is exploited. Who is responsible?
Which defence-in-depth layer do sensitivity labels and encryption protect?