Cloud, MSP, SLA, Service Models, and Shared Responsibility

Cloud Moves the Hardware, Not the Accountability

A cloud provider may run the data centers, power, cooling, hardware, and core platform. The customer still owns decisions about identity, data, configuration, access, monitoring, and acceptable risk. Where the line falls depends on the service model. The CC exam loves "who is responsible?" questions — identify the model first, then apply the split.

SaaS, PaaS, and IaaS

• Software as a Service (SaaS) delivers a complete application (hosted email, collaboration, CRM, ticketing). The provider patches and runs the app; the customer manages users, roles, data, sharing, integrations, and monitoring. A SaaS provider cannot stop you from granting every user admin rights.
• Platform as a Service (PaaS) provides a managed runtime, database, or app-hosting platform. The provider handles the OS and platform; the customer owns application code, data, identity, secrets, and configuration — including whether a managed database is exposed publicly.
• Infrastructure as a Service (IaaS) provides virtual machines, networks, and storage. The provider runs the physical facility and hypervisor; the customer owns the guest OS, patching, host firewall, security groups, applications, identity, and data. More control, more responsibility.

Shared Responsibility and Hybrid Environments

Shared responsibility means both parties have duties; it is not "the cloud provider handles security." The common phrasing: the provider secures the cloud (infrastructure), the customer secures what they put in the cloud and how they configure it. The most frequent customer-side failures are predictable:

• Misconfigured storage left public
• Overly broad identity permissions (violating least privilege)
• Management ports (SSH 22, RDP 3389) exposed to the internet
• Missing or unmonitored logging

Hybrid designs connect on-premises and cloud via VPN or private links. Teams must align routing, segmentation, identity federation, logging, key management, and incident response across both sides. If a cloud identity is compromised and trust is too broad, an attacker can pivot to on-premises systems. Multi-tenancy also matters: many customers share provider infrastructure, so logical isolation and configuration discipline protect your data from neighbors.

SLA and MSP Governance

A Service Level Agreement (SLA) defines measurable commitments: uptime (e.g., 99.9 percent), support response times, maintenance windows, notification duties, and remedies if targets are missed. An SLA is not a promise of perfect availability — read what is covered, what is excluded, and what remedy applies.

A Managed Service Provider (MSP) operates services for you: firewalls, endpoints, cloud, networks, or monitoring. Outsourcing operations does not outsource accountability. You still need governance, contract and SLA review, access control over the MSP, incident-notification clauses, reporting, and periodic assessment of performance. A Managed Security Service Provider (MSSP) is the security-focused version handling SOC monitoring and response.

Worked Scenarios

Scenario 1: Sensitive files sit in a SaaS platform; the provider patches the app, but a department shares a folder with "anyone with the link." That is a customer configuration and access-governance problem — review sharing settings, apply least privilege, enable MFA, monitor external sharing, and train data owners. Scenario 2: An IaaS VM is internet-exposed with SSH open to the world and no patching. The provider runs the facility correctly, but the customer owns the guest OS and security group — restrict management to a VPN or jump host, require MFA-backed identity, patch promptly, log access, and segment workloads.

In every model, contracts, monitoring, and shared responsibility decide the outcome.

Cloud Deployment Models and Tenancy

Beyond service models, CC expects familiarity with deployment models. A public cloud is shared infrastructure operated by a provider for many customers. A private cloud is dedicated to one organization, on-premises or hosted, offering more control at higher cost. A community cloud is shared by organizations with common requirements (for example, several agencies with the same compliance regime). A hybrid cloud combines public and private, often to keep sensitive workloads private while bursting other work to public capacity.

Multi-tenancy — many customers sharing the same physical resources — is why logical isolation, encryption, and disciplined configuration matter: a neighbor's misstep should never reach your data, and your misconfiguration should never expose theirs.

Data Concerns That Cross the Boundary

Moving to the cloud raises questions the exam treats as customer responsibilities regardless of model. Data residency and sovereignty ask where data physically lives and which laws apply. Encryption should protect data at rest and in transit, and the customer often controls or owns the keys. Vendor lock-in is the risk that proprietary services make it hard to migrate later, so portability and exit clauses belong in the contract. Data ownership and return should be explicit: when the relationship ends, the customer must be able to retrieve data and confirm the provider destroys remaining copies.

None of these shift to the provider just because the workload runs in their facility.

Exam Strategy for Responsibility Questions

Work these questions in order: first identify the service model (SaaS, PaaS, or IaaS), then trace the layer named in the stem. Data and identity are almost always the customer's job in every model; the operating system and platform shift to the provider as you move from IaaS toward SaaS; physical facility, hardware, and virtualization always stay with the provider. If the stem describes a misconfiguration, exposed port, over-broad permission, or sharing mistake, the customer is responsible. If it describes failed hardware, facility cooling, or hypervisor patching, the provider is responsible.

Outsourcing to an MSP or MSSP changes who performs the work but never who is accountable — governance, SLA review, and oversight stay with the organization.