High-signal CLF-C02 reference: cloud concepts and migration basics, shared responsibility + IAM/security fundamentals, AWS services by use case, and billing/pricing/support plan comparisons.
Keep this page open while drilling questions. CLF‑C02 rewards clear definitions, best-fit service choices, and pricing/support reasoning more than deep implementation details.
| Item | Value |
|---|---|
| Questions | 65 (multiple-choice + multiple-response) |
| Time | 90 minutes |
| Passing score | 700 (scaled 100–1000) |
| Cost | 100 USD |
| Domains | D1 24% • D2 30% • D3 34% • D4 12% |
Core principles you’ll see phrased in different ways:
Key definitions (frequently tested):
| Term | Meaning (exam-friendly) |
|---|---|
| High availability (HA) | System stays available during failures (often multi-AZ). |
| Fault tolerant (FT) | Continues operating with minimal/no interruption when components fail. |
| Scalability | Ability to grow capacity to meet demand (vertical or horizontal). |
| Elasticity | Automatically match capacity to demand (scale out/in). |
| RTO | Recovery Time Objective (how long downtime is acceptable). |
| RPO | Recovery Point Objective (how much data loss is acceptable). |
Simple HA mental model:
flowchart LR
U[Users] --> LB[Load Balancer]
LB --> AZ1[App in AZ1]
LB --> AZ2[App in AZ2]
AZ1 --> DB[(Managed DB Multi-AZ)]
AZ2 --> DB
| Pillar | What it’s about (CLF level) |
|---|---|
| Operational Excellence | Operate and improve: automation, runbooks, incident response, postmortems |
| Security | Protect: IAM, least privilege, encryption, logging/monitoring |
| Reliability | Recover and scale: multi-AZ, backups, DR, change management |
| Performance Efficiency | Use resources efficiently: right services, caching, scaling, measurement |
| Cost Optimization | Avoid waste: right sizing, purchase options, managed services, tagging |
| Sustainability | Reduce environmental impact: efficient architectures and resource usage |
The “6 Rs” show up a lot in wording:
| Strategy | Meaning | Typical goal |
|---|---|---|
| Rehost | Lift-and-shift | Fastest migration |
| Replatform | Minor optimization | Quick wins with limited change |
| Refactor / re-architect | Redesign for cloud-native | Best long-term benefits |
| Repurchase | Move to SaaS | Replace app with managed SaaS |
| Retire | Decommission | Reduce scope and cost |
| Retain | Keep as-is | Delay due to constraints |
AWS Cloud Adoption Framework (CAF) (high level):
| Perspective | Focus |
|---|---|
| Business | Value realization and outcomes |
| People | Skills, roles, organizational change |
| Governance | Decision-making, risk, compliance, controls |
| Platform | Architecture, infrastructure, and foundational services |
| Security | Security strategy and controls |
| Operations | Operating model, incident/change management |
Common migration services (high level):
| Concept | What to remember |
|---|---|
| CAPEX | Up-front spend (data centers, servers). |
| OPEX | Ongoing spend (pay-as-you-go cloud bills). |
| TCO | Total cost of ownership (hardware + people + operations + downtime risk). |
| Economies of scale | AWS can buy/run infrastructure cheaper at scale. |
| Right sizing | Match capacity to actual usage to reduce waste. |
Cost optimization habits (often the “best answer”):
AWS is responsible for security of the cloud (facilities, hardware, managed service infrastructure).
You are responsible for security in the cloud (data, identity, configs, and anything you deploy).
How responsibility shifts with service model:
| Model | Example services | You manage | AWS manages |
|---|---|---|---|
| IaaS | EC2, EBS, VPC | Guest OS, patching, configs, apps, data | Data centers, hardware, virtualization |
| PaaS/Managed | RDS, ECS/Fargate, DynamoDB | Data, identities, access controls, configs | OS/platform (varies), HA primitives |
| Serverless | Lambda, SQS, SNS | Code + data + permissions | Servers, OS, scaling, infra |
High-yield rule: you’re always responsible for data classification, IAM, and configuration.
Security basics that show up in CLF language:
Where to get compliance reports:
Control types (useful for matching to services):
| Control type | Goal | Examples |
|---|---|---|
| Preventive | Stop bad things | IAM/SCPs, security groups, encryption, WAF |
| Detective | Detect and alert | CloudTrail, Config, GuardDuty, Security Hub |
| Corrective | Fix automatically | Automation runbooks, backups/restore, remediation workflows |
| IAM concept | What it is | What it’s for |
|---|---|---|
| Root user | Highest-privilege account identity | Protect with MFA; don’t use day-to-day |
| User | Human identity | Prefer federation/Identity Center where possible |
| Group | Collection of users | Attach policies to groups to simplify access |
| Role | Temporary identity assumed by people/services | Preferred for apps and cross-account access |
| Policy | Permission document | Defines what actions on what resources |
| MFA | Extra login factor | Common “best practice” answer |
High-yield best practices:
| Service | Best one-liner for CLF-C02 |
|---|---|
| AWS KMS | Create/manage encryption keys (customer-managed keys). |
| AWS CloudHSM | Dedicated HSM hardware for stricter key control. |
| AWS Secrets Manager | Store and rotate secrets (DB creds, API keys). |
| AWS Certificate Manager (ACM) | Provision/manage TLS certificates. |
| AWS WAF | Web application firewall (L7 filtering). |
| AWS Shield | DDoS protection (Standard by default; Advanced adds more). |
| Amazon GuardDuty | Threat detection using logs (findings). |
| AWS Security Hub | Aggregate security findings and posture checks. |
| Amazon Inspector | Vulnerability scanning (instances/containers). |
| Amazon Macie | Discover/protect sensitive data in S3. |
| AWS CloudTrail | Records API calls and account activity (audit). |
| Amazon CloudWatch | Metrics, logs, alarms (operational visibility). |
| AWS Config | Resource configuration history and compliance rules. |
CloudTrail vs CloudWatch vs Config (very common):
| Service | Think “this answers…” |
|---|---|
| CloudTrail | “Who did what?” (API activity and audit trail) |
| CloudWatch | “How is it performing?” (metrics, logs, alarms) |
| Config | “What changed?” (resource configuration history + compliance) |
Network security basics:
Cloud computing models (high-yield framing):
| Model | You manage | AWS manages | Examples |
|---|---|---|---|
| IaaS | OS, apps, runtime, data | Hardware + virtualization | EC2 |
| PaaS/Managed | App + data (varies) | More of the platform | RDS, Fargate |
| SaaS | Mostly data and users | Application + platform | (Many third-party SaaS; some AWS managed apps) |
Cloud deployment models (conceptual):
| Model | Meaning |
|---|---|
| All-in cloud | Workloads run in the public cloud (AWS). |
| Hybrid | Mix of on-prem and cloud (for example, AWS + data center). |
| On-premises | Workloads run in your own data center. |
| Multi-cloud | Workloads span multiple cloud providers. |
How you run and operate workloads:
| Term | Meaning |
|---|---|
| Region | Geographic area with multiple AZs |
| Availability Zone (AZ) | Isolated data centers within a Region |
| Edge location | Content delivery/edge services (for example: CloudFront) |
Related concepts you might see:
flowchart TB
Users --> Edge[Edge Location]
Edge --> Region[Region]
Region --> AZ1[AZ 1]
Region --> AZ2[AZ 2]
| Service | Best for | “Exam phrasing” cue |
|---|---|---|
| EC2 | Virtual servers (IaaS) | “Need OS control” / “run a server” |
| Lambda | Event-driven code | “No servers to manage” / “run code on events” |
| ECS / EKS | Containers | “Run containers” |
| Fargate | Serverless containers | “Containers without managing servers” |
| Elastic Beanstalk | App platform (PaaS-like) | “Deploy app quickly” |
| Lightsail | Simple VPS bundles | “Simple workloads / beginner-friendly” |
| Service | Type | Best for |
|---|---|---|
| RDS | Relational | Managed MySQL/PostgreSQL/etc |
| Aurora | Relational (AWS-optimized) | High performance relational on AWS |
| DynamoDB | NoSQL | Key-value/document at massive scale |
| Redshift | Data warehouse | Analytics/BI on large datasets |
| ElastiCache | In-memory cache | Speed up reads, reduce DB load |
Rule of thumb:
| Service | Best for (CLF level) |
|---|---|
| VPC | Your isolated virtual network |
| Route 53 | DNS and domain routing |
| Elastic Load Balancing (ELB) | Distribute traffic across targets |
| CloudFront | CDN for caching and global delivery |
| Direct Connect | Dedicated private connection from on-prem to AWS |
| Site-to-Site VPN | Encrypted tunnel over the internet |
| Service | Storage type | Best for |
|---|---|---|
| S3 | Object | Buckets, backups, data lakes, static assets |
| EBS | Block | Storage for EC2 instances |
| EFS | File | Shared file system for Linux workloads |
| FSx | File | Managed Windows/Lustre/etc file systems |
| Glacier | Archive | Long-term, low-cost archival |
S3 storage class intuition (high-level):
| Class | Best for |
|---|---|
| S3 Standard | Frequent access |
| S3 Intelligent-Tiering | Unknown/changing access patterns |
| S3 Standard-IA / One Zone-IA | Infrequent access (One Zone is cheaper but less resilient) |
| S3 Glacier | Archival/long retention |
Hybrid + migration storage helpers:
| Category | Services | Best one-liner |
|---|---|---|
| AI/ML platform | SageMaker | Build/train/deploy ML models |
| AI services | Rekognition, Comprehend, Lex, Polly, Transcribe, Translate | Prebuilt AI capabilities |
| Analytics | Athena, Glue, EMR, QuickSight | Query/ETL/big data/BI |
| Streaming | Kinesis | Real-time streaming ingest/processing |
Application integration
Management & governance
Developer tools
Migration & transfer
Customer engagement
Static website (common pick):
flowchart LR
U[Users] --> R53[Route 53]
R53 --> CF[CloudFront]
CF --> S3[(S3 Static Site)]
Typical web app (conceptual):
flowchart LR
U[Users] --> R53[Route 53]
R53 --> CF[CloudFront]
CF --> LB[Load Balancer]
LB --> App[EC2 / Containers]
App --> DB[(RDS/Aurora)]
| Model | Best for | Key idea |
|---|---|---|
| On-Demand | Unpredictable usage | Pay by the second/hour with no commitment |
| Savings Plans | Predictable compute spend | Commit to usage for discount |
| Reserved Instances (RIs) | Predictable, specific resources | Commit to a specific resource for discount |
| Spot | Interruptible workloads | Use spare capacity at deep discount |
Also know:
| Tool | Best for |
|---|---|
| Billing console | Invoices, payments, account billing settings |
| Cost Explorer | Visualize and analyze spend trends |
| AWS Budgets | Alerts and guardrails for spend/usage |
| Cost and Usage Report (CUR) | Most detailed cost data export |
| Cost allocation tags | Attribute costs to teams/projects |
| Cost Categories | Group costs logically for showback/chargeback |
| Organizations (consolidated billing) | Central billing for multiple accounts |
| Trusted Advisor | Best-practice recommendations (cost/security/etc.) |
Cost language that appears in questions:
High-yield resources:
Public vs account-specific health views (common terminology):
| View | What it is |
|---|---|
| Service Health Dashboard | Public status of AWS services (global view) |
| AWS Health / Personal Health Dashboard | Account-specific events that may impact your resources |
Support plan distinctions (CLF level):
| Plan | What to remember |
|---|---|
| Basic | Included; docs/whitepapers/re:Post; Trusted Advisor core checks; AWS Health |
| Developer | Guidance + business-hours support (good for dev/test) |
| Business | 24/7 support; broader guidance; full Trusted Advisor |
| Enterprise | Proactive guidance; Technical Account Manager (TAM); best for mission-critical workloads |
Exam cue: TAM → Enterprise. 24/7 technical support → Business/Enterprise.