Cloud Shared Responsibility and Service Models

The Question Behind Every Cloud Item

Cloud questions on SY0-701 almost always reduce to one phrase: who is responsible? Under the shared responsibility model, the provider secures the cloud infrastructure (security of the cloud) and the customer secures what they put into it and how they configure it (security in the cloud). The exact line moves with the service model, and CompTIA expects you to know which way it slides.

Responsibility by Service Model

Exam shortcut: data, identity, access, and configuration stay with the customer in every model. The provider's slice grows as you move IaaS -> PaaS -> SaaS, but it never absorbs your data or your IAM choices. A fourth model, serverless / Function-as-a-Service, pushes even the runtime to the provider but still leaves code logic, secrets, and data to the customer.

Deployment Models and Their Concerns

High-Value Cloud Controls

Security Group Mini-Example

A cloud VM in a public subnet serves HTTPS. A database sits in a private subnet. Admins connect over a corporate VPN. A defensible security-group intent:

Never read the word "cloud" as "automatically secure." The cloud makes secure patterns available; the customer must select and configure them.

Two PBQ-Style Scenarios

Scenario 1 (IaaS): A team runs an IaaS Linux server for a public app. The provider confirms the underlying host is patched, yet a scan flags critical guest-OS vulnerabilities. Correct conclusion: the customer must patch the guest OS, because IaaS leaves OS maintenance to the customer. Provider patching of the hypervisor never touches your VM.

Scenario 2 (SaaS): A SaaS email platform suffers a mailbox compromise because the tenant never required MFA. The provider runs the service, but the customer owns tenant identity policy and monitoring. The best answer is to enforce MFA and review risky sign-ins, not to ask the provider to patch its servers.

Cloud Exam Traps

• Trap: "The provider is responsible for all security." False. Data, identity, access, and configuration remain yours.
• Trap: "SaaS means no customer security work." False. Tenant settings, users, retention, DLP, and logs are all customer-owned.
• Trap: "Encryption solves public exposure." Encryption protects confidentiality but does not stop a wide-open bucket policy from serving data to anyone allowed by that policy.
• Trap: "Multi-cloud automatically improves resilience." It can, but it adds complexity and demands consistent identity, logging, and governance across providers.

Cloud-Native Building Blocks

SY0-701 expects familiarity with the architecture pieces that compose modern cloud workloads, because each shifts the responsibility line and changes the attack surface:

• Virtualization and hypervisors isolate guest VMs; the exam-relevant risk is VM escape, where a guest breaks into the host, which is why hypervisor patching is the provider's most critical duty.
• Containers package an app with its dependencies and share the host kernel; they are lighter than VMs but offer weaker isolation, so image scanning and a hardened runtime matter.
• Microservices split an application into small services that communicate over APIs, increasing the number of internal trust boundaries and the need for mTLS and gateway policy.
• Infrastructure as Code (IaC) defines environments in version-controlled templates, making secure defaults repeatable but turning a single bad template into a fleet-wide misconfiguration.
• Serverless / Function-as-a-Service removes server management entirely; the customer still owns code logic, secrets handling, and the data the function touches.

The recurring theme: every abstraction the provider adds removes one operational burden from you but never removes your duty to secure data, identity, and configuration.