Cloud Concepts is 24% of the CLF-C02 — around 15 or 16 of your 65 questions — and it is the domain everything else stands on. It is also the one candidates most often dismiss as “the easy one”, which is a specific and avoidable mistake.
The domain is not technical. It is definitional. That sounds easier and is frequently harder, because definitional questions punish approximate knowledge in a way that scenario questions do not. When a question lists four genuine AWS cloud benefits and asks which one a scenario describes, knowing roughly what all four mean gets you nothing.
The question shape that dominates this domain
Look at the pattern in the questions below. Four options; all four are real; only one matches the definition the stem asks for. That is not accidental — it is how this domain is written, because there is no architecture to reason about here. The only lever is precision.
So the study method is different from the other domains. Elsewhere, you learn to reason. Here, you learn to say each term in one sentence and — this is the part that matters — to say what it is not.
Take the AWS cloud benefits. There are six, and they are the single most reliable source of questions in this domain:
- Trade capital expense for variable expense — how you pay. Not how fast you move.
- Benefit from massive economies of scale — AWS’s aggregated purchasing lowers unit prices. Not your own efficiency.
- Stop guessing capacity — scale to actual demand instead of forecasting it.
- Increase speed and agility — resources in minutes rather than weeks.
- Stop spending money running and maintaining data centres — focus on customers, not racks.
- Go global in minutes — deploy to Regions worldwide with low latency for users.
Every one of those will show up as a distractor for the others. The scenario tells you which is meant. “Stops buying servers upfront and pays monthly” is the capital-to-variable trade, not agility — even though it is also more agile, and even though agility is a real benefit sitting right there in the options.
The service models, and the line that separates them
IaaS, PaaS and SaaS describe how much of the stack the provider takes over. The diagram above is worth a slow look, because the exam works exactly along those layers.
IaaS hands you the building blocks: virtual machines, storage, networking. You control the operating system and everything above it. EC2 is the canonical example, and “full control over the operating system” is the phrase that gives it away.
PaaS takes the operating system and runtime off your hands so you can concentrate on deploying and running your application. Elastic Beanstalk is the AWS example.
SaaS is a finished product delivered over the internet. You are a user, not an operator — a webmail service is the everyday case.
NaaS is not part of this trio, and it appears in options for exactly that reason.
The distinction is what you still manage, not who owns the hardware. That is why a question can hand you a service you have never heard of and still be answerable: if the description says you configure the OS, it is IaaS, whatever the name.
Deployment models, and the word “hybrid”
Three models, one of which is genuinely tested:
- Cloud-native / all-in cloud — everything runs in the cloud.
- Hybrid — some workloads in your own data centre, some in the cloud, connected.
- On-premises / private cloud — everything stays in your own data centre, even if virtualised.
Hybrid is the one that appears, because it is the one real migrations actually look like. If a scenario mentions a data centre the company still runs and AWS, it is hybrid — no matter how much of the workload has moved.
Elasticity, scalability, and the half everyone drops
Scalability is the ability to grow — to handle more load by adding resources. Elasticity is the ability to grow and shrink automatically as demand moves.
The second half is the one that gets forgotten, and it is the half the exam cares about, because it is where the money is. A system that only ever scales up is not elastic; it is a system that will keep billing you for a peak that ended last Tuesday. If an option describes acquiring resources without ever mentioning releasing them, it is not describing elasticity.
The Well-Architected pillars
Six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. Learn the names and one line each. The exam gives you a scenario and asks which pillar it belongs to, and one pair does most of the damage:
Reliability asks does it recover, and can it meet demand? Performance efficiency asks is it using resources efficiently as demand and technology change? Recovery is reliability. Efficiency is performance efficiency. Scenarios about failover, backups and redundancy are reliability, every time.
How to use the questions below
Answer each one before you open the explanation. When you are wrong here, you will usually be wrong because two definitions blurred together — and the paragraph under the answer is written to pull them back apart. That is the work this domain asks for: not more knowledge, sharper edges on the knowledge you already have.
Updated for CLF-C02 (July 2026). The sample questions above are our own work
in the style of the exam — not real exam items. The exam itself is set and marked
by the certification body.