AWS Solutions Architect Professional common mistakes
AWS Solutions Architect Professional · Understand the traps and how to avoid them.
Answering 'backup and restore' or 'Multi-AZ' the moment the stem says highly available, without converting the stated RTO and RPO into a DR strategy class.
The phrases 'high availability' and 'disaster recovery' trigger a memorised answer, but the actual discriminator in the question is the pair of numeric targets plus the cost constraint.
What to do instead
On scratch paper, write the RTO and RPO before reading the options and map them to a band: hours → backup and restore; tens of minutes → pilot light; minutes → warm standby; near-zero with continuous availability → multi-site active/active. Then eliminate every option above or below the band on cost or recovery time.
Designing cross-region resilience around a single Auto Scaling group, Application Load Balancer, or ElastiCache cluster that is expected to serve both regions.
Multi-AZ habits get over-applied to geographic failure; the option reads as 'highly available' so the candidate stops checking whether the named services are regional resources.
What to do instead
Treat every regional resource as dying with its region. Duplicate the full stack per region, replicate state with the region-aware tool for the datastore (S3 Cross-Region Replication, Aurora Global Database, DynamoDB global tables, RDS cross-region read replicas), and front it with Route 53 failover or latency routing plus health checks. For each service named in an option, confirm it is not single-region-only.
Choosing a self-managed EC2-plus-custom-clustering design when the stem explicitly asks for least operational overhead or least management effort.
'More control' feels like the more sophisticated architectural answer, and candidates default to the services they personally run today rather than the ones the requirement rewards.
What to do instead
Circle the qualifier words in the stem and score options on operational burden first: managed or serverless (Aurora Serverless, Fargate, SQS, DynamoDB, Step Functions, Lambda) beats patching instances. Only pick self-managed when the stem names a constraint that managed services provably cannot meet, such as a specific kernel module or an unsupported engine version.
Ignoring the quantities in the stem - data volume, job duration, message size, request rate, retention period - and selecting a service that cannot technically satisfy them.
At the feature level all four options sound plausible, so the limit only surfaces if you deliberately check it; candidates pattern-match on keywords instead of numbers.
What to do instead
Extract every number onto scratch paper and test it against the limits you know: Lambda 15-minute invocation ceiling, SQS 256 KB message and 14-day retention, S3 single PUT 5 GB, Snowball Family for one-time bulk movement versus DataSync or Direct Connect for recurring or continuous transfer, DynamoDB item size 400 KB. Any option that violates a stated number is wrong regardless of how well it fits otherwise.
Treating a migration as a single lift-and-shift wave, with no dependency inventory and no explicit link between each application's business driver and its migration strategy.
Rehost is the default mental model, the seven strategies are memorised as vocabulary rather than used as a decision tool, and hidden dependencies (DNS, LDAP, licensing tied to MAC addresses, chatty server-to-server calls) only appear during cutover.
What to do instead
For each application in the stem, state the driver and the strategy that satisfies it: fastest data-centre exit with minimal change → rehost; unsupported OS or licensing → replatform; unsustainable run cost → repurchase; agility or scaling is the driver → refactor. Then group applications into waves by dependency, and convert chatty on-premises traffic into same-AZ private traffic or an asynchronous queue.
Proposing a big-bang cutover inside a maintenance window for a database the stem says must migrate with near-zero downtime, with no ongoing replication and no DNS plan.
Data movement is treated as a one-time copy rather than a continuous synchronisation problem, and DNS TTL behaviour at the moment of repointing is overlooked.
What to do instead
Use AWS DMS or native log-based replication (Aurora binlog, logical replication) to do a full load plus change data capture, keep source and target in sync while validating with a defined query set, lower DNS TTLs days ahead, then take a short write-freeze, confirm replication lag is zero, repoint, and keep the source warm as a rollback path.
Using a service control policy to grant access, or expecting a policy attached in the management account to restrict what a member account can do.
SCPs and IAM policies are both JSON policy documents that can contain Allow or Deny statements, and the exam deliberately mixes options that look like they both grant and restrict.
What to do instead
Recall that SCPs only define the maximum permissions available in an account and never grant anything; an identity or resource policy must also allow the action. Use SCPs as OU-level guardrails, IAM roles and permission sets inside each account for actual access, and keep the management account free of workloads.
Designing the AWS estate as one account, or a handful of ad hoc accounts, and using IAM to separate teams and environments.
It mirrors the on-premises directory model and the single-account design looks simpler in the question; blast radius, service quota contention, and billing separation are not on the candidate's checklist.
What to do instead
Use AWS Organizations with OUs per environment or business unit and a Control Tower landing zone, separate accounts for production, non-production, log archive, security tooling, and shared services, IAM Identity Center for human access, and cross-account roles for automation. Attach guardrails at the OU and centralise evidence with an organization trail to the log-archive account and a Config aggregator.
Recommending Reserved Instances or Savings Plans for a spiky, seasonal, or short-lived workload, or Spot for a workload the stem says must never be interrupted.
Cost questions get answered with 'largest discount' instead of 'best fit for the usage pattern', and interruption tolerance is treated as a footnote rather than a hard constraint.
What to do instead
Match commitment to the usage profile: steady 24/7 baseline → Compute Savings Plans or RIs; fault-tolerant batch, CI, or stateless fleets → Spot with a capacity-optimised, instance-diversified fleet; unpredictable or brief workloads → On-Demand; serverless with latency requirements → provisioned concurrency only where needed. Check any stated interruption-tolerance constraint before comparing discount depth.
Answering cost questions purely by resizing or changing instance and database pricing, while ignoring data transfer, cross-AZ chatter, NAT Gateway processing, idle EBS volumes, snapshots, and storage class choice.
Compute is the visible line item on a mental bill; transfer and storage charges stay invisible until you have actually operated an account and seen the cost explorer breakdown.
What to do instead
Run the checklist on every cost question: keep chatty tiers in a single AZ, replace NAT Gateway traffic to S3 and DynamoDB with gateway VPC endpoints, apply S3 lifecycle policies or Intelligent-Tiering, move gp2 volumes to gp3, snapshot then delete unattached volumes and idle load balancers, and choose a single NAT design where availability requirements allow. Be suspicious of any option that shrinks compute but increases cross-AZ or internet egress.