AWS Certified Cloud Practitioner common mistakes
AWS CRWT · Understand the traps and how to avoid them.
Treating the AWS Cloud Adoption Framework as a migration checklist and picking an answer that describes moving servers, rather than recognizing it as guidance for organizational change management and capability building.
The name 'adoption framework' sounds like a migration plan, and many candidates have memorized migration steps from other contexts. The framework's actual role - structuring people and process change across six perspectives - is easy to gloss over.
What to do instead
Memorize the six CAF perspectives (business, people, governance, platform, security, operations) and their purpose: building organizational capabilities, not executing technical migrations. When a question asks which tool helps a company plan organizational readiness, CAF is the likely answer; when it asks how to move workloads, look for migration services instead.
Confusing the six advantages of cloud computing with general cloud benefits, and choosing a plausible-sounding benefit (such as automatic high availability) that is not one of the six.
Many true statements about cloud exist, so distractor answers sound correct. The exam expects the specific six: variable expense, economies of scale, no capacity guessing, speed and agility, no data center spending, and global reach in minutes.
What to do instead
Write the six advantages from memory and test each candidate answer against them. If an option describes a real benefit but is not one of the six (for example, 'improved security by default'), treat it as a distractor unless the question asks broadly about cloud value.
Treating the Well-Architected Framework pillars as interchangeable and selecting an answer that names the wrong pillar for a described scenario, such as calling cost optimization a performance efficiency concern.
The pillars overlap in practice - a design change can affect several at once - and candidates often match on surface keywords instead of the pillar's core question.
What to do instead
Attach one question to each pillar: operational excellence (run and improve operations), security (protect data and systems), reliability (recover from failure and meet demand), performance efficiency (use resources efficiently), cost optimization (avoid unnecessary spend), and sustainability (minimize environmental impact). Read the scenario and ask which question it is really about.
Assuming the shared responsibility model shifts everything to AWS once a service is managed, and answering that AWS secures customer data, IAM permissions, or application code in a managed service.
Managed services remove operational burden, which creates a mental shortcut that AWS also takes on data and access responsibilities. The split changes by service type, so a single mental model fails.
What to do instead
Anchor on the invariant: AWS is responsible for security OF the cloud (facilities, hardware, network, managed service infrastructure); the customer is always responsible for security IN the cloud (data, identity, access, configuration). For each service, ask what the customer still configures, and remember data classification and IAM remain customer duties even in fully managed offerings.
Confusing IAM users, groups, roles, and policies, and choosing a role where a group policy is needed, or granting long-term access keys where temporary credentials through a role are correct.
The terms are related and often appear together in scenarios, and candidates memorize definitions without the decision rule about when each is appropriate.
What to do instead
Learn the decision rule: users are identities for people or applications; groups collect users to attach policies; roles are assumed for temporary credentials and are the right answer for cross-account access, AWS service permissions, and federation. Policies are documents attached to any of these. When a scenario involves temporary access or service-to-service access, choose a role.
Selecting a compliance or governance tool for the wrong purpose, such as using AWS Artifact to audit resource configuration or AWS Config to download compliance reports.
Artifact, Config, CloudTrail, and Trusted Advisor all sound like 'audit and compliance' tools, and candidates match on the word compliance rather than the tool's function.
What to do instead
Separate the functions: Artifact provides on-demand access to AWS compliance reports and agreements; Config tracks resource configuration and changes against rules; CloudTrail records API activity; Trusted Advisor offers best-practice checks. Match the question's object - reports, resource state, API calls, or recommendations - to the tool.
Choosing compute services by familiarity rather than by workload characteristics, for example picking Amazon EC2 for a short event-driven function or AWS Lambda for a long-running stateful application.
EC2 is the most familiar service, so it becomes a default. Candidates often skip the qualifiers in the question (duration, traffic pattern, statefulness) that determine the right compute model.
What to do instead
Extract the workload traits before answering: run duration, need for a server or OS control, traffic predictability, and state. Match short-lived event-driven code to Lambda, containers to ECS or EKS, full server control to EC2, and simple web apps to Elastic Beanstalk. Eliminate options that violate a stated trait.
Mixing up storage classes and services, such as using Amazon EFS for block storage on a Windows instance or Amazon S3 for a shared file system across many Linux instances.
S3, EBS, EFS, and FSx are all storage, and the distinctions rest on access pattern and protocol rather than capacity, which scenarios often emphasize.
What to do instead
Classify by access model: S3 is object storage accessed over HTTP APIs; EBS is block storage attached to a single instance in one Availability Zone; EFS is shared NFS file storage for Linux; FSx provides managed file systems for specific protocols and platforms. Identify the access pattern in the question first, then the service.
Confusing Availability Zones with Regions when designing for resilience, and proposing a multi-Region design when the requirement is only to survive a single data center failure.
Both are fault-isolation concepts, and marketing language about global infrastructure blurs them. Candidates over-build or under-build relative to the stated requirement.
What to do instead
Fix the hierarchy: a Region contains multiple isolated Availability Zones; an AZ contains one or more data centers. Surviving an AZ failure requires deploying across AZs in one Region; surviving a Region failure requires multi-Region. Read the recovery requirement and choose the smallest scope that satisfies it.
Misapplying pricing model logic, such as recommending Savings Plans for a short unpredictable workload or Reserved Instances for a spiky, temporary test environment.
Discount mechanisms sound universally beneficial, and candidates forget that each carries a commitment in exchange for savings. Spot and On-Demand are often treated as interchangeable.
What to do instead
Map commitment to predictability: On-Demand for short or unpredictable work, Spot for fault-tolerant flexible batch, Savings Plans and Reserved Instances for steady long-term usage, and dedicated options for licensing or isolation needs. Ask whether the workload is steady and long-lived before choosing a discount instrument.