ExamFinch.com My Study

Study guide

Cloud Shared Responsibility and Service Models

Practice this exam

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Cloud Shared Responsibility and Service Models

Key Takeaways Explain This Topic AI

The shared responsibility model splits security tasks between provider and customer, and the split shifts with the service model.

In IaaS the customer owns the most: guest OS, runtime, applications, data, identities, and most network controls.

In PaaS the provider owns the platform and OS, while the customer keeps data, identity, app configuration, and access.

In SaaS the customer still owns users, data, tenant settings, access policy, and monitoring of tenant activity.

Misconfiguration, weak IAM, exposed object storage, and missing logging are the most-tested cloud architecture risks on SY0-701.

Last updated: June 2026

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

  • Layer IaaS PaaS SaaS
  • Physical data center Provider Provider Provider
  • Hypervisor and hardware Provider Provider Provider
  • Guest operating system Customer Provider Provider
  • Runtime and middleware Customer Provider Provider
  • Application code Customer Customer Provider
  • Data classification and handling Customer Customer Customer
  • Identity and access configuration Customer Customer Customer
  • Tenant security settings Customer Customer Customer
  • User activity review Customer Customer Customer

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

  • Model Meaning Dominant security concern
  • Public cloud Shared provider infrastructure used by many tenants Tenant isolation, configuration, IAM
  • Private cloud Cloud platform dedicated to one organization Internal governance and platform hardening
  • Hybrid cloud Mix of on-prem and cloud Identity federation, routing, data movement
  • Multi-cloud More than one provider Policy consistency, monitoring complexity
  • Region Geographic location of resources Data residency, latency, sovereignty
  • Availability zone Isolated facility group inside a region High availability and fault isolation
  • High-Value Cloud Controls

Risk Control

Public object-storage exposure Block public access, review bucket policy, enforce encryption, enable access logs

  • Overprivileged admins Role-based access, MFA, just-in-time access, periodic access reviews
  • Lost cloud logs Centralized log export, retention policy, immutable storage where required
  • Unpatched IaaS instances Patch management, golden images, vulnerability scanning
  • Secrets in code Secrets manager, automatic rotation, CI/CD secret scanning
  • Insecure internet exposure Security groups, network ACLs, private endpoints, WAF
  • 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:

  • Target Rule
  • Web VM inbound Allow TCP 443 from 0.0.0.0/0
  • Web VM admin Allow SSH/RDP only from the VPN admin CIDR
  • Database inbound Allow the DB port only from the web/app security group
  • Database from internet Deny all internet sources
  • Outbound logs Allow to the centralized logging endpoint

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.