Most people study the cloud objectives by memorizing three definitions. IaaS is infrastructure. PaaS is a platform. SaaS is software. Then they hit a scenario question about a breach in a cloud environment and the definitions do not help at all.
The exam rarely asks what SaaS means. It asks who should have caught this, or which control would have stopped it. Both of those get answered by the same thing: the responsibility matrix.
Matrix is the whole domain
Every cloud provider publishes a responsibility matrix. It is a chart of layers with an owner attached to each one. Professor Messer's version colors the customer's layers blue and the provider's yellow, which is as good a mental image as any. Hardware sits at the bottom. Identity sits at the top. Everything in between gets a side too.
Two details about the matrix matter more than the chart itself.
It changes by provider, so there is no universal law you can memorize. It can also be modified by contract. So when a question hinges on who was supposed to patch the database engine, the honest answer starts with what the agreement says.
Sounds like a cop-out, doesn't it? That is the exam's favorite move though, because it separates people who memorized a picture from people who understood the model.
Ladder
Go from on-premises to IaaS to PaaS to SaaS and watch the provider swallow more layers at each step.
On-prem, you own everything down to the concrete. In IaaS, the provider handles the hardware and the hypervisor. The operating system lands on you. In PaaS, they take the OS and the runtime and leave you the application. By SaaS, they run nearly the whole stack.
Operating system patching is the one worth burning in. Yours in on-prem and IaaS. Theirs in PaaS and SaaS. A stem that mentions an unpatched guest OS on a rented virtual machine is an IaaS question with the answer sitting right there in it.
Line that never moves
Here is the part that turns cloud questions from guesswork into arithmetic.
Account and identity management stays with the customer in every cloud model. All of them. No tier exists where you hand the provider your user accounts and stop caring.
Follow that through. A storage bucket set to public. A shared document reachable by the whole internet. An admin account with no MFA and a password from 2019. Every one of those belongs to the customer, and it does not matter which service model the stem describes. If the failure is a permission or an account or anything a human configured wrong, stop looking at the provider.
Providers lose data too. CompTIA, though, writes the cloud scenarios where somebody flipped the wrong toggle, because that is what actually happens out here.
Underneath: the hypervisor
Virtualization sits under the cloud, and it brings its own vulnerabilities.
A hypervisor's job is to manage resources across the virtual machines running on that system. Each VM carries its own guest OS. That separation is the isolation you are paying for.
VM escape is what happens when the isolation fails. An attacker gets access to one virtual machine and then finds a way to reach other VMs on the same hypervisor. Not theoretical, either. At Pwn2Own in 2017 researchers chained a JavaScript engine bug in Edge to a Windows kernel bug to a hardware simulation bug in VMware. Then they walked out of the guest.
Resource reuse is the quieter cousin. If the hypervisor has a bug that mishandles shared resources, one VM can write to a memory area and a different VM can read it. How do you end up there? Overallocate memory. Three VMs at 2 GB each on a box holding 4 GB will do it.
Containers trade isolation for efficiency
Containers fix the waste. Rather than a guest OS per workload, the applications sit on top of container software and share the host operating system. Docker is the name everyone knows.
Fewer OS copies means more density. It also means the isolation boundary got thinner. Virtualization separates workloads better while containers run leaner, and that is the trade the exam wants you to see.
Tell in a stem: shared operating system or shared kernel means container. Separate guest OS means virtual machine.
Hybrid and multi-cloud: complexity is the vulnerability
Run two providers and the risk lives in the seam between them rather than in either provider.
They do not talk to each other directly. You configure each one by hand and separately, which is how authentication settings drift apart and firewall rules quietly stop matching. Then the data has to get from one provider to the other. How? It rides the public internet, which is why transit encryption keeps turning up as the answer.
Decoder
Read the stem and ask three things in order.
Which model is this? That tells you which layers are even yours to lose.
Did a person configure something? Then it is yours, in every model.
Is the failure between things rather than inside one thing? Look at the seam. Transit. Identity federation. Config drift.
Drill it
Write the layer stack on paper. Hardware at the bottom. Then hypervisor and operating system. Then runtime and application. Data and identity on top.
Now draw the provider's line four times, once for on-prem and once each for IaaS and PaaS and SaaS. Four lines on one page, from memory.
When you can do that without hesitating, cloud questions turn into a lookup.
Then go work scenarios until the lookup is reflex. I built the practice bank at SecPlus Mastery around that idea of scenarios ahead of definitions. There is a free diagnostic at https://secplusmastery.com/diagnostic if you want to see which domains are costing you points before you plan a schedule around a guess.
Top comments (0)