AWS Certified
Solutions Architect
The definitive SAA-C03 study guide covering all four domains — secure, resilient, high-performing, and cost-optimized architectures — plus 100 practice questions with detailed explanations and the Well-Architected Framework.
About the SAA-C03 Exam
The AWS Certified Solutions Architect – Associate validates the ability to design secure, resilient, high-performing, and cost-optimized architectures on AWS. It is the most popular AWS certification and one of the most sought-after cloud credentials in the industry.
📋 Exam Format
- 85 questions total (65 scored + 20 unscored)
- Multiple choice & multiple response
- 130 minutes duration
- Scaled score 100–1,000
- Minimum passing score: 720
- No penalty for guessing — answer every question
- Available in testing centers or online proctored
🎯 Domain Weightings
- Domain 1: Design Secure Architectures — 30%
- Domain 2: Design Resilient Architectures — 26%
- Domain 3: Design High-Performing Architectures — 24%
- Domain 4: Design Cost-Optimized Architectures — 20%
👤 Target Audience
- Solutions architects and cloud engineers
- Developers working with AWS infrastructure
- IT professionals moving to cloud roles
- 1+ years hands-on AWS experience recommended
- Strong understanding of networking, storage, compute
✅ Key AWS Services to Master
- Compute: EC2, Lambda, ECS, EKS, Fargate
- Storage: S3, EBS, EFS, FSx, Glacier
- Database: RDS, Aurora, DynamoDB, ElastiCache
- Network: VPC, Route 53, CloudFront, ALB/NLB
- Security: IAM, KMS, WAF, Shield, GuardDuty
- Integration: SQS, SNS, EventBridge, Step Functions
Domain 1 (30%) is largest — master IAM, VPC security, encryption, and S3 bucket policies. Domain 2 (26%) — know every HA and DR strategy: Multi-AZ, Auto Scaling, and RTO/RPO requirements. Domain 3 (24%) — EC2 instance types, caching, and read replicas. Domain 4 (20%) — spot instances, S3 storage classes, and Reserved vs. On-Demand. The exam is scenario-based: read carefully and eliminate obviously wrong answers first.
Design Secure Architectures
Domain 1 is the largest domain — it covers IAM, network security, data protection, and application security. Understanding the principle of least privilege and defense-in-depth is essential.
Secure Architectures
Task Statements: 1.1 Secure access to AWS resources · 1.2 Secure workloads & applications · 1.3 Determine appropriate data security controls
IAM & Identity Management
| IAM Concept | Description | Key Exam Points |
|---|---|---|
| IAM User | Long-term credentials for a person or service with username/password + access keys | Avoid for applications; use roles. Enable MFA for all users. |
| IAM Group | Collection of IAM users sharing the same permissions via attached policies | Groups cannot be nested. Use for team-level permissions. |
| IAM Role | Temporary credentials assumed by users, services, or AWS resources — no long-term keys | Best practice for EC2, Lambda, cross-account access |
| IAM Policy | JSON document defining Allow/Deny for actions on resources with optional conditions | Explicit Deny always wins. Policies: identity-based, resource-based, SCPs |
| Service Control Policies (SCPs) | Organization-level policies that restrict maximum permissions for accounts | Applied via AWS Organizations. SCPs don't grant permissions — they set guardrails. |
| AWS Organizations | Management of multiple AWS accounts with hierarchical OUs and centralized billing | Enable SCPs for governance. Use for multi-account strategies. |
| IAM Permission Boundary | Limits the maximum permissions an identity-based policy can grant to an IAM entity | Used to delegate permission management safely. |
| AWS SSO / IAM Identity Center | Centralized SSO and workforce identity management across AWS accounts and apps | Replace individual IAM users in multi-account environments |
| Amazon Cognito | User identity for web/mobile apps: User Pools (auth) + Identity Pools (AWS credentials) | User Pools = authentication. Identity Pools = authorization (federated AWS access) |
Grant only the minimum permissions required to perform a task. Start with zero permissions and add as needed. Use IAM Access Analyzer to identify unused permissions. Enable MFA for all privileged accounts. Never embed access keys in code — use IAM roles for EC2, Lambda, and ECS.
AWS KMS: Managed key creation, storage, and auditing. Customer-managed keys (CMKs) for full control. Integrates with S3, EBS, RDS, Secrets Manager.
AWS Secrets Manager: Store, rotate, and retrieve database passwords and API keys. Auto-rotation via Lambda.
AWS Certificate Manager (ACM): Free SSL/TLS certificates for ELB, CloudFront, API Gateway.
| S3 Security Control | Purpose | When to Use |
|---|---|---|
| Bucket Policy | Resource-based JSON policy on the bucket itself | Cross-account access, public access, IP-based restrictions |
| ACL (Access Control List) | Legacy per-object/bucket access control | Generally avoid — use bucket policies instead |
| Block Public Access | Account/bucket-level switch to prevent any public access | Enable always unless bucket must be public (static website) |
| S3 Object Lock | WORM (Write Once Read Many) compliance — prevents deletion/overwrite | Regulatory compliance (SEC 17a-4, FINRA) |
| S3 Encryption | SSE-S3 (AWS manages), SSE-KMS (customer controls), SSE-C (customer keys) | SSE-KMS for audit trail; SSE-S3 for simple encryption |
| Pre-signed URLs | Temporary URLs granting time-limited access to private objects | Sharing private files without making bucket public |
| VPC Endpoint for S3 | Private access to S3 without traversing the public internet | Private subnet resources accessing S3 |
VPC & Network Security
🌐 VPC Fundamentals
- VPC: Logically isolated network — you define IP ranges, subnets, route tables
- Public Subnet: Has route to Internet Gateway. Instances can get public IPs.
- Private Subnet: No route to Internet. Access internet via NAT Gateway.
- Internet Gateway (IGW): Allows VPC instances to communicate with internet
- NAT Gateway: Allows private subnet instances to reach internet (outbound only, AWS-managed)
- NAT Instance: Self-managed EC2 in public subnet for NAT (legacy)
🛡️ Security Groups vs. NACLs
Security Groups (Stateful):
- Applied at the instance/ENI level
- Stateful — return traffic automatically allowed
- Allow rules only (no explicit deny)
- Evaluated as a whole (all rules)
Network ACLs (Stateless):
- Applied at the subnet level
- Stateless — must allow both directions
- Allow AND deny rules
- Evaluated in order (lowest number first)
🔗 VPC Connectivity
- VPC Peering: One-to-one private connection. Not transitive.
- Transit Gateway: Hub-and-spoke connecting many VPCs. Transitive routing.
- VPN Gateway: IPSec VPN to on-premises. Encrypted over internet.
- AWS Direct Connect: Dedicated private line to AWS. Consistent bandwidth, lower latency.
- PrivateLink: Expose services to other VPCs via endpoint — no peering/IGW needed
- VPC Endpoints: Gateway (S3/DynamoDB) or Interface (most services)
🔒 Additional Security Services
- AWS WAF: Web Application Firewall — protect against SQLi, XSS, rate limiting
- AWS Shield Standard: Free DDoS protection for all AWS customers
- AWS Shield Advanced: Enhanced DDoS protection + 24/7 DRT + cost protection
- Amazon GuardDuty: ML-based threat detection — analyzes VPC Flow Logs, CloudTrail, DNS
- Amazon Macie: Discover and protect sensitive data in S3
- AWS Security Hub: Centralized security findings and compliance status
- Amazon Inspector: Automated vulnerability scanning for EC2, ECR, Lambda
Design Resilient Architectures
Domain 2 covers designing for high availability, fault tolerance, and disaster recovery. Understand Multi-AZ vs. Multi-Region, Auto Scaling, and RTO/RPO strategies.
Resilient Architectures
Task Statements: 2.1 Design scalable & loosely coupled architectures · 2.2 Design highly available & fault-tolerant architectures
High Availability & Auto Scaling
| Service | HA Capability | Key Configuration |
|---|---|---|
| EC2 Auto Scaling | Automatically adjust EC2 fleet size based on demand | Min/Max/Desired capacity. Scaling policies: Target Tracking (preferred), Step, Scheduled |
| Application Load Balancer (ALB) | Layer 7 HTTP/HTTPS load balancing across AZs | Path-based routing, host-based routing, WebSocket, sticky sessions. Best for microservices. |
| Network Load Balancer (NLB) | Layer 4 TCP/UDP ultra-high performance load balancing | Millions of requests/sec, static IPs, low latency. Best for gaming, IoT, real-time. |
| Gateway Load Balancer (GWLB) | Layer 3 for inline network traffic inspection appliances | Route traffic through 3rd-party firewalls/IDS systems transparently |
| RDS Multi-AZ | Synchronous standby in another AZ — automatic failover | Standby is not readable. Failover in ~1-2 min. For HA, not read scaling. |
| RDS Read Replicas | Asynchronous copies for read scaling (up to 5 for MySQL/PostgreSQL) | Can be in different AZ or Region. Can be promoted to primary. |
| ElastiCache | In-memory caching to reduce database load | Redis: persistence, replication, Multi-AZ. Memcached: simple horizontal scaling. |
🔄 Decoupling Patterns
- Amazon SQS: Managed message queue — decouple producers from consumers. Standard (at-least-once) vs. FIFO (exactly-once, ordered).
- Amazon SNS: Pub/Sub for fanout notifications to SQS, Lambda, HTTP, email, SMS
- Amazon EventBridge: Event bus connecting AWS services, custom apps, SaaS. Replaces CloudWatch Events.
- AWS Step Functions: Visual serverless workflow orchestration with retry logic and error handling
- Amazon Kinesis: Real-time data streaming. Kinesis Data Streams (custom processing), Firehose (ETL to S3/Redshift)
🚀 Serverless Architecture
- AWS Lambda: Function-as-a-Service. Pay per invocation. 15-min max timeout. Scales automatically.
- Amazon API Gateway: Managed REST/HTTP/WebSocket API frontend. Integrates with Lambda for serverless APIs.
- AWS Fargate: Serverless container execution for ECS/EKS. No EC2 management needed.
- Amazon DynamoDB: Serverless NoSQL database. Single-digit millisecond latency. Auto-scales throughput.
- Aurora Serverless: Aurora that auto-scales compute capacity based on load.
Disaster Recovery Strategies
RTO (Recovery Time Objective): Maximum acceptable downtime — how quickly must systems be restored after a disaster?
RPO (Recovery Point Objective): Maximum acceptable data loss — how much data can be lost (measured in time since last backup)?
Lower RTO/RPO = more expensive strategy. Exam asks which DR strategy meets stated RTO/RPO requirements.
| DR Strategy | RTO | RPO | Cost | Description |
|---|---|---|---|---|
| Backup & Restore | Hours | Hours | Lowest | Regular backups to S3 Glacier. Restore when needed. Simple but slow recovery. |
| Pilot Light | Minutes–Hours | Minutes | Low | Core services (DB) always running. Scale up compute when disaster occurs. |
| Warm Standby | Minutes | Seconds–Minutes | Medium | Scaled-down fully functional system always running. Scale up quickly on failover. |
| Multi-Site Active/Active | Near Zero | Near Zero | Highest | Full production running in multiple regions simultaneously. Route 53 for failover. |
Route 53 Routing Policies: Simple, Weighted, Latency-based, Failover, Geolocation, Geoproximity, Multivalue Answer.
Route 53 Health Checks: Monitor endpoints; trigger DNS failover automatically.
S3 Cross-Region Replication (CRR): Async replication of objects to another region for DR and latency.
DynamoDB Global Tables: Multi-region, multi-active replication. Low-latency reads/writes globally.
Aurora Global Database: Single primary in one region; up to 5 read-only regions. <1-second replication lag.
Design High-Performing Architectures
Domain 3 covers selecting the right compute, storage, database, and networking services to maximize performance. Know when to use caching, read replicas, and horizontal vs. vertical scaling.
High-Performing Architectures
Task Statements: 3.1 Determine high-performing & scalable storage · 3.2 High-performing elastic compute · 3.3 High-performing database · 3.4 High-performing networking
Compute, Storage & Networking
| EC2 Purchase Option | Use Case | Savings vs. On-Demand |
|---|---|---|
| On-Demand | Short-term, unpredictable workloads | 0% (baseline) |
| Reserved Instances (1-year) | Steady-state workloads, 1-year commitment | ~40% off |
| Reserved Instances (3-year) | Steady-state workloads, 3-year commitment | ~60% off |
| Savings Plans | Flexible compute, Lambda, Fargate — commit to $/hour not specific instances | ~66% off |
| Spot Instances | Fault-tolerant, flexible, stateless workloads. Can be interrupted with 2-min warning. | Up to 90% off |
| Dedicated Hosts | Physical server for compliance/licensing (BYOL) | Higher cost; meets regulatory requirements |
EBS Volume Types:
gp3 — General purpose SSD, 3,000–16,000 IOPS. Best for most workloads.
io1/io2 — Provisioned IOPS SSD, up to 64,000 IOPS. Critical databases.
st1 — Throughput-optimized HDD, sequential workloads (log processing).
sc1 — Cold HDD, lowest cost, infrequent access.
Instance Store: Ephemeral NVMe storage directly attached to host. Highest IOPS but data lost on stop/terminate.
Amazon CloudFront: Global CDN with 450+ PoPs. Cache static and dynamic content. Integrates with WAF, ACM, Lambda@Edge.
ElastiCache for Redis: In-memory caching with persistence, replication, Multi-AZ. Best for session management, leaderboards, real-time analytics.
ElastiCache for Memcached: Simple multi-threaded caching. No persistence. Best for simple object caching at scale.
DynamoDB Accelerator (DAX): In-memory cache for DynamoDB — microsecond read latency.
Storage Classes & Database Selection
| S3 Storage Class | Use Case | Retrieval | Cost |
|---|---|---|---|
| S3 Standard | Frequently accessed data | Milliseconds | Highest storage |
| S3 Intelligent-Tiering | Unknown or changing access patterns | Milliseconds | Monitoring fee |
| S3 Standard-IA | Infrequently accessed, rapid retrieval needed | Milliseconds | Lower storage, retrieval fee |
| S3 One Zone-IA | Infrequent access, single AZ (recreation-able data) | Milliseconds | 20% cheaper than Std-IA |
| S3 Glacier Instant | Long-term archive, millisecond access | Milliseconds | Low |
| S3 Glacier Flexible | Long-term archive, minutes-hours retrieval | 1 min – 12 hrs | Very low |
| S3 Glacier Deep Archive | Compliance archiving, 7-10 year retention | 12–48 hours | Lowest |
| Database Service | Type | Best For |
|---|---|---|
| Amazon RDS | Relational (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) | Traditional OLTP workloads requiring SQL, ACID transactions |
| Amazon Aurora | Relational (MySQL/PostgreSQL-compatible) — cloud-native | High-performance relational DB — 5x MySQL, 3x PostgreSQL performance |
| Amazon DynamoDB | NoSQL key-value + document | Single-digit ms latency, serverless, massive scale, flexible schema |
| Amazon Redshift | Data warehouse (OLAP, columnar) | Analytics on petabytes of data. BI tools, SQL queries over historical data |
| Amazon ElastiCache | In-memory (Redis/Memcached) | Caching, session management, real-time analytics, sub-millisecond latency |
| Amazon Neptune | Graph database | Social networks, fraud detection, knowledge graphs, relationship queries |
| Amazon DocumentDB | Document (MongoDB-compatible) | JSON document storage, MongoDB migration, flexible schemas |
| Amazon Keyspaces | Wide-column (Cassandra-compatible) | Cassandra workloads at scale, time-series data |
Design Cost-Optimized Architectures
Domain 4 covers selecting the most cost-effective storage, compute, and database options. Know the AWS pricing models and use the Well-Architected Cost Optimization pillar principles.
Cost-Optimized Architectures
Task Statements: 4.1 Design cost-optimized storage · 4.2 Cost-optimized compute · 4.3 Cost-optimized database · 4.4 Cost-optimized networking
Cost Optimization Strategies
💰 Compute Cost Optimization
- Right-sizing: Match EC2 instance type to actual workload needs
- Spot Instances: Up to 90% savings for fault-tolerant workloads
- Savings Plans: Flexible commitment for compute, Lambda, Fargate
- Reserved Instances: Up to 60% off for steady-state workloads
- Auto Scaling: Scale down during low demand periods
- Lambda for variable workloads: Pay only per invocation — no idle cost
- Fargate Spot: Spot pricing for containerized workloads
📦 Storage Cost Optimization
- S3 Lifecycle Policies: Automatically transition objects to cheaper storage classes
- S3 Intelligent-Tiering: Automatic tiering for unknown access patterns
- S3 Glacier Deep Archive: Lowest cost for 7+ year compliance archives
- EBS Snapshots: Delete unused snapshots; use EBS snapshot archive tier
- EFS Infrequent Access: Auto-tiering for EFS files not accessed in 30 days
- Delete unattached EBS volumes to eliminate idle storage costs
🗄️ Database Cost Optimization
- Aurora Serverless: Pay per ACU-hour when active, pause when idle
- DynamoDB On-Demand: Pay per request for unpredictable workloads
- DynamoDB Reserved Capacity: Up to 67% off for predictable DynamoDB usage
- RDS Reserved Instances: Up to 60% savings for stable DB workloads
- Stop RDS when not needed: Dev/test databases — can stop for up to 7 days
🌐 Networking Cost Optimization
- Data transfer costs: Inbound free; outbound to internet = billable
- S3 Transfer Acceleration: Only pay when faster; skip if not needed
- VPC Endpoints: Avoid NAT Gateway data processing costs for S3/DynamoDB
- CloudFront: Reduce origin fetch costs by caching at edge
- Same-AZ traffic is free; cross-AZ costs $0.01/GB each direction
- Direct Connect: Cheaper per-GB data transfer vs. internet VPN at high volume
| AWS Cost Tool | Purpose | Key Use |
|---|---|---|
| AWS Cost Explorer | Visualize and analyze AWS spending patterns | Historical spend analysis, RI recommendations, forecasting |
| AWS Budgets | Set custom cost/usage/reservation budgets with alerts | Alert when spend exceeds threshold; enforce with Budget Actions |
| AWS Pricing Calculator | Estimate costs before deploying | Pre-deployment cost estimation for architecture decisions |
| AWS Trusted Advisor | Best practice checks including cost optimization | Identify idle resources, underutilized instances, RI opportunities |
| AWS Compute Optimizer | ML-based recommendations for EC2, Lambda, EBS sizing | Right-sizing recommendations based on actual utilization metrics |
| Cost Allocation Tags | Tag resources to allocate costs by team, project, or environment | Chargeback, showback, cost center reporting |
AWS Well-Architected Framework
The Well-Architected Framework provides best practices for building cloud workloads across six pillars. SAA-C03 tests your ability to apply these principles to architecture scenarios.
🏛️ Operational Excellence
Run and monitor systems to deliver business value and continually improve processes.
- Infrastructure as Code (CloudFormation, CDK)
- Runbooks and playbooks for operations
- Observability: CloudWatch, X-Ray, CloudTrail
- Frequent, small, reversible changes
🔐 Security
Protect information, systems, and assets while delivering business value.
- Implement strong identity foundation (IAM)
- Enable traceability (CloudTrail, Config)
- Apply security at all layers (defense-in-depth)
- Automate security best practices
- Protect data in transit and at rest (KMS, TLS)
🔄 Reliability
Ensure workloads perform correctly and recover from failures.
- Automatically recover from failure (Auto Scaling)
- Test recovery procedures (chaos engineering)
- Scale horizontally to increase aggregate availability
- Stop guessing capacity — use Auto Scaling
- Manage change through automation
⚡ Performance Efficiency
Use computing resources efficiently to meet requirements and maintain that efficiency as demand changes.
- Use advanced technologies (Lambda, EKS)
- Go global in minutes (CloudFront, Global Accelerator)
- Use serverless architectures to reduce ops
- Experiment more often
💰 Cost Optimization
Avoid unnecessary costs and optimize spending over time.
- Adopt a consumption model (pay for what you use)
- Measure overall efficiency (Cost Explorer)
- Stop spending money on undifferentiated heavy lifting
- Analyze and attribute expenditure
🌱 Sustainability
Minimize the environmental impact of running cloud workloads.
- Understand your impact metrics
- Maximize utilization (right-size resources)
- Use managed services to reduce infrastructure footprint
- Reduce downstream impact of cloud workloads
The AWS Well-Architected Tool is a free service in the AWS Console that allows you to review your workloads against the six pillars and get actionable recommendations. Use it to identify high-risk issues (HRIs) in your architecture and track improvement over time.
100 Practice Questions
SAA-C03 — covering all four domains with detailed explanations