CLF-C02 is easier to remember when the four domains are mapped around one business decision: why use cloud, how responsibility and security work, which AWS service category solves the need, and what it costs/supports operationally. The current CLF-C02 weighting is 24% Cloud Concepts, 30% Security and Compliance, 34% Cloud Technology and Services, and 12% Billing/Pricing/Support.
Cloud value sits at the beginning of the map
Agility, elasticity, high availability, global reach, managed services and variable cost explain why organizations adopt cloud.
These benefits should be tied to business outcomes rather than treated as slogans.
Well-Architected principles shape good cloud use
Operational excellence, security, reliability, performance efficiency, cost optimization and sustainability provide a common lens for AWS workloads.
The foundational exam asks candidates to recognize the pillar or principle that matches the described concern.
Migration connects business strategy with cloud adoption
AWS Cloud Adoption Framework and migration strategies help organizations plan people, process, governance and technology change.
CLF-C02 does not require migration execution, but candidates should understand why adoption is broader than moving servers.
Shared responsibility defines the security boundary
AWS protects the cloud infrastructure while customers protect different layers depending on the service consumed. Responsibility shifts across EC2, RDS and Lambda-style services.
The shared responsibility model should sit between service choice and security obligations.
Identity and access define who can act
IAM, roles, policies, MFA, federation and Identity Center provide authentication and authorization across AWS.
Root-user protection and least privilege are baseline governance concepts for every account.
Global infrastructure defines where services live
Regions, Availability Zones and edge locations create geographic and resilience choices.
The map should distinguish a Region-level service decision from an Availability Zone-level deployment concept.
Compute, storage, database and networking form the service core
EC2/Lambda/containers provide compute options; S3 and EBS/EFS provide different storage models; RDS and DynamoDB address database needs; VPC, Route 53 and CloudFront handle networking and delivery.
Foundational questions often ask which category or service best matches a simple use case.
Management, analytics and AI extend the platform
CloudWatch, CloudTrail, Config, Organizations, Systems Manager, analytics services and AI/ML services expand operations, governance and business capability.
The goal is service recognition and purpose rather than implementation syntax.
Cost tools sit beside architecture choices
Pricing Calculator estimates before deployment, Cost Explorer analyzes spend, Budgets alerts on thresholds and Cost and Usage Reports provide detailed data.
Compute purchasing models and storage tiers connect workload behavior with economics.
Support resources complete the operating context
AWS Support, documentation, re:Post, Knowledge Center, partners and Professional Services help organizations resolve issues or build capability.
Cloud economics should sit beside business value because cost flexibility is one reason organizations move to cloud. Elastic resources can scale with demand, but cloud does not guarantee savings automatically. Rightsizing, pricing models and governance determine whether variable consumption produces economic benefit.
AWS CAF should be drawn around migration because transformation includes people and process as well as technology. A company can migrate servers successfully and still struggle if skills, governance, security ownership or operating models are not ready.
The Well-Architected Framework should be shown as a cross-cutting review lens rather than a service. Its six pillars help evaluate workloads after service choices are made. One question can describe a cost or reliability concern without naming the framework explicitly.
Security should be split into responsibility, identity, protection and governance. Shared responsibility defines who owns what; IAM controls access; KMS/WAF/Shield/GuardDuty and similar services protect workloads; Artifact/Config/CloudTrail support governance/compliance evidence.
Root-user protection belongs above IAM because the root identity has special account powers. The map should show that everyday administrative work should use scoped IAM identities rather than the root account.
Regions, Availability Zones and edge locations should connect business needs to deployment location. Region choice can reflect latency, compliance and service availability; AZs support high availability; edge infrastructure improves content delivery and user proximity.
Compute should branch into EC2, serverless and containers. This prevents candidates from treating every workload as an EC2 instance. The service model changes the customer’s operational responsibility as well as the technical execution model.
Storage should branch into object, block, file and archive. Different access patterns explain why S3, EBS, EFS and archival storage coexist. The objective map should place the data model before the service name.
Database should branch into relational, NoSQL and caching. RDS/Aurora support relational engines, DynamoDB supports serverless NoSQL patterns, and ElastiCache addresses high-speed caching. The simplest use-case clue often identifies the category.
Networking should connect VPC, Route 53, CloudFront, API Gateway, Direct Connect, VPN and PrivateLink by function: isolated networks, naming/routing, edge delivery, managed APIs, dedicated/hybrid connectivity and private service access.
Application integration should have its own branch. SNS broadcasts messages, SQS queues them, EventBridge routes events and Step Functions orchestrates workflows. Foundational candidates need the category purpose without designing complex event systems.
Management/governance should connect monitoring, audit, configuration and account management. CloudWatch answers “what is happening,” CloudTrail “who called which API,” Config “what is the resource state,” and Organizations “how are accounts governed.”
Analytics and AI/ML should sit as service categories used by businesses rather than as deep technical domains. Athena queries data, Glue integrates/prepares data, Redshift warehouses analytics, QuickSight visualizes, while AI services provide capabilities such as vision, language, document processing or model development.
Pricing models should be placed alongside workload predictability. Flexible/unpredictable use fits On-Demand; stable committed use may fit Savings Plans/Reserved options; interruptible work may fit Spot. Dedicated hosts/instances and capacity reservations solve other isolation/licensing/capacity needs.
Support resources should be split into self-service and assisted paths. Documentation, Knowledge Center and re:Post provide information; AWS Support plans provide varying levels of support; partners and Professional Services can help with adoption or implementation.
Use the map to answer business questions. “Need static global content?” CloudFront/S3. “Need managed relational database?” RDS. “Need API audit history?” CloudTrail. “Need compliance report?” Artifact. “Need cost threshold alert?” Budgets. Mapping needs to service categories is the exam skill.
Shared responsibility should also connect to cost and operations. A managed service may cost differently from self-managed infrastructure but can reduce customer responsibility for patching or platform administration. Foundational questions sometimes test this trade-off at a high level.
Migration tools should sit between adoption strategy and service categories. Migration Hub, Application Migration Service, DMS and related services support moving workloads/data, while AWS CAF helps organize the broader transformation. Tool and framework have different roles.
End-user computing and business applications belong on the broader service map as well. WorkSpaces/AppStream-style services provide managed desktop/application experiences, while Connect/SES address business communication use cases. Recognizing the category is enough for CLF-C02.
Serverless should be mapped as an operating model, not just Lambda. Fargate can run containers without managing servers, and other managed services remove infrastructure administration at different layers. This reinforces how customer responsibility shifts with service abstraction.
Cost allocation should connect Organizations, tags and billing tools conceptually. Organizations can consolidate multiple accounts, while tags and CUR/Cost Explorer help attribute usage. The exam can ask which feature helps understand spend without requiring FinOps implementation depth.
Support resources should include Well-Architected Tool and Trusted Advisor as guidance mechanisms. One helps review workloads against the Well-Architected Framework; the other provides recommendations. Both differ from opening a technical support case.
The completed map should make “service purpose” the primary memory key. If you remember that CloudTrail is API audit, Config is resource configuration history/compliance, CloudWatch is monitoring, Artifact is compliance documentation and Budgets is threshold tracking, many questions become simple classification.
Cloud Adoption Framework should connect cloud concepts with governance and people. Its purpose is to help organizations structure transformation capabilities and outcomes; it is not a compute or migration service. Keeping frameworks separate from products prevents several common foundational mistakes.
Shared responsibility should be redrawn for each service category. The more managed the service, the more infrastructure responsibilities shift to AWS, but customers still own data, identities, configuration and application choices relevant to their use. There is no service where the customer has zero security responsibility.
Billing tools should be mapped by question type: “what will this design cost?” points to Pricing Calculator; “what did we spend?” to Cost Explorer/CUR; “warn me before/when a threshold is crossed” to Budgets. This decision-based map is easier to remember than product descriptions.
Use the complete map to answer one migration case: identify cloud benefit, governance/adoption framework, target service category, shared-responsibility change, global-infrastructure need, security control, and cost/support tool. This transforms four domains into one business conversation.
The map should also include the difference between a service and a purchasing/support mechanism. EC2 is a compute service; Savings Plans and Reserved Instance options affect how qualifying compute is priced; AWS Support provides assistance; Marketplace supplies third-party offerings. Keeping these categories separate helps avoid distractors that sound AWS-related but solve a different business problem.
Another useful branch is “information versus action.” Artifact provides compliance information, Trusted Advisor provides recommendations, CloudWatch supplies monitoring data, and Systems Manager can help operate resources. Foundational questions often hinge on whether the organization needs evidence, advice, visibility, or a management capability rather than simply “an AWS service.”
Support-plan knowledge should remain proportional to the foundational exam. The important map is who provides help and through which channel: self-service documentation and re:Post, AWS Support, AWS partners, or Professional Services. Detailed operational entitlements matter less than recognizing the correct class of assistance for the scenario.
For final review, draw a use case from business goal → cloud benefit → responsibility/security → service category → cost/support. That is the current Cloud Practitioner foundation in one map.