The AWS Certified Solutions Architect – Associate (SAA-C03) is the most widely held cloud certification and the one most job posts name. It does not test whether you can click through the console; it tests whether, given a scenario with constraints, you pick the architecture that is secure, resilient, performant and cost-effective in AWS's own terms. That makes it learnable in a structured way: know the exam's four domains and their weights, learn the small set of services that appear again and again, internalise the decision rules the questions are built on, and practise reading scenarios for the keywords that point to the answer. This guide covers exactly that, with a six-week plan, a cheat sheet of the services that matter, and questions in the exam's style. Exam facts here were checked against the official exam guide (version 1.1) in September 2026; confirm them on the AWS certification page before you book.
- Describe the SAA-C03 exam format, scoring and the four domains with their weights
- Map each domain to the services and decision rules the questions actually test
- Read a scenario question for its constraint keywords and eliminate distractors systematically
- Follow a six-week study plan that combines hands-on labs with practice questions
- Walk into the exam knowing what to expect on the day
The exam at a glance
SAA-C03 is 65 questions in 130 minutes: 50 scored and 15 unscored pretest items you cannot distinguish, multiple choice (one of four) and multiple response (two or more of five or more). Scores are scaled 100 to 1,000 with a passing mark of 720, compensatory across domains — you need to pass overall, not each section. It costs 150 USD, is offered at test centres and online with a proctor, and the certification is valid for three years. AWS states a target of one year of hands-on design experience; people pass with less if they lab deliberately.
| Domain | Weight | What it really tests |
|---|---|---|
| 1. Design Secure Architectures | 30% | IAM, multi-account, encryption, network isolation, secure application access |
| 2. Design Resilient Architectures | 26% | Multi-AZ and multi-Region, decoupling, failover, backup and recovery objectives |
| 3. Design High-Performing Architectures | 24% | Choosing compute, storage, database and network options for scale and latency |
| 4. Design Cost-Optimized Architectures | 20% | Storage classes, purchase options, right-sizing, data transfer costs |
Every question is a scenario with a requirement and usually a constraint ("most cost-effective", "least operational overhead", "minimal changes to the application"). The constraint decides between two technically valid answers, and it is the single most important thing to read.
Domain 1: Secure architectures (30%)
The largest domain is mostly identity and isolation. IAM: users, groups, roles and policies; identity-based versus resource-based policies; how an explicit deny always wins; permission boundaries; roles for EC2, Lambda and cross-account access via STS; IAM Identity Center for workforce SSO. Multi-account: AWS Organizations with service control policies as guardrails, Control Tower for landing zones. Data protection: KMS with customer-managed keys, envelope encryption, S3 encryption options and bucket policies, Secrets Manager versus Parameter Store, Macie for discovering sensitive data. Network security: security groups (stateful, allow-only) versus network ACLs (stateless, ordered allow and deny), VPC endpoints so traffic to S3 or DynamoDB never leaves the AWS network, PrivateLink, WAF and Shield in front of CloudFront, ALB or API Gateway, and GuardDuty for threat detection.
- Role, never keys: an application on EC2 needing S3 access gets an instance profile; a Lambda gets an execution role; another account gets a role to assume. Any answer with access keys in code or on an instance is wrong.
- Least privilege with conditions: resource-level ARNs and conditions such as
aws:SourceVpceoraws:PrincipalOrgIDon bucket policies. - SCP versus IAM: SCPs set the maximum permissions for an account; they grant nothing. A user denied by an SCP cannot be allowed by IAM.
- Encryption keywords: "customer-managed key with rotation and audit" means KMS CMK; "client-side encryption" means the data is encrypted before it reaches AWS; "compliance requires you control the key material" points at CloudHSM or KMS with imported key material.
- Private access to AWS services: gateway endpoints for S3 and DynamoDB (free, route-table based); interface endpoints (PrivateLink) for most other services.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "OnlyFromOurVpcEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": ["arn:aws:s3:::acme-reports", "arn:aws:s3:::acme-reports/*"],
"Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0a1b2c3d4e5f6a7b8"}}
}]
}Domain 2: Resilient architectures (26%)
Resilience questions are about failure domains and decoupling. Know the hierarchy: an Availability Zone is one or more data centres; a Region is multiple isolated AZs; Multi-AZ protects against AZ failure, multi-Region against Regional failure and for disaster recovery. Learn each service's resilience story: EC2 in an Auto Scaling group across AZs behind an ALB; RDS Multi-AZ (synchronous standby, automatic failover, not for read scaling) versus read replicas (asynchronous, for reads, can be cross-Region and promoted); Aurora with multiple readers and Global Database; DynamoDB global tables; S3's eleven nines of durability and Cross-Region Replication; EFS as a regional file system; Route 53 health checks with failover routing.
Decoupling is its own sub-domain: SQS between producers and consumers so a slow consumer does not lose work (standard versus FIFO, visibility timeout, dead-letter queues), SNS for fan-out, EventBridge for event routing, Kinesis for ordered streaming, and Lambda or containers as elastic consumers. Disaster recovery questions give an RPO and RTO and expect you to pick the cheapest strategy that meets them: backup and restore (hours), pilot light (minutes to tens of minutes, core data replicated, compute off), warm standby (minutes, scaled-down copy running), multi-site active-active (seconds, full cost).
| Scenario keyword | Points at |
|---|---|
| "automatic failover for the database with no code change" | RDS Multi-AZ |
| "offload read traffic" | Read replicas or Aurora replicas, plus ElastiCache for hot data |
| "messages must be processed exactly once, in order" | SQS FIFO |
| "RTO of minutes, minimise cost" | Pilot light or warm standby, depending on the minutes |
| "route users away from an unhealthy Region" | Route 53 failover or latency routing with health checks |
| "stateless web tier across AZs" | ALB + Auto Scaling group across at least two AZs |
Domain 3: High-performing architectures (24%)
This domain is about picking the right tool for the access pattern. Compute: EC2 families (compute, memory, storage, accelerated), Auto Scaling policies (target tracking, step, scheduled, predictive), Lambda for event-driven bursts with its limits (15-minute timeout, memory-proportional CPU), ECS and EKS with Fargate to remove instance management. Storage: EBS types (gp3 general purpose, io2 for high IOPS, st1 throughput for sequential, sc1 cold) and that EBS is single-AZ; instance store for ephemeral speed; EFS for shared POSIX across instances; FSx for Windows or Lustre for HPC; S3 performance (prefixes, multipart, Transfer Acceleration, S3 Express One Zone for single-digit-millisecond access).
Databases: RDS engines for relational; Aurora for higher throughput and Serverless v2 for variable load; DynamoDB for key-value at any scale with DAX for microsecond reads and on-demand capacity for unpredictable traffic; ElastiCache (Redis for data structures and persistence, Memcached for simple caching); Redshift for warehousing; OpenSearch for search and log analytics; Neptune for graphs. Networking: CloudFront for global caching, Global Accelerator for TCP/UDP performance with static anycast IPs, Direct Connect for consistent private bandwidth, VPN as the quick or backup option, Transit Gateway for hub-and-spoke, and placement groups (cluster for low latency, spread for isolation, partition for large distributed systems).
When two answers both work, the exam usually prefers the managed one: Aurora over self-managed MySQL on EC2, Fargate over managing EC2 for containers, DynamoDB over a sharded RDS, unless the scenario says the application cannot change.
Domain 4: Cost-optimised architectures (20%)
Cost questions reward knowing the price levers by name. Compute purchase options: On-Demand for short or unpredictable; Savings Plans (compute or EC2 instance) and Reserved Instances for steady one- or three-year usage; Spot for interruptible, fault-tolerant work at up to 90% off, with Spot Fleet or mixed Auto Scaling groups; right-sizing with Compute Optimizer. Storage classes: S3 Standard, Intelligent-Tiering (unknown access patterns), Standard-IA and One Zone-IA (infrequent, with retrieval fees and minimum durations), Glacier Instant Retrieval, Flexible Retrieval and Deep Archive (archival with retrieval times from milliseconds to hours), lifecycle policies to move data between them. Data transfer: inbound is free, outbound to the internet costs, cross-AZ and cross-Region transfer costs, CloudFront and VPC endpoints reduce it, NAT gateways charge per GB processed.
- "Access patterns are unknown or change" means S3 Intelligent-Tiering.
- "Retrieval within milliseconds, rarely accessed, must be cheap" means Glacier Instant Retrieval.
- "Batch jobs that can be interrupted and restarted" means Spot.
- "Predictable steady workload for three years" means Savings Plans or Reserved Instances.
- "Large volume of traffic from private subnets to S3" means a gateway endpoint, not a NAT gateway.
- "Cost visibility per team" means cost allocation tags, Cost Explorer and Budgets; "consolidated billing across accounts" means Organizations.
Watch for the trap answers: One Zone-IA for data that needs high availability; Glacier Deep Archive when the scenario needs retrieval within an hour; Reserved Instances for a workload described as temporary; a bigger instance when Auto Scaling would fit variable demand.
Reading questions, and the six-week plan
A reliable method for each question: read the last sentence first (what is being asked and under which constraint), then read the scenario for the requirement keywords, then eliminate any option that violates a stated requirement or an AWS fact (EBS across AZs, Multi-AZ for read scaling, security group deny rules), then choose between the survivors by the constraint. Flag anything you cannot resolve in ninety seconds and return to it; the compensatory scoring means a few hard questions do not decide the result.
| Week | Focus | Hands-on lab |
|---|---|---|
| 1 | IAM, Organizations, VPC fundamentals, S3 (security and storage classes) | Two-tier VPC with public and private subnets, instance role reading S3 through a gateway endpoint |
| 2 | EC2, Auto Scaling, ELB, EBS, EFS; RDS and Aurora | ALB + Auto Scaling group across two AZs; RDS Multi-AZ with a forced failover |
| 3 | Decoupling: SQS, SNS, EventBridge, Lambda; DynamoDB; ElastiCache | SQS-fed Lambda with a dead-letter queue; DynamoDB table with DAX |
| 4 | Route 53, CloudFront, Global Accelerator, Direct Connect and VPN, Transit Gateway; KMS and encryption | CloudFront in front of S3 with OAC; KMS key with a policy; Route 53 failover records |
| 5 | Cost: purchase options, storage classes, data transfer; DR strategies; migration services | Lifecycle policy moving objects through tiers; Cost Explorer with tags; a pilot-light sketch |
| 6 | Practice exams, review of every wrong answer against the docs, weak-domain drills | Two full timed practice exams; re-lab anything scored under 70% |
Use the official practice question set and the free AWS Skill Builder exam-prep course; they show the question style precisely. Schedule the exam at the start of week five so the deadline is real. On the day: sleep, arrive early or set up the online proctoring space an hour before, and remember that the first minutes are the hardest — the questions do not get easier, you get calmer.