AWS Certified Cloud Practitioner (CRI series) common mistakes
AWS CRI · Understand the traps and how to avoid them.
Treating the AWS Cloud Adoption Framework (CAF) perspectives as a checklist of technical services, and picking an answer that names a product when the question asks which perspective a given activity belongs to.
Candidates memorize the six perspectives as words but never attach concrete activities to them, so under time pressure they default to the answer that mentions a familiar service.
What to do instead
Build a one-line activity anchor for each perspective (Business: ROI and business case; People: skills and org change; Governance: portfolio and budget control; Platform: architecture and provisioning; Security: identity and controls; Operations: run and monitor). Practice classifying 15 short scenario sentences into perspectives without looking at service names, then re-check any answer that names a product against the question's actual ask.
Choosing a single purchasing option such as On-Demand or Spot as the general answer for cost optimization, instead of matching the option to the workload's tolerance for interruption and commitment length.
Spot is heavily marketed as the cheapest option, so candidates select it whenever the word 'cost' appears and ignore the interruption, statelessness, and fault-tolerance conditions that must hold first.
What to do instead
Use a decision order: is the workload interruptible and stateless (Spot or Spot Fleet); is it steady-state for one or three years (Reserved Instances or Savings Plans); is it short-lived or unpredictable (On-Demand); is it a dedicated host licensing need (Dedicated Hosts). For any cost question, first write the workload's durability and runtime profile, then eliminate options that violate it before comparing prices.
Confusing the shared responsibility split at the service model boundary, for example saying the customer patches the guest OS on a managed service or that AWS secures data the customer classifies.
Candidates learn 'AWS secures the cloud, you secure what's in the cloud' as a slogan but never map it onto IaaS, managed, and serverless tiers, where the handoff line moves.
What to do instead
Draw one table with three columns (EC2, managed database or container service, serverless or storage) and two rows (AWS, customer), and fill in OS patching, network controls, encryption key management, identity, and data classification. The rule to memorize: AWS is always responsible for physical and infrastructure layers and never for customer data, IAM configuration, or client-side encryption choices, regardless of service model.
Recommending a single Availability Zone deployment or a single-Region design for a scenario that states a resilience or disaster recovery requirement.
The scenario's requirement sentence (for example, survive an AZ failure or meet a recovery objective) is buried in a long prompt, and candidates answer the basic 'make it work' version instead of the stated resilience level.
What to do instead
Before evaluating options, extract the explicit non-functional requirement and its scope: AZ-level, Region-level, or account-level. Then apply the mapping: multi-AZ for AZ fault tolerance, multi-Region with replication for Region failure, and backup and restore or pilot light for cost-constrained DR. Eliminate any option whose failure domain is narrower than the stated requirement, even if it is cheaper.
Selecting security groups and network ACLs interchangeably, or claiming a security group can explicitly deny traffic.
Both are described as firewalls in study material, so candidates miss that security groups are stateful, allow-only, and instance-level, while network ACLs are stateless, allow-and-deny, and subnet-level.
What to do instead
Memorize three contrasts: statefulness (return traffic auto-allowed in security groups, must be explicitly allowed in ACLs), rule type (allow-only versus allow and deny), and attachment level (ENI or instance versus subnet). For any question about blocking a specific malicious source IP, the answer is a network ACL deny rule or a WAF, not a security group.
Mixing up the support plan tiers and attaching the wrong response time, Trusted Advisor scope, or technical account management feature to a plan.
The plans differ along several independent axes (response time, channel, TAM, Concierge), and candidates collapse them into a single 'better or worse' ranking.
What to do instead
Build a matrix with rows for Basic, Developer, Business, Enterprise On-Ramp, and Enterprise, and columns for production workload guidance, 24x7 access, response-time targets for production-down cases, full Trusted Advisor checks, and designated technical account management. Answer support questions by locating the specific feature row first, then reading across to the plan, rather than reasoning from overall tier prestige.
Treating total cost of ownership comparisons as a straight price-per-hour comparison and ignoring data transfer, storage request, and operational labor components.
Instance hourly rates are easy to compare, while egress charges, request pricing, and staffing costs are diffuse and easy to overlook under exam time pressure.
What to do instead
For any TCO question, enumerate five cost buckets explicitly: compute, storage volume, requests and operations, data transfer in and out, and people or management overhead. Then check whether the proposed answer changes any bucket it does not mention. Managed services usually raise the direct service line but lower the labor line, which is often the intended trade-off in the scenario.
Answering availability and durability questions with the wrong guarantee, such as promising that a single storage class survives an entire Region loss or quoting a durability figure for an availability question.
Durability (probability of not losing an object) and availability (ability to read it now) are stated as similar-looking nines and get swapped.
What to do instead
Anchor each storage option to its replication scope first (single AZ, multiple AZs within a Region, or cross-Region replication), then answer the durability or availability question within that scope. If the requirement is Region-loss survival, no single-Region configuration qualifies regardless of its durability number, so the answer must include cross-Region replication or a multi-Region design.
Picking a service by its marketing category name rather than by the operational behavior the scenario demands, for example recommending a relational database for a key-value access pattern or a message queue where a pub/sub fan-out is needed.
Candidates recognize service names from study lists but do not hold a mental model of access pattern, consistency, ordering, and delivery semantics, so they pattern-match on the word 'database' or 'messaging'.
What to do instead
Before choosing, write the requirement in four slots: access pattern (key lookup, relational join, document, time series), consistency need, ordering or delivery guarantee, and scale shape. Then match: key-value to a key-value store, strict multi-row transactions to relational, at-least-once fan-out to pub/sub topics, ordered single-consumer processing to a queue. Reject any option that fails one slot even if its category name sounds right.
Confusing IAM users, groups, roles, and policies, particularly assuming a role is something assigned to a person rather than an identity assumed temporarily by a principal.
All four are presented as access-control building blocks, so candidates treat roles as another kind of user and miss the temporary-credential and trust-policy mechanics that most scenario questions hinge on.
What to do instead
State the distinction in one sentence each: users are long-term identities, groups are collections of users for policy attachment, policies are JSON documents granting or denying actions on resources, and roles are assumable identities defined by a trust policy that issue temporary credentials. For any question involving cross-account access, EC2 or Lambda accessing other services, or federation, the answer is a role with a trust relationship, not a user with access keys.