Cloud questions become much easier when you separate three decisions: what makes the environment cloud computing, which service or deployment model is in use, and who controls the security task in the scenario.
The full Domain 4 guide explains the complete networking and cloud domain. This Quick Review stays focused on objective 4.3.
Fast rule: Start with the service model. The more of the technology stack the provider operates, the more the responsibility boundary shifts, but customer responsibility for identities, data, approved configuration, and appropriate use never disappears.
1. Cloud-security decision map
| Question | Think first | Strong clue |
|---|---|---|
| Is this actually cloud computing? | Five essential characteristics | On-demand, network accessible, pooled, elastic, measured |
| How much of the stack does the provider operate? | IaaS, PaaS, SaaS | Infrastructure, platform/runtime, or complete application |
| Who is the environment provisioned for? | Deployment model | One organization, shared community, broad public use, or connected mix |
| Who must fix the security issue? | Shared responsibility boundary | Which party controls that technology layer or configuration? |
| Who controls users and data? | Customer responsibility | Accounts, roles, data handling, secrets, customer settings |
2. Know the five cloud characteristics
NIST defines cloud computing with five essential characteristics.
| Characteristic | Meaning | Scenario clue |
|---|---|---|
| On-demand self-service | Customers can provision capabilities as needed without manual provider interaction for each request. | Create resources when needed |
| Broad network access | Capabilities are available over networks through standard mechanisms used by different client platforms. | Reach service through standard network access |
| Resource pooling | Provider resources serve multiple consumers and are assigned according to demand. | Shared provider resource pool |
| Rapid elasticity | Capabilities can expand or contract quickly as demand changes. | Scale up or down quickly |
| Measured service | Resource use is monitored, controlled, and reported. | Metering or usage visibility |
A hosted server is not automatically cloud simply because it lives in someone else's data center. The characteristics describe the operating model.
3. Separate IaaS, PaaS, and SaaS by provider-managed layers
| Model | Customer consumes | Customer still commonly controls |
|---|---|---|
| IaaS | Compute, storage, networking, virtualization-backed infrastructure | Guest OS, applications, identities, customer network rules, configurations, and data |
| PaaS | Provider-managed platform or runtime | Application logic, identities, data, secrets, and customer-visible configuration |
| SaaS | Provider-operated application | Users, roles, data use, tenant settings, integrations, and acceptable use |
IaaS
Infrastructure as a Service leaves substantial system responsibility with the customer. If the customer launches an unpatched virtual machine, the provider's secure physical data center does not patch the customer's guest operating system for them.
PaaS
Platform as a Service moves more runtime and platform work to the provider. The customer still needs secure application code, identity decisions, data handling, secrets management, and correct customer-controlled settings.
SaaS
Software as a Service moves still more of the stack to the provider. The customer can still create risk through weak access controls, excessive sharing, bad tenant configuration, unsafe integrations, or inappropriate data handling.
CC clue: "Managed by the provider" should make you ask which layer is managed. It should not make you assume the customer has no security work left.
4. Separate deployment model from data confidentiality
| Model | Basic idea | Do not confuse it with |
|---|---|---|
| Private cloud | Provisioned for exclusive use by one organization. | Automatically on-premises or automatically secure |
| Community cloud | Provisioned for a specific community of organizations with shared concerns. | General public availability |
| Public cloud | Provisioned for open use by a broad customer base or the general public. | Customer data being public |
| Hybrid cloud | Distinct cloud infrastructures remain separate but are connected for portability or coordinated use. | One cloud account using several services |
Public cloud describes how the service is provisioned and offered. It does not mean a customer's private records are supposed to be publicly readable.
5. Use control of the layer to find the responsibility
Cloud security is shared because provider and customer control different parts of the environment.
A useful question is:
Who can actually configure, operate, or change the thing that needs protection?
Provider responsibility commonly includes the facilities, hardware, virtualization, platform, or application layers the provider has agreed to operate.
Customer responsibility commonly includes decisions such as:
- Which users receive access
- Which data enters the service
- Which roles and permissions are assigned
- Which customer-controlled security settings are enabled
- How credentials and secrets are protected
- Which integrations are trusted
- How customer activity is monitored
- Which legal, privacy, retention, and compliance obligations apply
The exact boundary depends on the provider, product, service model, contract, and configuration. A generic IaaS/PaaS/SaaS diagram is a study aid, not a substitute for the provider's current documentation.
6. Watch for security failures the customer can create
A secure provider does not prevent every customer mistake.
Common customer-controlled failures include:
- Publicly exposing data that should be restricted
- Granting excessive permissions
- Keeping former employees active
- Leaving weak tenant settings
- Failing to enable available logging
- Storing secrets in unsafe locations
- Connecting risky third-party integrations
- Uploading data that policy does not allow in the service
- Failing to configure backups, retention, or recovery options that remain the customer's responsibility
When the provider infrastructure is healthy but one tenant exposes sensitive information, look closely at customer configuration, identity, and data-handling choices.
7. Identity, data, and monitoring remain important in every service model
Identity
Cloud services still need authentication, authorization, least privilege, access review, and deprovisioning.
Single sign-on or federation can simplify identity management, but centralized identity does not remove the need to review roles and permissions.
Data
The customer should know what data is stored, its classification, where it may be processed or retained, who can access it, how it is protected, how it is backed up or recovered, and how it will be deleted when appropriate.
Monitoring
Provider logs and customer-visible telemetry can support detection and investigation, but the customer has to collect, retain, review, or integrate the evidence needed for its own responsibilities.
Buying a cloud service does not automatically create useful monitoring.
8. Apply the same cloud responsibility model to AI workloads
The current CC outline integrates foundational Artificial Intelligence (AI) security across its domains. Many AI systems depend heavily on cloud infrastructure and hosted services.
For CC-level reasoning, treat an AI workload as another system with identities, data, network paths, configurations, logs, dependencies, and provider/customer responsibility boundaries.
If an organization sends sensitive information to a hosted AI service, the relevant questions still include data classification, authorized use, access control, retention, provider terms, and customer configuration.
AI does not create a new cloud service model. Determine the actual service model and then apply the real responsibility boundary.
9. Scenario comparisons
A company rents virtual machines and manages the guest operating systems
That is an IaaS clue. The provider operates underlying infrastructure; the customer retains substantial responsibility for guest operating systems, applications, identities, configuration, and data.
Developers deploy code to a provider-managed runtime
That points toward PaaS. The provider manages more of the platform, while the customer still owns application and data security decisions under its control.
Employees use a hosted collaboration application
That is a SaaS clue. The provider operates the application, but the customer still manages users, permissions, tenant configuration, sharing, and data use.
A SaaS tenant accidentally shares a confidential folder with everyone
The provider may be operating the service correctly. The failure can still be a customer-controlled authorization or configuration problem.
Several healthcare organizations use a cloud built for their shared regulatory concerns
That fits a community cloud clue.
Demand doubles and resources expand quickly without manual provider provisioning
That points toward rapid elasticity and on-demand self-service.
A provider patches its infrastructure, but a customer IaaS VM remains vulnerable
The scenario highlights the shared responsibility boundary. The provider can secure its layer while the customer still fails to secure the guest system it controls.
10. Common exam traps
- Calling every remotely hosted server cloud without checking the cloud characteristics.
- Assuming IaaS means the provider patches the customer's guest operating system.
- Assuming SaaS removes customer identity, data, and configuration responsibilities.
- Treating public cloud as public data.
- Treating private cloud as automatically on-premises.
- Confusing service models with deployment models.
- Assuming shared responsibility is identical across every provider and product.
- Treating provider security certification as proof that the customer's configuration is secure.
- Forgetting that the customer can create risk through accounts, permissions, secrets, integrations, and data handling.
- Treating AI workloads as exempt from ordinary cloud, identity, data, and monitoring controls.
- Choosing the provider for a problem the customer alone can configure.
- Choosing the customer for a physical-data-center control the provider owns under the service agreement.
11. Rapid review grid
| Clue | Think first |
|---|---|
| Scale quickly with demand | Rapid elasticity |
| Usage is metered | Measured service |
| Customer manages guest OS | IaaS |
| Provider manages runtime/platform | PaaS |
| Provider operates complete application | SaaS |
| One organization only | Private cloud |
| Organizations with shared concerns | Community cloud |
| Broad customer availability | Public cloud |
| Connected distinct cloud environments | Hybrid cloud |
| Who fixes the control? | Who controls that layer or setting? |