Domain 4 · Objective reference 4.3 · Chapter 14 of 19
Cloud characteristics, service models and shared responsibility
About 6 minutes · ISC2 CC outline effective 1 September 2026
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Moving to cloud changes responsibility; it does not remove it.
Explore the anchors
Customer manages guest systems and applications.
Concept matching activity
Match this task or description to its concept:
Provider manages more of the runtime.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Recognize cloud characteristics
- Use the service boundary to assign tasks
- Compare deployment and elasticity decisions
Recognize cloud characteristics
On-demand self-service lets consumers provision approved resources without a manual provider interaction for every action. Broad network access makes capabilities reachable through standard mechanisms. Resource pooling shares provider resources across consumers with appropriate isolation. Rapid elasticity expands or contracts capacity, while measured service records usage. These characteristics bring operational benefits but require controls for identity, configuration, cost and data handling.
Deployment models describe who uses and governs the environment: public, private, community and hybrid arrangements have different sharing and integration contexts. A private cloud is not automatically secure, and a public service is not automatically unsuitable. Evaluate the actual data, obligations, architecture and assurance.
Use the service boundary to assign tasks
Infrastructure services commonly leave the customer responsible for guest operating systems and applications. Platform services shift more runtime and platform maintenance to the provider. Software services deliver a managed application, but customer identities, sharing configuration and permitted data use still matter. The exact agreement and service define responsibility; a diagram is a starting point, not a substitute for it.
Review tenant access, service identities, logging, key use, backup, recovery, supplier dependencies and exit requirements. A provider’s certification does not prove the customer configured access correctly. For AI services, clarify what inputs may be retained or reused, who controls model access and how changes or unavailable service will be handled. Keep secrets and personal information out of unapproved tools.
Compare deployment and elasticity decisions
A public-cloud service is shared infrastructure made available to consumers under the provider’s service model. A private-cloud arrangement is dedicated to an organization. A community arrangement serves a defined shared community, while hybrid arrangements combine distinct environments and their integrations. The important questions remain identity, isolation, data location, operational control and recoverability.
Elasticity changes available capacity as demand changes. Scalability describes the ability to handle changed load, while metering measures usage. Automatic expansion can help availability but can also increase costs or expand an attack’s resource consumption. Apply appropriate quotas, monitoring and approval. Resource pooling makes tenant isolation and correct configuration important; pooling does not mean consumers are entitled to access one another’s data.
| Service model | Provider commonly manages | Customer still evaluates |
|---|---|---|
| Infrastructure | Underlying physical and virtualization infrastructure | Guest OS, applications, identities, data and network configuration |
| Platform | Infrastructure plus managed platform/runtime | Application code, data, identity and platform configuration |
| Software | Application and supporting platform | Tenant access, sharing, data use and retained contractual responsibilities |
Worked example
A software service maintains its underlying servers, but a tenant employee creates a public document link. Investigating the tenant’s sharing permission and audit record is necessary; server maintenance assurance does not explain the link.
Check your understanding
Who patches the guest operating system in a typical infrastructure-service arrangement, and why should you still check the contract?
Show explanation
The customer commonly manages the guest operating system. Managed options can change that division, so the actual service agreement and operating model determine the answer.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.