AWS Solutions Architect common mistakes
AWS Solutions Architect · Understand the traps and how to avoid them.
When a question says an application running on EC2, Lambda, or ECS needs to call S3, DynamoDB, or SQS, the candidate picks 'create an IAM user, generate an access key, store it in the app config / Secrets Manager' instead of an IAM role.
Access-key habits come from on-premises credential management, and the phrase 'programmatic access' in an option triggers the IAM-user answer even when the workload runs inside AWS and a role is available.
What to do instead
Before evaluating options, ask one question: 'Where does the code run?' Inside AWS compute = IAM role (instance profile / task role / execution role), no stored credentials. Outside AWS = STS AssumeRole, IAM Roles Anywhere, or federation. Static access keys are almost never the exam answer except for third-party tooling you cannot change.
The candidate uses a security group to explicitly deny traffic from a single bad IP, or uses a network ACL to control traffic between two instances in the same subnet, and then forgets to add the ephemeral-port return rule for a NACL.
The rule 'security groups are allow-only, NACLs allow and deny' is memorized as a slogan but not applied to the two real axes: scope (ENI/instance vs subnet) and statefulness (stateful vs stateless, so NACLs need both directions on ephemeral ports 1024-65535).
What to do instead
Run a two-question filter on every network question: (1) Is the control point an ENI/instance or a whole subnet? Instance-level = security group; subnet-level or 'block a specific IP range' = NACL. (2) Is it stateless? If NACL, write both inbound and outbound rules including the ephemeral port range. Also remember SGs can reference other SGs, which is how you allow instance-to-instance without CIDRs.
The stem says 'improve read performance for a read-heavy database' and the candidate picks Multi-AZ, or the stem says 'survive an Availability Zone failure with zero data loss' and the candidate picks a Read Replica.
RDS Multi-AZ and Read Replicas are both described as 'a second copy of the database', so the features collapse into one memory. The candidate pattern-matches the words 'high availability' or 'second copy' without separating synchronous standby from asynchronous readable copy.
What to do instead
Memorize a three-row table and map the stem's keyword to a row before looking at options. Multi-AZ: synchronous, standby not readable, automatic failover, purpose = availability. Read Replica: asynchronous, readable, manual promotion, purpose = read scaling. Multi-Region / cross-region replica: purpose = regional DR. Also note Aurora has its own rules (Aurora Replicas can fail over, Global Database for cross-region).
The candidate treats a service as automatically covering every failure scope, e.g. 'S3 is eleven nines durable, so no DR plan is needed' or 'Lambda is serverless, so it is multi-region', or assumes a single DynamoDB table is already global.
Durability, availability, and geographic blast radius get conflated. Marketing numbers about durability are remembered, but the region/AZ boundary of each service is not.
What to do instead
For any resilience question, first label the blast radius the stem requires (instance, AZ, region, global) and then label each candidate service's scope: S3 bucket = regional (cross-region replication is a separate feature), EBS volume = single AZ, DynamoDB table = regional (global tables for multi-region), Lambda = regional. Eliminate any option whose native scope is smaller than the requirement unless it is paired with the feature that extends it.
The candidate answers a decoupling question with SQS where fan-out to multiple consumers is required, or with SNS where durable buffering, retry, and a backlog for a slow consumer are required, or ignores the need for a dead-letter queue.
SQS and SNS are both 'messaging services', so the choice default is whatever service was studied most recently. The distinguishing properties (pull vs push, single consumer group vs many subscribers, retention, replay) are not recalled under time pressure.
What to do instead
Memorize the shape of each: SQS = queue, pull, one consumer group competing for messages, retention up to 14 days, needs a DLQ for poison messages. SNS = pub/sub push, fan-out to many subscribers at once, no retention for failed delivery unless you add a queue. EventBridge = routing and filtering by event pattern, plus SaaS sources. SQS FIFO = ordering and deduplication. If the stem says 'send the same event to five systems', the answer is fan-out, not a single queue.
The stem shows a performance bottleneck and the candidate's answer is 'move to a larger instance type', even when read replicas, ElastiCache, CloudFront, or a queue are among the options.
Scaling up is the intuitive and most familiar answer from on-premises experience, and the candidate does not spend time deciding what the bottleneck actually is (CPU, read I/O, write I/O, connection count, or client latency).
What to do instead
Classify the bottleneck before comparing options: CPU-bound = bigger instance or horizontal scaling; read-heavy database = read replicas or a cache in front; repeated identical reads / static content = CloudFront or ElastiCache; write-heavy = queue writes, partition key/sharding, or DynamoDB on-demand; long-running synchronous calls between services = decouple with SQS. Pick the option that targets the labeled bottleneck, not the one that adds raw capacity everywhere.
For a global performance or failover requirement, the candidate picks Route 53 latency-based routing for a non-HTTP TCP workload, or picks CloudFront when the requirement is static anycast IP addresses for allowlisting, or assumes CloudFront provides fixed IPs.
CloudFront, Global Accelerator, and Route 53 routing policies are all 'global and fast', so they collapse into one memory. The differentiators (HTTP(S) content caching vs TCP/UDP acceleration with anycast IPs vs DNS-level resolution) are not separated.
What to do instead
Use a decision tree: cacheable or HTTP(S) content delivered to worldwide users = CloudFront; non-HTTP(S) protocols, static anycast IPs, or fast regional failover without DNS TTL delay = Global Accelerator; multi-region routing based on latency, geography, or weights with DNS only = Route 53 policies. Record that CloudFront does not give you a fixed IP list (use a managed prefix list or Global Accelerator if IP allowlisting is required).
The candidate chooses a storage service by capacity or price rather than by access semantics, e.g. EBS for a shared directory mounted on several Linux instances, EFS for a single-instance high-IOPS database, or S3 for a low-latency POSIX filesystem.
Block, file, and object storage are all 'storage' in the candidate's mental model, and EFS sounds like a newer, better EBS. The key signals in the stem (shared, POSIX, SMB, single-AZ, random I/O, HPC scratch) are not mapped to services.
What to do instead
Anchor on access semantics: block storage attached to one instance in one AZ with high random IOPS = EBS (gp3/io2); shared POSIX NFS across Linux instances and AZs = EFS; native Windows/SMB or Active Directory integration = FSx for Windows; HPC scratch with sub-millisecond latency = FSx for Lustre; object with HTTP access and lifecycle tiering = S3; ephemeral ultra-high-IOPS scratch = instance store. Look for the words 'shared', 'POSIX', 'SMB', and 'single AZ' in the stem as direct pointers.
The candidate picks a lower storage-class price per GB (S3 One Zone-IA, Glacier Instant Retrieval, or Deep Archive) for data that is accessed frequently, or compares NAT Gateway, cross-AZ transfer, or provisioned capacity using only the headline hourly rate.
Price-per-GB is the number candidates remember from study material, while retrieval fees, minimum storage durations, request charges, per-GB processing, and cross-AZ data transfer are the numbers that decide the real bill.
What to do instead
Compute a total cost checklist before choosing: storage rate x GB, plus request count charges, plus retrieval fees per GB, plus minimum billable duration (30 days for Standard-IA/One Zone-IA, 90 days for Glacier Instant Retrieval/Flexible Retrieval, 180 days for Deep Archive), plus data transfer in/out and cross-AZ. If the data is accessed more than roughly once a month or is smaller than 128 KB per object, Standard usually wins. For NAT Gateway, price per hour plus per-GB processed, and remember it is per AZ.
The candidate answers 'On-Demand for everything' to avoid commitment risk, or proposes Spot Instances for a stateful primary database or a workload that cannot tolerate interruption, or ignores Savings Plans and Reserved capacity entirely.
There is a bias toward the safest-sounding option, and commitment-based pricing feels risky, so the candidate eliminates the correct cost answer. Conversely, 'cheapest compute' is chosen when the words Spot appear, without checking fault tolerance.
What to do instead
Split the workload into three buckets and price each: steady-state baseline that runs 24/7 = Compute Savings Plans or Reserved Instances (and DynamoDB reserved capacity, ElastiCache reserved nodes); unpredictable or short-lived = On-Demand; fault-tolerant, checkpointed, interruption-tolerant batch/CI = Spot. If the stem gives a stable utilization percentage, that is a direct signal for a commitment-based option. If the stem says 'stateful', 'cannot be interrupted', or 'single database', eliminate Spot.