Overview
Domain 8 covers cloud security in one module. It covers cloud concepts and service models (IaaS, PaaS, SaaS) and deployment models (public, private, hybrid, community), the shared responsibility model, container technology and orchestration, serverless computing, common cloud attacks (misconfiguration, exposed storage, insecure APIs, account hijacking, metadata service abuse, container escape), and cloud security controls and best practices such as identity and access management, encryption and monitoring.
Like the other 5% domains, cloud is dangerous to skim because the questions go deep for the weight. The single most important idea is the shared responsibility model, which determines who secures what, and the most common cloud weakness on the exam is misconfiguration, especially exposed storage and over-permissive access. The domain connects to web and system attacks, since many cloud compromises start with the same techniques applied to cloud-hosted assets.
How it's tested
Expect questions on who is responsible under a given service model, on identifying a cloud attack such as a misconfigured bucket or metadata abuse, and on choosing the right cloud control. The shared responsibility model underlies many answers. Read the full scenario and every option carefully before deciding.
-
Who is responsible?
A service model and a security task are given, and you must decide whether the customer or the provider is responsible.
-
Identify the cloud attack
A cloud weakness or attack is described, and you must name it, such as exposed storage or container escape.
-
Right cloud control
A cloud security need is described, and you must choose the control, often IAM hardening or encryption.
A company's customer data leaks from a cloud object storage bucket that was left publicly readable. It is tempting to blame the cloud provider. But under the shared responsibility model, configuring access to stored data is the customer's responsibility in every service model. The breach is a customer misconfiguration, and the fix is to correct the access policy and audit for other exposed resources.
Domains 1
Official domains from the EC-Council outline, in outline order.
8.1 Cloud ComputingCloud models, shared responsibility, containers, serverless, attacks and controls.
- What it means
- This module covers cloud service models (IaaS, PaaS, SaaS) and deployment models (public, private, hybrid, community), the shared responsibility model, container technology such as Docker and orchestration such as Kubernetes, serverless computing, cloud-specific attacks (misconfiguration, exposed storage buckets, insecure APIs, account and credential hijacking, metadata service abuse, container escape, side-channel attacks), and cloud security controls including identity and access management, encryption, logging and monitoring, and cloud security posture management.
- What to understand
- Responsibility shifts with the service model, but the customer always owns its data, identities and access configuration. Most cloud breaches come from customer misconfiguration, especially exposed storage and over-permissive IAM. Containers share the host kernel, so a container escape threatens the host and other containers. Insecure APIs and exposed metadata services are common attack paths.
- How it shows up
- A cloud scenario is described, and you must assign responsibility, identify the attack, or choose the control.
- Common confusion
- Assuming the cloud provider secures customer data by default. The customer always remains responsible for its data and access configuration.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Shared responsibility model
Security duties split between provider and customer by service model.
- Remember
- The customer always owns its data, identities and access configuration.
- Tested as
- The central cloud concept.
- Trap
- Assuming the provider secures customer data.
-
IaaS vs. PaaS vs. SaaS responsibility
The customer secures more in IaaS and least in SaaS, but never nothing.
- Remember
- Data and access stay with the customer in all models.
- Tested as
- Responsibility questions.
- Trap
- Thinking SaaS leaves nothing for the customer.
-
Cloud misconfiguration
Insecure settings such as public storage buckets or over-permissive IAM.
- Remember
- It is the most common cause of cloud breaches.
- Tested as
- Cloud attack questions.
- Trap
- Blaming the provider for customer misconfiguration.
-
Exposed storage buckets
Object storage left publicly readable or writable.
- Remember
- A frequent and high-impact misconfiguration.
- Tested as
- Cloud attack questions.
- Trap
- Assuming storage is private by default.
-
Metadata service attack
Abusing a cloud instance's metadata endpoint to steal temporary credentials.
- Remember
- Often reached through server-side request forgery.
- Tested as
- Cloud attack questions.
- Trap
- Overlooking the SSRF-to-metadata path.
-
Container escape
Breaking out of a container to the host.
- Remember
- It threatens the host and all other containers.
- Tested as
- Container security questions.
- Trap
- Assuming containers isolate as strongly as virtual machines.
-
Containers vs. virtual machines
Containers share the host kernel; virtual machines each run their own OS.
- Remember
- Virtual machines provide stronger isolation.
- Tested as
- Container questions.
- Trap
- Treating containers as fully isolated VMs.
-
Serverless security
Functions run without managing servers, shifting some security to the provider.
- Remember
- Code, permissions and data handling remain the customer's job.
- Tested as
- Serverless questions.
- Trap
- Assuming serverless removes all security responsibility.
-
Insecure APIs
Cloud APIs lacking proper authentication, authorization or rate limiting.
- Remember
- They are a primary cloud attack surface.
- Tested as
- Cloud attack questions.
- Trap
- Overlooking API security in the cloud.
-
Cloud security posture management
Tools that continuously check cloud configurations against best practice.
- Remember
- They help find misconfigurations at scale.
- Tested as
- Cloud control questions.
- Trap
- Relying on manual review alone.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
IaaS vs. PaaS vs. SaaS customer responsibility
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| IaaS | Customer manages OS, apps and data | Most customer responsibility | Expecting the provider to patch guest OS |
| PaaS | Customer manages apps and data | Shared at the application layer | Neglecting app configuration |
| SaaS | Customer manages users, access and data | Least, but data and access remain the customer's | Assuming nothing is left to do |
Containers vs. virtual machines vs. serverless
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Containers | Isolated processes sharing the host kernel | Lightweight, weaker isolation | Assuming VM-level isolation |
| Virtual machines | Each runs its own OS on a hypervisor | Stronger isolation | Confusing with containers |
| Serverless | Functions run without managed servers | Provider handles more infrastructure | Thinking it removes all customer security duties |
Common cloud attacks
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Misconfiguration | Insecure settings such as public buckets | Most common cause of breaches | Blaming the provider |
| Metadata abuse | Stealing credentials from the metadata service | Often via SSRF | Missing the SSRF path |
| Container escape | Breaking out to the host | Threatens all containers on the host | Assuming strong container isolation |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Provider secures the data
- What candidates pick
- Blame the cloud provider for a leaked storage bucket.
- Why it looks right
- The provider runs the storage service.
- Why it's wrong
- Configuring access to stored data is the customer's responsibility in every service model.
Clue to watch for The leak comes from a misconfigured access policy.
-
SaaS needs nothing
- What candidates pick
- Assume a SaaS application requires no customer security configuration.
- Why it looks right
- The provider runs the whole application.
- Why it's wrong
- The customer still manages users, access settings and data in SaaS.
Clue to watch for The issue involves user permissions or sharing settings.
-
Containers are VMs
- What candidates pick
- Run untrusted workloads in containers expecting VM-level isolation.
- Why it looks right
- Containers feel isolated.
- Why it's wrong
- Containers share the host kernel, so isolation is weaker and a container escape threatens the host.
Clue to watch for The workloads are untrusted or multi-tenant.
-
Ignore the metadata path
- What candidates pick
- Treat an SSRF on a cloud instance as low impact.
- Why it looks right
- SSRF alone can look limited.
- Why it's wrong
- On a cloud instance, SSRF can query the metadata service and steal temporary credentials, escalating to account compromise.
Clue to watch for The vulnerable server runs in a cloud environment.
-
Serverless is hands-off
- What candidates pick
- Assume serverless functions need no security attention.
- Why it looks right
- The provider manages the servers.
- Why it's wrong
- Function code, permissions and data handling remain the customer's responsibility.
Clue to watch for The scenario involves function code or over-broad permissions.
-
Skip the small domain
- What candidates pick
- Spend no study time on cloud because it is only 5%.
- Why it looks right
- Larger domains seem more important.
- Why it's wrong
- The six cloud questions go deep, and losing most of them can fail an otherwise passing exam.
Clue to watch for Not a question trap but a study-strategy warning.
Answer framework
For any Domain 8 cloud scenario, use these steps before choosing an answer.
- Identify the service model and apply the shared responsibility model to decide who owns the security task.
- Remember that the customer always owns its data, identities and access configuration, whatever the model.
- For attacks, recognize misconfiguration as the most common cause and watch for exposed storage, insecure APIs and metadata abuse.
- For containers, remember the shared kernel and the risk of container escape; for serverless, remember the customer still owns code and permissions.
- Choose controls that address the root cause, such as correcting access policies, hardening IAM and using posture management to find misconfigurations, and recall that the customer always owns its data and access.
Practice question
Want more like this? The CEH practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Do not skim this domain despite its 5% weight, because its six questions are deep. Start with the shared responsibility model, since it underlies most cloud answers. Learn how responsibility shifts across IaaS, PaaS and SaaS, and fix firmly that the customer always owns its data and access configuration.
Next, learn the common cloud attacks, with misconfiguration and exposed storage at the top, followed by insecure APIs, metadata abuse and container escape. Understand that most cloud breaches are customer misconfigurations, not provider failures.
Then cover container and serverless concepts: the shared kernel and escape risk for containers, and the customer's continuing responsibility for code and permissions in serverless. Finish with cloud controls such as IAM hardening, encryption and posture management.
If you have access to a cloud account, reviewing storage and IAM settings makes these concepts concrete. Afterwards, move to Domain 9, cryptography, the last and another deep small domain.
FAQ
How much of CEH v13 is Domain 8?
Cloud Computing is about 5% of the exam, roughly six questions, but they go deep for the weight.
Who is responsible for security in the cloud?
Both provider and customer, split by service model, but the customer always remains responsible for its data, identities and access configuration.
What is the most common cause of cloud breaches?
Customer misconfiguration, especially exposed storage buckets and over-permissive identity and access management, rather than provider failure.
Why are containers less isolated than virtual machines?
Containers share the host kernel, so a container escape can affect the host and other containers, whereas each virtual machine runs its own operating system.
What is a cloud metadata service attack?
Abusing a cloud instance's metadata endpoint, often through server-side request forgery, to steal temporary credentials and escalate access.
Does serverless remove security responsibility?
No. The provider manages the servers, but the customer remains responsible for function code, permissions and data handling.
How does Domain 8 connect to the rest of the exam?
Many cloud attacks apply web and system techniques, such as SSRF, to cloud-hosted assets, linking this domain to Domains 3 and 5.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- Certified Cloud Security Professional Same subject: Domain 4: Cloud Application Security (16%)
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
Test your Domain 8 knowledge
You have covered cloud models, shared responsibility, containers, serverless and cloud attacks. Test whether you can assign responsibility and identify cloud attacks under exam conditions.