AWS Certified Cloud Practitioner common mistakes
AWS CRI · Understand the traps and how to avoid them.
Treating the AWS Cloud Practitioner exam as a hands-on engineering test and memorizing console click-paths and CLI syntax instead of service purpose and value propositions.
Candidates coming from a technical background assume the exam rewards configuration depth, but CRI questions are written at a conceptual and business-value level, so deep tooling recall crowds out the definitions actually tested.
What to do instead
Rewrite your notes for each service as one sentence of purpose plus the business problem it solves, and stop at the level of 'what it is for' rather than 'how to configure it'. Practice explaining each service to a non-technical stakeholder in two sentences.
Confusing the six advantages of cloud computing with generic cloud benefits and being unable to map a scenario to a specific advantage such as 'stop guessing capacity' versus 'go global in minutes'.
The advantages are often memorized as a list of slogans without a distinguishing example attached, so similar-sounding scenarios become indistinguishable under exam pressure.
What to do instead
Attach one concrete scenario to each advantage (for example, elasticity to a seasonal traffic spike, economies of scale to lower pay-as-you-go pricing, global reach to deploying in multiple Regions). Drill by reading a scenario and naming the single advantage it illustrates.
Mixing up the shared responsibility model boundary, answering that AWS is responsible for patching the guest operating system on EC2 or that the customer is responsible for patching the underlying hypervisor.
The model is usually learned as a single slogan ('security of the cloud versus security in the cloud') without practicing where the line falls for each service type, and the line moves between IaaS, managed, and serverless offerings.
What to do instead
Build a table with columns for IaaS, managed platform, and serverless, and classify patching, network controls, encryption, and identity for each. For every practice scenario, first classify the service type, then decide the responsibility.
Choosing a broad identity solution when the scenario calls for least privilege, or selecting root-account usage for routine administrative tasks.
Candidates conflate 'secure access' with 'administrator access' and underestimate how often the exam tests scoping permissions narrowly and avoiding the root user for day-to-day work.
What to do instead
For any identity question, ask what the minimum permission set is that satisfies the stated task, and prefer scoped policies, roles, and temporary credentials over long-lived broad access. Treat root-account use as the exception that requires justification.
Assuming AWS is automatically responsible for customer data classification, encryption choices, and compliance validation of the customer's own application.
The phrase 'AWS is responsible for security' is remembered too literally, leading candidates to hand over data-level controls that always remain with the customer.
What to do instead
Memorize the invariant that data classification, encryption decisions, and application-level compliance remain with the customer regardless of service model. When a question mentions customer data, default to customer responsibility unless the option explicitly describes physical or infrastructure controls.
Selecting a compute or storage service by name familiarity rather than by matching the workload characteristic, for example picking EC2 for a sporadic event-driven function or choosing a block store for static website content.
Candidates learn services in isolation and never practice the selection decision, so under time pressure the most familiar service name wins over the best-fit service.
What to do instead
Practice a decision drill: for each scenario, write down the workload traits (duration, traffic pattern, statefulness, access pattern) before looking at the options, then eliminate services that contradict a trait. Keep a one-page comparison of compute and storage options organized by trait, not by name.
Confusing availability concepts, treating a single Availability Zone as highly available or assuming a Region is the same thing as an edge location.
The vocabulary of Regions, Availability Zones, and edge locations is learned as a glossary without spatial intuition, so questions about fault isolation and latency get answered with the wrong construct.
What to do instead
Draw the hierarchy once: edge locations for caching close to users, Availability Zones as isolated data centers within a Region, Regions as geographic separation. Then answer availability questions by asking what failure the design must survive.
Mixing up the pricing models, answering that Reserved Instances suit unpredictable short workloads or that On-Demand is the cheapest option for steady long-running usage.
The models are memorized as labels without the trade-off of commitment versus flexibility, so scenario cues like 'steady state for three years' or 'spiky and unpredictable' fail to trigger the right model.
What to do instead
Map each pricing model to a commitment profile and a workload profile, and practice classifying scenarios by those two axes before reading the answer choices. Remember that savings plans and reserved commitments trade flexibility for discount.
Treating the billing and cost tools as interchangeable, for example using cost explorer when the question asks for a budget alert or confusing the pricing calculator with the billing dashboard.
The tools have overlapping names and purposes, and candidates learn them as a list rather than as answers to distinct questions (estimate before you build, understand what you spent, get alerted, get credits).
What to do instead
Assign each tool a one-line question it answers and sort practice questions by which question is being asked. If the scenario is pre-deployment, it is an estimate; if it is about a threshold notification, it is a budget.
Guessing at the support plan tiers and their response times, or assuming business support is included by default with every account.
Support plans are a small part of the material and get skipped during review, yet questions test the distinction between plan levels and what each includes, and the default plan is easily forgotten.
What to do instead
Learn the plan tiers as an ordered ladder with the distinguishing feature at each step (who you can contact, response-time commitments, and access to technical account guidance) and note which plan is the default. Answer by matching the scenario's stated need to the lowest tier that provides it.