AWS Cloud Practitioner common mistakes
AWS Cloud Practitioner · Understand the traps and how to avoid them.
Treating similar-sounding services as interchangeable - picking EC2 with an attached EBS volume when the scenario asks for a shared file system mounted by several Linux instances, or picking an Application Load Balancer for a workload that needs extreme throughput with static IPs.
The service names are memorised as vocabulary lists rather than as distinct capability profiles, so the candidate pattern-matches on a keyword like 'storage' or 'load balancer' instead of on the requirement.
What to do instead
Build a one-line differentiator card for each confusable cluster (EBS = one instance, one AZ, block; EFS = many Linux instances, multi-AZ, file; S3 = object over HTTP; ALB = HTTP/HTTPS layer 7; NLB = TCP/UDP layer 4, static IP, extreme performance) and rehearse each question by extracting the requirement keywords before looking at the options.
Having an application on EC2 call AWS APIs by creating an IAM user, generating an access key, and hard-coding or storing the key on the instance.
Access keys are the first mechanism people learn for programmatic access, and 'give the app permissions' reads as 'make a user' unless the candidate knows instance profiles exist.
What to do instead
Anchor the rule 'workloads get roles, humans get users (and even then, federation is preferred)'. For EC2 specifically, the answer is an IAM role attached via an instance profile so credentials are temporary and auto-rotated by the instance metadata service.
Placing activities on the wrong side of the shared responsibility model - stating that AWS patches the guest operating system on EC2, configures the customer's security groups, or certifies the customer's own application as PCI DSS compliant.
The model is taught as a slogan ('AWS secures the cloud, you secure in the cloud') without a concrete split, so the boundary is guessed at exam time.
What to do instead
Memorise the split by layer: AWS owns facilities, hardware, the hypervisor, and managed-service infrastructure; the customer owns guest OS patching, security group and NACL rules, IAM configuration, data classification, and application code. For compliance, remember AWS provides the inherited controls and audit artifacts (e.g., SOC and PCI reports via AWS Artifact) while the customer remains responsible for their own workload's compliance.
Answering a durability/availability question with a multi-Region architecture when the stated requirement is only tolerance of a single Availability Zone failure, or describing multi-AZ as disaster recovery.
The terms high availability, fault tolerance, and disaster recovery blur together, and 'more redundancy' feels safer than 'right-sized redundancy' on a multiple-choice exam.
What to do instead
Separate the axes: multi-AZ within a Region handles AZ failure and is the standard HA answer; multi-Region handles Regional failure and DR, at much higher cost and complexity. Match the scope of the failure in the stem (AZ, Region, or data corruption) to the scope of the architecture in the answer, and reject options that exceed the stated requirement when cost or overhead is constrained.
Confusing the cost-management tooling - choosing Cost Explorer to send a proactive alert when spend crosses a threshold, or choosing AWS Budgets when the task is to explore historical spend by service and forecast forward.
All four cost tools sit in the same Billing console area and share overlapping-sounding names, so the candidate picks the most familiar name rather than the one matching the verb in the question (alert, explore, report, recommend).
What to do instead
Assign one verb to each tool: Budgets = alert/notify on thresholds; Cost Explorer = visualise, filter, and forecast historical cost and usage; Cost and Usage Report = the most granular line-item data exported for analysis; Trusted Advisor = best-practice checks and recommendations. Also remember Cost Allocation Tags and Cost Categories are the mechanism for splitting spend by team or project.
Recommending Spot Instances for a steady-state, always-on workload such as a production relational database, or defaulting to On-Demand for a predictable multi-year batch workload.
Spot's discount is the largest and most memorable number, so it gets selected on price alone, ignoring the two-hour interruption notice and the fact that Spot capacity can be reclaimed.
What to do instead
Filter by interruption tolerance first, then by commitment: Spot for fault-tolerant, flexible, interruptible work (batch, CI, stateless web tier); Reserved Instances or Savings Plans for steady-state and predictable usage over one or three years; On-Demand for spiky, short-lived, or unpredictable work. If the stem says 'cannot tolerate interruption' or 'must run continuously', Spot is disqualified regardless of price.
Mixing up AWS Support plan entitlements - expecting a Technical Account Manager or a 15-minute critical response on Business support, or assuming Basic support includes 24/7 phone access to Cloud Support Engineers.
The four plans differ along only a few dimensions (response times, channel access, TAM, concierge billing), and those dimensions are rarely memorised precisely.
What to do instead
Memorise the two anchors: a designated Technical Account Manager and a 15-minute response for business-critical system down are Enterprise-only; Business gives 24/7 phone, chat, and email access to Cloud Support Engineers with a one-hour response for production system down. Basic includes account and billing questions, documentation, and the health dashboard only - no technical support cases.
Answering with the technically valid option instead of the one satisfying the stated constraint, ignoring qualifiers such as 'MOST cost-effective', 'least operational overhead', 'least privilege', or 'with minimal changes to existing code'.
Under time pressure the candidate recognises that an option works and selects it, treating the qualifier as filler rather than as the scoring axis.
What to do instead
Highlight the qualifier before evaluating the options, then rank the surviving answers against it. 'Least operational overhead' usually points to a managed or serverless service (e.g., Lambda, Fargate, S3) over self-managed EC2; 'most cost-effective' usually points to Spot, Savings Plans, S3 lifecycle transitions, or right-sizing rather than simply the cheapest-sounding instance.
Treating cloud spend as a capital expense and selecting answers that involve pre-purchasing hardware to reduce long-run cost, or rejecting variable cost as a disadvantage.
On-premises intuition says buying capacity up front is cheaper over time, which contradicts the pay-as-you-go model the exam is testing.
What to do instead
State the cloud value proposition explicitly in economic terms: trade capital expense for variable expense, benefit from massive economies of scale, stop guessing capacity, increase speed and agility, and stop spending money running data centres. Options that require upfront hardware purchase, long procurement cycles, or fixed capacity provisioning are distractors.
Misplacing global versus Regional versus zonal constructs - assuming an edge location can host EC2 instances, that IAM users are created per Region, or that an Availability Zone spans multiple Regions.
The geographic hierarchy is learned implicitly from service names rather than as an explicit containment model, so each service's scope gets guessed.
What to do instead
Draw the hierarchy once: Region contains multiple isolated Availability Zones; each AZ contains one or more discrete data centres; edge locations sit outside the Region/AZ structure and cache content for CloudFront and Route 53. Then tag each service with its scope - global: IAM, Route 53, CloudFront, WAF, AWS Organizations; Regional: VPC, S3 buckets (Regional but globally named), DynamoDB tables; zonal: subnets, EC2 instances, EBS volumes.