Step 1 — Cloud Concepts

Most people who sit the Cloud Practitioner exam have never launched a server in their life, and that’s fine — it’s the point. CLF-C02 is not asking you to build anything. It’s asking whether you can explain, in business terms, why a company would move to AWS in the first place. If you’re coming from an associate-level mindset, recalibrate now: this exam rewards someone who can talk to a finance director as easily as an engineer.

So What Is Cloud Computing, Really?

Strip away the marketing language and cloud computing is a simple trade: instead of buying, racking, and maintaining physical servers, you rent computing resources from someone else — on demand, over the internet, billed for what you actually consume.

TRADITIONAL DATA CENTER              CLOUD COMPUTING
────────────────────────             ────────────────────────
Buy servers (capex)                  Rent capacity (opex)
Guess future demand                  Scale up/down as needed
Wait weeks for hardware              Provision in minutes
Pay for idle capacity                Pay only for what's used
You maintain the building            AWS maintains the building

AWS defines three ways of consuming this rented capacity, and the exam expects you to sort examples into the right bucket without hesitating:

Model	Who manages what	Example AWS service
IaaS (Infrastructure as a Service)	You manage OS, runtime, data, app — AWS manages hardware	Amazon EC2
PaaS (Platform as a Service)	You manage app and data — AWS manages the runtime layer	AWS Elastic Beanstalk
SaaS (Software as a Service)	AWS manages everything, you just use the product	Amazon Chime, Amazon Connect

None of these models is “better” in isolation — the exam wants you to match the right one to the right business need.

Why Companies Actually Move to AWS

AWS markets six advantages of cloud computing, and CLF-C02 loves testing them as multiple-choice scenarios where a company describes a pain point and you pick the matching advantage.

Trade capital expense for variable expense — Stop sinking money into data centers before you know if you’ll need them.
Benefit from massive economies of scale — AWS buys hardware at a scale no single company can match, and passes some of that savings down through lower prices over time.
Stop guessing capacity — Launch what you need this week, adjust next week, without over-provisioning “just in case.”
Increase speed and agility — New resources appear in minutes instead of the weeks or months hardware procurement used to take.
Stop spending money running and maintaining data centers — Let AWS staff worry about power, cooling, and physical security so your team focuses on the product.
Go global in minutes — Deploy an application into a new geographic Region with a few clicks instead of building a new facility.

If a question describes “we don’t want to predict server needs two years in advance anymore,” the answer is almost always tied to advantage #3 or #4 — not a specific service.

Deployment Models: Public, Private, and Hybrid

PUBLIC CLOUD                 PRIVATE CLOUD               HYBRID CLOUD
─────────────                ──────────────               ─────────────
Fully on AWS                 On-premises only             Mix of both
Shared infrastructure        Dedicated infrastructure     Some workloads stay
Lowest operational           Full control, higher          local for latency,
overhead                     operational overhead          compliance, or legacy
                                                            system reasons

Public cloud is what most people picture when they hear “AWS” — everything runs on AWS-owned infrastructure, shared (securely and logically isolated) among customers. Private cloud keeps everything on hardware a single organization owns or leases exclusively. Hybrid cloud blends the two, and it’s extremely common in real organizations that have legacy systems they can’t move yet, or regulatory requirements tying certain data to a specific physical location.

AWS supports hybrid architectures through services like AWS Direct Connect (a dedicated network link between your data center and AWS) and AWS Outposts (AWS-managed hardware installed inside your own facility). You don’t need deep technical knowledge of either for this exam — just recognize them as the hybrid-cloud answer when a scenario mentions keeping some infrastructure on-premises.

Elasticity and Agility — The Words the Exam Keeps Repeating

Two terms show up constantly and get confused with each other:

Elasticity — the ability of infrastructure to automatically grow or shrink based on real-time demand. A retail site scaling from 10 servers to 200 during a flash sale, then back down overnight, is elasticity in action.
Agility — the speed at which an organization can get new resources into the hands of developers. Spinning up a test environment in 15 minutes instead of filing a hardware request that takes six weeks is agility.

They’re related but distinct: elasticity is about infrastructure responding to load, agility is about how fast humans can act. A question describing rapid experimentation and faster time-to-market is testing agility. A question describing automatic scaling during a traffic spike is testing elasticity.

How Pricing Actually Works

AWS pricing rests on a handful of ideas that repeat across every service:

Pay-as-you-go — You’re billed for consumption, not for a fixed subscription. Turn something off, stop paying for it.

Pay less when you reserve capacity — Commit ahead of time to a usage level and unlock a discount versus on-demand rates. This idea reappears in Step 4 when we cover Savings Plans and Reserved Instances in depth.

Pay less with volume — The more you consume, the lower your effective per-unit price tends to get on services like S3, because AWS’s economies of scale get passed along as your usage tier increases.

None of this requires memorizing a price sheet. The exam checks whether you understand the shape of AWS pricing — consumption-based, no long-term lock-in required, discounts available for those willing to commit or scale.

How CLF-C02 Differs From the Associate-Level Exams

If you’ve glanced at study material for the Solutions Architect Associate exam, don’t let it intimidate you — CLF-C02 lives in a different register entirely.

CLF-C02 (Foundational)                 SAA-C03 (Associate)
────────────────────────               ────────────────────────
"What does this service do?"           "Design an architecture using..."
Business value + basic technical       Deep technical trade-offs
No hands-on configuration tested       Assumes real console/CLI experience
Vendor-neutral cloud concepts          AWS-specific implementation detail
~90 minutes, broad but shallow         ~130 minutes, narrow but deep

You will not be asked to configure a VPC’s route table or choose between two DynamoDB indexing strategies. You will be asked whether a described scenario calls for RDS or DynamoDB conceptually, whether it needs a Reserved Instance or Spot pricing model, or which pillar of the Well-Architected Framework a design principle belongs to. Read every question as a business stakeholder would, and resist the urge to overthink it with associate-level depth it isn’t asking for.

Exam Focus: What Questions Test From This Step

Matching a business scenario to the correct value proposition (agility, elasticity, economies of scale, capex-to-opex)
Distinguishing IaaS, PaaS, and SaaS given a described service
Recognizing public, private, and hybrid deployment models and which AWS services support hybrid
Telling elasticity apart from agility when both appear as distractor answers
Understanding pay-as-you-go as the default AWS pricing posture before any discount is applied
Knowing that CLF-C02 tests conceptual understanding, not hands-on configuration