AWS SAP Specialty common mistakes
AWS SAP Specialty · Understand the traps and how to avoid them.
Choosing a single-account or hub-only network design when the scenario describes multiple business units, centralized security inspection, and shared services, instead of proposing AWS Organizations with OUs, SCPs, and a Transit Gateway or VPC sharing model.
Candidates pattern-match on the word 'VPC' and design connectivity alone, missing that organizational complexity questions are scored on governance (SCPs, centralized logging, account vending) as much as routing.
What to do instead
For every multi-account scenario, explicitly state the OU structure, which guardrails are SCPs versus IAM policies, how shared services (DNS, inspection, logging) are centralized, and how accounts are provisioned repeatably (Control Tower, Account Factory).
Using VPC peering for a full-mesh requirement across many VPCs, or proposing Transit Gateway without addressing route table segmentation and inspection insertion.
Peering is the most familiar primitive, so it is reached for first; candidates also forget that TGW needs separate route tables and appliance VPC attachments to force traffic through a firewall.
What to do instead
Compare options on scale and transitivity: peering is non-transitive and O(n^2), TGW is hub-and-spoke and transitive. Then describe TGW route table segmentation (prod/non-prod) and how to attach a inspection VPC with appliance mode for east-west filtering.
Designing cross-account access by distributing IAM users or long-lived access keys to each account rather than using IAM Identity Center, role assumption, and resource-based policies.
Access-key thinking is habitual from single-account work, and the question's phrasing about 'teams in different accounts' does not always say 'federated'.
What to do instead
Default to centralized identity (IAM Identity Center or SAML federation) with permission sets, cross-account AssumeRole, and trust policies scoped by ExternalId or aws:PrincipalOrgID. Reserve static keys only when the workload is explicitly outside AWS.
Proposing a single-Region, single-AZ deployment for a workload whose stated RTO/RPO or compliance requirements imply multi-AZ or multi-Region resilience, or over-engineering to active-active when the RTO does not justify it.
Candidates either ignore the numeric RTO/RPO in the prompt or anchor on the most resilient (and most expensive) option without checking the requirement.
What to do instead
Extract RTO and RPO first, map them to a strategy tier (backup and restore, pilot light, warm standby, active-active), and justify the choice against both the numbers and cost. State which components need Multi-AZ versus cross-Region replication.
Treating 'decoupled' and 'serverless' as interchangeable, and picking Lambda or SQS where the workload needs long-running processes, ordering guarantees, or exactly-once semantics.
Serverless is the fashionable default, and candidates do not check Lambda's 15-minute limit, SQS standard queue's at-least-once delivery, or FIFO throughput constraints against the stated workload profile.
What to do instead
Match the service to the constraint: run time limits, message ordering and deduplication, payload size, concurrency, and cold-start tolerance. Then name the failure-handling pattern (DLQ, idempotency key, Step Functions for orchestration) explicitly.
Designing a data layer on a single engine (usually RDS) without evaluating access patterns, and ignoring read replicas, caching, or purpose-built stores for the stated query shape.
Relational databases are the comfortable default; prompts describing high-volume key-value lookups or time-series ingestion are answered with an over-provisioned RDS instance.
What to do instead
State the access pattern (transactional, key-value at scale, analytical, time-series, document), then select the engine and add the read-scaling and caching layer (replicas, ElastiCache, DAX) with the consistency trade-off named.
Answering cost-optimization questions with a single lever such as Reserved Instances, rather than combining rightsizing, purchasing strategy, storage tiering, and architectural change.
RI/Savings Plans are the most memorable cost tool, so candidates stop there and miss that the scenario describes idle capacity, unattached volumes, or a steady-state versus spiky split.
What to do instead
Structure the answer as a sequence: measure (Cost Explorer, CUR, tagging), eliminate waste, rightsize, choose commitment coverage for the steady baseline, tier storage and logs, then re-architect where the workload shape allows. Quantify expected savings where the prompt gives numbers.
Proposing a migration cutover without addressing the operational baseline: no monitoring, logging, or rollback plan, and no defined success criteria for the migration.
Candidates focus on the target architecture and treat operations as an afterthought, even though existing-solution questions reward measurable improvement and safe change.
What to do instead
For each improvement, state the current metric, the target metric, the instrumentation (CloudWatch metrics/alarms, centralized logs, X-Ray), and the rollback trigger. Tie the change to a controlled rollout such as canary or blue/green.
Treating a migration as rehost-by-default and skipping the portfolio assessment, or conversely proposing refactoring for every application regardless of business value.
Rehost is the fastest path and easiest to describe, while refactor sounds most 'cloud-native'; candidates skip the 6 Rs analysis and the dependency discovery that determines the actual sequence.
What to do instead
Run discovery and dependency mapping first, classify each application into a migration strategy (retire, retain, rehost, replatform, refactor, repurchase) with a business justification, and sequence waves by dependency and risk. Name the tooling (Migration Hub, Application Discovery Service, DMS, MGN).
Designing the database migration as a one-shot dump-and-load and ignoring schema conversion, ongoing replication, and the cutover window for a heterogeneous migration.
Homogeneous migrations are simple enough that candidates generalize the approach, forgetting that heterogeneous moves need schema conversion and that minimal downtime requires continuous replication before cutover.
What to do instead
Split the plan into schema conversion (SCT), full load, change data capture for ongoing replication (DMS), validation of row counts and checksums, then a short cutover with a defined rollback path to the source still running.