AWS Certified Cloud Practitioner Preparation

1. Apply the ability to distinguish elasticity from scalability and connect each to a business decision within the CLF-C02 scope.
2. Apply the ability to choose protection across Availability Zones and Regions from continuity objectives, and separate stateless-tier placement from data placement when latency measurements and data-residency boundaries require it within CLF-C02 scope.
3. Map an operational observation to the correct pillar and select the applicable design principle, and for sustainability distinguish AWS infrastructure responsibility from the customer responsibility for workload design, data, and use. Conduct a structured cross-pillar Well-Architected workload review to identify risks, prioritize an improvement plan, and track progress through milestones without treating the review as compliance certification or automatic remediation. Distinguish managed AI service purposes from the required input and output: structured document extraction, speech transcription, text translation, entity and sentiment analysis, text-to-speech narration, image labeling, and intent-aware dialogue management. Distinguish a ready-made contextual AWS assistant in Amazon Q Developer from the managed custom model build, train, tune, and deployment lifecycle in Amazon SageMaker AI.
4. Compare cloud, hybrid, and on-premises models, connect migration to a measurable outcome, and recognize the high-availability benefit of reducing failure impact before selecting a protection design.
5. Apply the ability to separate business, people, governance, platform, security, and operations perspectives; use a Migration Readiness Assessment to identify readiness gaps before wave planning; distinguish the Mobilize purpose of closing gaps and establishing the landing zone, operating model, tools, and skills; and move from Launch to Scale after a repeatable pilot is proven while benefits continue to be measured within CLF-C02 scope. Run a complete Assess covering portfolio inventory, dependencies, owners, and business state before the directional case and wave plan, and use cross-functional cloud enablement to build reusable patterns and skills. Use Envision to form the value hypothesis, outcomes, and opportunities, then Align to align stakeholders and identify capability gaps and an action plan; define the business outcome, owner, baseline, target, and stop criterion before selecting technology. Distinguish AWS Migration Acceleration Program (MAP) as a migration support program governed by eligibility, agreement, and tracking—not a guidance library or workload-moving service—and classify the four transformation domains: technology, process, organizational, and product, according to the change and intended outcome.
6. Select rehost, relocate, repurchase, replatform, refactor, retain, or retire from business constraints; distinguish migration discovery, progress-tracking, replication, and cutover tools; sequence waves from dependencies, business priority, and complexity; define evidence-based readiness, entry, exit, rollback, and pilot-success gates before phase transition; and recognize the supported planning and transformation scope of AWS Transform for .NET with human review plus build and test validation within CLF-C02 scope.
7. Analyze TCO and cloud economics; distinguish CapEx from OpEx and the effect of economies of scale; select purchasing models from usage stability and interruption tolerance; build a continuing Cloud Financial Management capability; relate delivery cost to business output and value timing; and periodically re-evaluate alternatives, prices, usage, and measured outcomes before selecting or renewing a financial decision. Analyze eligibility for aggregated usage and volume benefits after declared exclusions. Choose a buyer-specific AWS Marketplace private offer when negotiated pricing and legal terms, rather than general volume benefits, govern procurement.
8. Apply the ability to identify waste and correct capacity from utilization evidence rather than guesswork within the CLF-C02 scope.
9. Allocate responsibilities between AWS and the customer by managed-service level, then coordinate customer-owned guest patching with compliance evidence.
10. Apply the ability to separate identity proof from permission and apply least privilege within the CLF-C02 scope.
11. Apply the ability to protect high-impact credentials and choose multi-factor authentication within the CLF-C02 scope.
12. Apply the ability to distinguish encryption in transit and at rest and separate keys from secrets within the CLF-C02 scope. Distinguish an ordinary configuration value suitable for Parameter Store from a secret requiring dedicated protection and lifecycle. Compare independent Regional keys with related KMS multi-Region primary and replica keys when shared key material and key ID are required while policy and administration remain Regional. Distinguish the managed TLS-certificate lifecycle in AWS Certificate Manager—issuance, validation, association with an integrated endpoint, and eligible renewal—from secret storage, encryption-key management, and direct HSM control.
13. Choose CloudWatch, CloudTrail, or AWS Config from the evidence required, and apply AWS Config to deploy standardized compliance-control packs and attach approved remediation when needed. Distinguish VPC path modeling from configuration without packets from evidence of observed traffic in Flow Logs and runtime measurements. Use AWS X-Ray when an already instrumented distributed request must be traced across recorded service segments to attribute downstream latency, rather than inferring an individual path from aggregate metrics.
14. Distinguish AWS reports from the Artifact agreement lifecycle and from the customer duty to design and evidence controls.
15. Apply the ability to distinguish GuardDuty, Inspector, Macie, and Security Hub by signal type within the CLF-C02 scope. Apply narrow safe suppression only to confirmed benign findings while keeping uncertain signals active for review. Configure aggregation of Security Hub findings, insights, and control status from linked Regions into a home Region while retaining source and Regional enablement as separate prerequisites.
16. Select the appropriate estimation or forecasting tool and analyze actual and forecast cost data and attribution line items to correct alerts and reconcile allocation without inventing ownership or enforcement. Distinguish internal pro forma pricing from actual AWS invoiced charges, and control RI and Savings Plans discount sharing across billing-family accounts according to the utilization objective. Select Cost Optimization Hub to aggregate recommendations across accounts, Regions, and services, deduplicate overlap, and prioritize estimated savings before using the source service for implementation detail. Treat history-based purchase recommendations as inputs and explicitly adjust the forward commitment for known retirements; distinguish normalized FOCUS exports, approval-controlled budget actions, anomaly-contributor attribution, and first-match Cost Category rule order.
17. Diagnose hybrid-path capacity and tunnel routing from failure measurements while separating path privacy, encryption, and proven redundancy. Choose private access to a supported service through PrivateLink and an interface endpoint when public internet and NAT must be avoided, while keeping DNS, routes, and policies verifiable. Apply Transit Gateway route-table association and propagation to isolate attachments and permit only declared paths.
18. Evaluate WAF test results against a malicious-request detection threshold and a benign false-positive ceiling before enabling enforcement.
19. Analyze CloudTrail event fields to distinguish reads from writes and relate request and response fields to the call result.
20. Reconstruct a resource configuration timeline from ordered AWS Config items and their changed properties.
21. Calculate a CloudWatch alarm state from the threshold, EvaluationPeriods, DatapointsToAlarm, and actual datapoints.
22. Distinguish workflow execution semantics and queue-message acknowledgement lifecycle, and evaluate routing, integration, and compute behavior from the actual path and state. Choose a repeatable governed self-service provisioning path when controls and quotas are approved and encodable. Select EC2 bare metal only when direct physical processor or non-virtualized access is the deciding compute boundary. Select the bounded primary purpose of managed frontend hosting, persistent personal desktops, streamed desktop applications, transactional email, cloud contact-center operations, and secure bidirectional IoT device messaging while preserving each service boundary. Choose Amazon Lightsail when the deciding boundary is a simplified virtual private server with a preconfigured stack and documented bundled allowances, rather than deeper EC2 control.
23. Evaluate data, storage, and recovery services from distribution, consistency, retrieval windows, and reconciliation evidence; apply measured lifecycle behavior for transition and expiration of completed objects and asynchronous expiry deletion of DynamoDB items; separate storage performance from capacity; and choose the appropriate query capability. Apply an atomic conditional write that prevents overwrite when creating an idempotent record. Evaluate object-version immutability and retention enforcement and bounds, and distinguish an indefinite legal hold released only by an authorized action from explicitly authorized governance overrides. Choose managed operations over a manifest-defined object list with result reporting, and distinguish a continuing cached hybrid file interface from a scheduled verified managed transfer that ends after migration. Distinguish dedicated Kinesis enhanced fan-out throughput, version-matched conditional updates, resumable multipart transfer, asynchronous read offload, indexed full-text search, schema discovery, and refreshable stored warehouse results from their adjacent mechanisms.
24. Evaluate security, governance, and network boundaries from inspectable allowed and denied actions or protection and drift state.
25. Distinguish public status and support channels from account-specific AWS Health events and private account state; verify the applied account-and-Region quota, entitlement-dependent account recommendations, and the appropriate support channel, entitlement, and record; and redact sensitive account data before sharing. Choose an AWS Support level from team expertise and the need for proactive services and a designated support relationship. Automate supported quota-increase requests when new organization accounts are created, while tracking approvals and unsupported exceptions. Apply current entitlement boundaries to programmatic private Support-case retrieval, and use AWS Health organizational view with all-features prerequisites and delegated access for member-account event aggregation.
26. Choose the appropriate Route 53 record and routing policy, distinguish failover precedence and latency routing with health evaluation from geolocation and weighted routing, and understand that location is inferred from IP with a default case while weights probabilistically influence cached DNS answers and do not guarantee an HTTP-request percentage or data-residency compliance. Determine hybrid DNS direction: an inbound Resolver endpoint for on-premises queries of VPC names, and an outbound endpoint with rules for VPC queries forwarded to network DNS.
27. Choose appropriate CloudWatch logic among converting log patterns into metrics, composing alarm states, anomaly-detection bands, and a derived metric-math expression for the operating condition.
28. Distinguish CloudTrail event history from Insights analysis of unusual API activity rates.
29. Distinguish Savings Plans flexibility and constraints from EC2 Availability Zone capacity reservation based on the operating need.
30. Distinguish Route 53 multivalue routing from failover and latency policies and interpret its all-records-unhealthy boundary.

ECO tasks were compared with instruction, applications and questions, and public promises reconciled to completed material. Target reviews and repairs are retained; bank quotas and practice/credential separation are checked at set closure. Scores are neither scientific guarantees nor AWS endorsement.