AWS Certified Cloud Practitioner (CRWT) common mistakes
AWS CRWT · Understand the traps and how to avoid them.
Treating the shared responsibility model as a single divide ("AWS secures the cloud, the customer secures everything in it") and applying that split uniformly to EC2, S3, RDS, and Lambda.
The model shifts by service type. On EC2 the customer owns the guest OS, patching, and security groups; on RDS AWS patches the database engine while the customer owns data, access, and network controls; on S3 the customer owns bucket policy, ACLs, and object-level encryption choices. Candidates memorize the slogan rather than the per-service boundary and pick answers that assign OS patching to AWS for IaaS or assign physical security to the customer.
What to do instead
Build a three-column table (service, AWS-owned, customer-owned) for the services named in the exam objectives and rehearse the boundary cases: who patches the RDS engine, who configures S3 Block Public Access, who manages the hypervisor. When a stem asks "who is responsible," first classify the service as IaaS, managed, or serverless, then answer.
Choosing the most feature-rich or highest-tier option (multi-Region, Dedicated Hosts, full enterprise support) when the scenario states a cost constraint, a small workload, or a short-lived experiment.
Candidates equate "correct" with "most resilient" and ignore the qualifiers in the stem. The exam frequently tests cost optimization and right-sizing, where the expected answer is Spot, Savings Plans, S3 lifecycle transitions, or a smaller instance family, not the maximum-availability design.
What to do instead
Underline every constraint word in the stem (budget, intermittent, fault-tolerant, predictable, compliance) before reading the options. Map each constraint to a known lever: Spot for interruptible batch, Savings Plans for steady-state compute, lifecycle policies for cold data, Graviton or smaller families for right-sizing. Eliminate any option that violates a stated constraint even if it is technically superior.
Confusing security groups with network ACLs when answering questions about statefulness, allow/deny rules, and scope.
Both control traffic at the network layer, so the terms blur under time pressure. Security groups are stateful, allow-only, and attached to ENIs; NACLs are stateless, support explicit deny, are evaluated in numbered order, and apply at the subnet level. Candidates pick a NACL to "block a specific IP on an instance" or a security group to "deny a CIDR."
What to do instead
Memorize a two-row contrast: stateful/allow-only/instance-level versus stateless/allow-and-deny/subnet-level. For any stem mentioning explicit deny, numbered rule order, or return-traffic ephemeral ports, the answer is NACL; for instance-level filtering with automatic return traffic, it is a security group.
Mixing up IAM users, groups, roles, and policies, and selecting a long-term access key where a role or identity federation is the intended answer.
The service names are familiar but the trust model is not. Roles are assumed and issue temporary credentials; they are the answer for EC2 instances, Lambda functions, cross-account access, and federated users. Candidates default to creating an IAM user with access keys because that is the pattern they have seen in tutorials.
What to do instead
Anchor on one rule: if the principal is an AWS service, another account, or an external identity provider, the answer is a role with a trust policy, never an access key. Practice distinguishing identity-based policies (attached to users/roles) from resource-based policies (attached to S3 buckets, SQS queues, KMS keys) and from permission boundaries.
Treating Availability Zones and Regions as interchangeable, and placing a highly available two-tier design across AZs when the stem requires disaster recovery across Regions, or vice versa.
Both are geographic isolation concepts. Multi-AZ protects against a single data center failure within a Region; multi-Region protects against a Regional outage and is required for very low RTO/RPO targets. Candidates read "high availability" and jump to multi-Region, or read "disaster recovery" and design only across AZs.
What to do instead
Map the requirement to the mechanism: multi-AZ for HA within a Region, multi-Region with replication for DR, and read the RTO/RPO numbers in the stem as the deciding signal. Remember that a single AZ failure is handled by spreading subnets across AZs, while a Regional event requires cross-Region replication of data and infrastructure.
Answering storage questions by capacity alone, ignoring access pattern, durability, and retrieval cost differences among S3 storage classes, EBS volume types, EFS, and Glacier tiers.
All are "storage," so candidates default to S3 Standard or gp2 without reading the access-pattern clues. The exam distinguishes frequently accessed objects, infrequently accessed objects with millisecond retrieval, archive with hours-long retrieval, block storage for a single instance, and shared file storage across instances.
What to do instead
Before answering, extract three facts from the stem: is access shared or single-instance, is it object/block/file, and what is the retrieval-time requirement. Then apply the mapping: S3 classes for objects by access frequency and retrieval latency, EBS for single-instance block volumes, EFS for shared POSIX file access, Glacier tiers for archive with defined retrieval windows.
Miscalculating or misreading the pricing model levers: On-Demand versus Reserved versus Savings Plans versus Spot, and the difference between data transfer in, data transfer out, and inter-AZ transfer.
Candidates conflate commitment-based discounts with interruption-tolerant pricing, and assume all data transfer is billed the same. Inbound data transfer is generally free, outbound to the internet is billed, and cross-AZ traffic is billed, which changes the cost answer in architecture scenarios.
What to do instead
Learn the four compute purchase models as a decision tree: steady predictable workload to Reserved or Savings Plans, interruptible to Spot, spiky or short-lived to On-Demand. Separately memorize that inbound internet transfer is free while outbound and cross-AZ are charged, and check whether a stem's cost driver is compute hours, storage volume, or egress.
Confusing CloudTrail, CloudWatch, and AWS Config, and selecting the wrong service for "audit API activity," "monitor metrics and alarms," or "track resource configuration changes."
The three observability and governance services overlap in casual descriptions. CloudTrail records API calls and who made them; CloudWatch handles metrics, logs, and alarms; Config records resource configuration state and compliance over time. Candidates pick CloudWatch for audit trails or CloudTrail for performance alarms.
What to do instead
Use a one-line mnemonic per service: CloudTrail answers "who did what and when" for API calls, CloudWatch answers "how is it performing" for metrics and logs, Config answers "what does the resource look like and has it drifted." Match the verb in the stem (audit, monitor, assess compliance) to the service.
Treating the Well-Architected Framework pillars and the Cloud Adoption Framework as interchangeable, or failing to map a scenario to the correct pillar (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability).
Both are AWS frameworks with overlapping vocabulary. Candidates memorize pillar names but cannot assign a scenario to one, so they choose a plausible-sounding pillar rather than the one the stem describes.
What to do instead
Attach a concrete question to each pillar: are we running and improving operations (operational excellence), protecting data and access (security), recovering from failure (reliability), using resources efficiently (performance efficiency), spending wisely (cost optimization), minimizing environmental impact (sustainability). Read the stem's stated goal and select the pillar that matches it, not the one that sounds most important.
Answering billing questions from intuition about invoices instead of using the specific tools: Cost Explorer, Budgets, Cost and Usage Report, and consolidated billing across an Organizations structure.
The tools sound similar and candidates have not used them. Cost Explorer visualizes and forecasts spend, Budgets sends alerts or triggers actions against thresholds, the Cost and Usage Report provides the most granular line-item data, and consolidated billing aggregates member accounts with volume discounts. Candidates pick Budgets when asked for historical trend analysis or pick Cost Explorer when asked to alert on a threshold.
What to do instead
Map each tool to its output: visualization and forecasting (Cost Explorer), threshold alerts and automated responses (Budgets), detailed line-item exports (Cost and Usage Report), aggregated billing and shared volume discounts (consolidated billing). Match the stem's requested output, not the tool name that sounds most familiar.