CLF common mistakes
CLF · Understand the traps and how to avoid them.
Choosing the shared-responsibility answer that assigns patching of the guest operating system or customer data to AWS, rather than to the customer, when the workload runs on Amazon EC2.
Candidates memorize 'AWS secures the cloud, you secure what's in the cloud' as a slogan but never map it to concrete layers, so the boundary between infrastructure (AWS) and guest OS, applications, and data (customer) blurs under exam pressure.
What to do instead
Build a one-page table splitting each layer (physical facilities, hypervisor, network, guest OS, runtime, application, identity/config, data) into AWS-side and customer-side, and note how the split shifts for managed services such as RDS, Lambda, and S3, where AWS absorbs more of the stack. Practice classifying 15 services against that table before exam day.
Treating the AWS Cloud Adoption Framework perspectives as a list of AWS services, or confusing the six perspectives with the well-architected pillars, and picking an answer that names a service when the question asks which CAF perspective addresses a business outcome.
Both frameworks have memorable six-item lists, and candidates study them in the same sitting, so the labels bleed together; the CAF names (business, people, governance, platform, security, operations) sound like service categories.
What to do instead
Anchor CAF to who it is for: business, people, and governance perspectives are business-oriented and owned by non-technical stakeholders; platform, security, and operations are technical. Anchor the Well-Architected pillars (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability) to design decisions. Write one sentence per item tying it to a stakeholder or design concern, not to a service name.
Answering a resilience question by defaulting to Multi-AZ when the requirement is regional or cross-region survivability, or defaulting to a single Availability Zone because the workload is 'not critical'.
Multi-AZ is the most rehearsed pattern, so it becomes a reflex; candidates stop reading for phrases like 'survive the loss of an entire Region' or 'RTO of minutes with a secondary Region' that change the correct answer.
What to do instead
Before selecting, underline the failure domain the scenario must survive (instance, AZ, Region) and the recovery objective. Map instance failure to horizontal scaling or auto recovery, AZ failure to Multi-AZ or multi-AZ replication, and Region failure to cross-region replication, backup and restore, or a multi-region active-active design. Reject any option whose blast radius is smaller than the stated failure domain.
Mixing up Availability Zones and Regions when reasoning about latency, data residency, and service scope, for example claiming two AZs in one Region provide geographic disaster recovery or that a global service such as IAM is Region-scoped.
The terms appear together in almost every architecture description, and candidates learn 'AZ equals data center, Region equals group of AZs' without connecting AZs to low-latency, independent-failure design and Regions to geographic and compliance boundaries.
What to do instead
Fix the mental model: an AZ is one or more discrete data centers with independent power and cooling inside a Region, connected to sibling AZs by low-latency links; a Region is a separate geographic area. Then sort services into Regional (EC2, S3 buckets, RDS), global (IAM, Route 53, CloudFront, WAF), and edge. Test yourself by asking 'what is the scope of this resource's name and data?' for each service you meet.
Selecting a compute service by familiarity rather than by workload shape, such as choosing EC2 for a short event-driven function, Lambda for a long-running stateful process, or containers when a fully managed batch or queue worker fits better.
Study material presents compute services as a menu without decision criteria, so the service the candidate used first or read about most becomes the answer for every scenario, ignoring runtime limits, statefulness, and operational overhead stated in the question.
What to do instead
Learn the disqualifiers as much as the use cases: Lambda has execution time and runtime constraints and suits event-driven, short-lived, stateless work; EC2 suits full control and persistent state; containers suit portable, packaged workloads; managed batch and queue services suit decoupled processing. For each practice scenario, list the stated constraints (duration, state, traffic pattern, operational effort) and eliminate services that violate any one of them.
Confusing storage classes and durability versus availability, for example assuming S3 Standard-IA or Glacier tiers offer the same millisecond access as S3 Standard, or treating EBS volumes as shared across instances.
The class names are descriptive but the trade-offs (retrieval time, minimum storage duration, retrieval fees, AZ scope) are buried in details candidates skim; durability and availability are also used loosely in conversation, so the eleven-nines durability figure gets misapplied to availability.
What to do instead
Make a comparison grid for S3 classes with columns for access pattern, retrieval latency, retrieval cost, minimum duration, and intended use, and memorize that S3 durability is designed for eleven nines while availability differs by class and design. Separately note scope: EBS volumes attach to one instance in one AZ (with multi-attach as a specific exception), EFS is shared file storage across AZs, and instance store is ephemeral. Quiz yourself by matching a scenario's access frequency and latency tolerance to a class.
Answering pricing questions with the wrong purchasing option, such as recommending On-Demand for a steady 24/7 workload that should use Savings Plans or Reserved Instances, or claiming Spot capacity is appropriate for a stateful production database.
Candidates learn the option names but not the commitment and interruption characteristics, and the exam phrases scenarios around cost reduction without spelling out the workload's tolerance for interruption or its duration.
What to do instead
Memorize three attributes per option: commitment length, discount depth relative to On-Demand, and interruption or flexibility risk. On-Demand has no commitment and highest cost; Savings Plans and Reserved Instances trade one- or three-year commitment for discount, with Savings Plans offering more flexibility across compute families; Spot is deeply discounted but can be reclaimed with short notice, so it suits fault-tolerant, stateless, or checkpointed work. Read the scenario for duration and interruption tolerance before choosing.
Misreading the AWS Support plan tiers, for example assuming Business support includes a designated Technical Account Manager or that Developer support includes 24/7 production-critical response.
The plan names are intuitive and the differentiators (response times by severity, TAM, concierge billing, architecture guidance) are a short list that candidates skim rather than memorize as a matrix, so adjacent tiers collapse together.
What to do instead
Build a small matrix of Basic, Developer, Business, Enterprise On-Ramp, and Enterprise with columns for who to contact, response-time targets for production-down versus general guidance, and included extras such as TAM or Concierge. Pay special attention to the boundary cases: production-critical 24/7 access and a TAM are the markers that separate Business from the higher tiers. Verify current tier details against official AWS documentation before relying on them, since inclusions change.
Treating billing and cost-management tools as interchangeable, for example using AWS Cost Explorer to enforce a hard spending cap or expecting AWS Budgets to retroactively itemize which service caused last month's spike.
Budgets, Cost Explorer, and Cost and Usage Reports all display cost data, so candidates pick whichever name they remember without distinguishing forecasting and visualization from alerting and enforcement from raw line-item export.
What to do instead
Assign one primary job to each tool: Cost Explorer for visualizing, filtering, and forecasting historical and future spend; Budgets for threshold alerts and automated responses when spend or usage crosses a limit (budgets alert, they do not by themselves stop resources unless you wire an action); Cost and Usage Reports for the most granular line-item data delivered to S3 for analysis. For any cost question, first decide whether it asks to see, to be warned, or to act, then choose the tool that does that job.
Choosing a network or connectivity option without checking the stated requirement for private versus public paths, such as sending traffic over the public internet when the scenario demands private connectivity, or proposing a Site-to-Site VPN where dedicated private capacity is required.
VPC components (subnets, route tables, internet and NAT gateways, security groups, network ACLs) are numerous and candidates learn them as a vocabulary list rather than as a path from source to destination, so they cannot trace whether a given design actually keeps traffic private.
What to do instead
Practice tracing a packet: source, subnet route table, gateway or endpoint, destination, then the security group and network ACL rules that must allow it. Memorize the private-connectivity options and their trade-offs: VPC endpoints for AWS services, Site-to-Site VPN over the internet with encryption, and dedicated private connectivity for consistent private bandwidth. When a question says 'without traversing the public internet', eliminate any option whose path includes an internet gateway or public endpoint.