Official source note
aws saa c03 practice exam is the main focus of this page, and the safest way to study it is to keep the exam hub open while you work through the official facts and the service selection patterns. AWS describes AWS Solutions Architect - Associate (SAA-C03) as a certification that validates practical cloud literacy, service selection, and scenario thinking. The main Cert Pass hub remains /exams/aws-aws-solutions-architect-associate-saa-c03.
Exam facts
- Exam name: AWS Solutions Architect - Associate (SAA-C03)
- Exam slug: aws-aws-solutions-architect-associate-saa-c03
- Vendor: AWS
- Cert Pass landing page: /exams/aws-aws-solutions-architect-associate-saa-c03
- Study hub: /exams/aws-aws-solutions-architect-associate-saa-c03
- Official vendor page: AWS Certified Solutions Architect - Associate
Why this article exists
The goal here is not to collect trivia. The goal is to build the habit of reading a scenario, identifying the category, and choosing the simplest service that directly fits the requirement.
Fast study map
Use the exam hub twice during review: /exams/aws-aws-solutions-architect-associate-saa-c03 and /exams/aws-aws-solutions-architect-associate-saa-c03. Those internal links should act as the stable anchor for practice, revision, and final review.
This practice exam page is designed to mirror the style of the AWS Solutions Architect Associate SAA C03 test. The focus is on realistic service selection, not on trivia.
Exam snapshot
| Item | Details |
|---|---|
| Exam name | AWS Certified Solutions Architect Associate |
| Exam code | SAA-C03 |
| Questions | 65 |
| Time limit | 130 minutes |
| Format | Multiple choice and multiple response |
| Cost | 150 USD |
| Official source | AWS certification page |
Practice blueprint
| Area | What it tests | Common correct choice |
|---|---|---|
| Storage and backup | Object, block, shared file, and archive decisions | S3, EBS, EFS, Glacier |
| Compute selection | Serverless, containers, and virtual machines | Lambda, Fargate, EC2 |
| Database choice | Relational, NoSQL, analytics, caching | RDS, Aurora, DynamoDB, Redshift, ElastiCache |
| Networking | Connectivity, DNS, delivery, private access | VPC, Route 53, CloudFront, Direct Connect, VPC endpoints |
| Security and operations | Access, audit, monitoring, and compliance | IAM, KMS, CloudTrail, CloudWatch, Config |
How to use the practice set
- Read the entire scenario before looking at the options.
- Mark the primary requirement first, such as cost, resiliency, or latency.
- Remove any option that violates a constraint or adds unnecessary complexity.
- Review the explanation after each question and write down the reason the wrong answers failed.
Scenario themes to watch for
| Theme | Example signal | Typical answer shape |
|---|---|---|
| High availability | The prompt mentions one region, multiple AZs, or failover | Multi AZ design or managed redundancy |
| Decoupling | Producers and consumers should not wait on each other | SQS or SNS |
| Private connectivity | Traffic must stay off the public internet | VPC endpoint, VPN, or Direct Connect |
| Cost control | The prompt emphasizes low cost or predictable spend | Reserved capacity, Spot, or right sizing |
| Global delivery | Users are distributed geographically | CloudFront and regional design |
Extended official revision notes
AWS Certified Solutions Architect - Associate (SAA-C03) Exam Course
1. Exam Overview
What the exam is testing
The AWS Certified Solutions Architect - Associate (SAA-C03) exam tests whether you can design secure, resilient, high-performing, and cost-optimized architectures on AWS. It is not mainly a memorization exam. Most questions describe a business scenario, constraints, and several plausible AWS services. Your job is to choose the design that best satisfies the requirement with the least operational burden and the most appropriate tradeoff.
The exam commonly tests your ability to:
- Translate business requirements into AWS architecture choices.
- Select the right managed service instead of overengineering.
- Apply security controls without breaking application access.
- Design for Availability Zone or Regional failure where required.
- Improve performance with caching, scaling, partitioning, and service selection.
- Reduce cost without sacrificing stated requirements.
- Eliminate distractors that are technically possible but not the best architecture.
How to think like the exam
Read every scenario in this order:
- Requirement: What must the architecture achieve? Security, resiliency, performance, cost, migration, or operations?
- Constraint: Least operational effort, no code change, low latency, private connectivity, multi-account governance, compliance, or cost reduction?
- Data pattern: Object, block, file, relational, key-value, streaming, queue, analytics, or archive?
- Traffic pattern: Steady, unpredictable, spiky, global, read-heavy, write-heavy, or batch?
- Failure scope: Instance, Availability Zone, Region, account, or user mistake?
- Best AWS-native answer: Prefer managed, scalable, secure-by-default services unless the question explicitly requires custom control.
How to use this course
Use this file as a compressed revision guide. First read the domain sections to understand the exam logic. Then use the service-selection tables to learn how to choose between confusing AWS services. Finally, use the exam traps, memory rules, and exam-day checklist to revise quickly before the test.
This course is synthesized from the SAA-C03 blueprint and from repeated patterns in the generated practice question bank. It does not reproduce raw questions or dumps.
2. Exam Domains
| Domain | Official Weight | Priority | What matters most |
|---|---|---|---|
| Design Secure Architectures | 30% | Highest | IAM, VPC security, private access, encryption, logging, multi-account guardrails, data protection |
| Design Resilient Architectures | 26% | Very high | Multi-AZ, backup, disaster recovery, decoupling, failover, stateless design, durable storage |
| Design High-Performing Architectures | 24% | High | Scalable compute, caching, databases, storage performance, network acceleration, global delivery |
| Design Cost-Optimized Architectures | 20% | High | Pricing models, right sizing, storage classes, managed services, serverless, cost-aware data transfer |
Priority notes
Security has the largest weighting, so expect many questions where the obvious service is not enough unless access control, encryption, logging, or network isolation is handled correctly. Resiliency and performance questions often look similar, but resiliency focuses on surviving failures while performance focuses on latency, throughput, and scalability. Cost questions often contain traps where the cheapest option violates availability, durability, or performance requirements.
What matters most
The most repeated high-value services and concepts are:
- Amazon S3: storage classes, lifecycle policies, encryption, bucket policies, access points, versioning, replication, Object Lock, VPC endpoints.
- Amazon EC2: Auto Scaling, purchase options, placement groups, AMIs, EBS, instance families, load balancing.
- VPC networking: public/private subnets, NAT gateway, internet gateway, route tables, security groups, NACLs, VPC endpoints, peering, Transit Gateway, VPN, Direct Connect.
- IAM and Organizations: least privilege, roles, resource policies, SCPs, identity federation, permission boundaries.
- Databases: RDS/Aurora, DynamoDB, ElastiCache, Redshift, OpenSearch, read replicas, Multi-AZ, global tables.
- Resiliency services: ELB, Auto Scaling, Route 53 failover, AWS Backup, SQS, SNS, EventBridge, multi-AZ databases.
- Monitoring and governance: CloudWatch, CloudTrail, AWS Config, GuardDuty, Security Hub, WAF, Shield, Systems Manager.
3. Start-to-Finish Study Path
Foundation
Learn the core AWS building blocks before memorizing edge cases:
- AWS global infrastructure: Regions, Availability Zones, edge locations.
- Shared responsibility model.
- IAM users, groups, roles, policies, and resource-based policies.
- VPC basics: CIDR, subnets, route tables, gateways, security groups, NACLs.
- Storage basics: S3, EBS, EFS, FSx.
- Compute basics: EC2, Auto Scaling, ELB, Lambda, ECS/Fargate.
- Database basics: RDS, Aurora, DynamoDB, ElastiCache, Redshift.
Intermediate
Build service-selection instincts:
- Choose S3 vs EBS vs EFS vs FSx.
- Choose RDS/Aurora vs DynamoDB vs Redshift vs OpenSearch.
- Choose ALB vs NLB vs Gateway Load Balancer.
- Choose CloudFront vs Global Accelerator vs Route 53 latency routing.
- Choose SQS vs SNS vs EventBridge vs Step Functions.
- Choose VPN vs Direct Connect vs Transit Gateway vs VPC peering.
- Choose KMS key policy vs IAM policy vs bucket policy vs SCP.
Advanced
Practice tradeoff questions:
- Multi-AZ vs multi-Region.
- Read replica vs Multi-AZ standby.
- NAT gateway vs VPC endpoint.
- S3 Standard-IA vs One Zone-IA vs Glacier Instant Retrieval vs Flexible Retrieval vs Deep Archive.
- Reserved Instances vs Savings Plans vs Spot Instances.
- CloudFront caching vs ElastiCache vs DynamoDB DAX.
- S3 replication vs AWS Backup vs versioning.
- RTO/RPO-driven disaster recovery patterns.
Final review
Use the last stage to improve elimination speed:
- Mark the keyword that decides the answer: private, managed, least operational overhead, global low latency, compliance, multi-account, unpredictable traffic, archive, read-heavy, asynchronous, event-driven.
- Remove any answer that violates the explicit requirement.
- Prefer fully managed services when the question asks for reduced operational overhead.
- Prefer serverless when traffic is unpredictable and the workload fits the service limits.
- Prefer multi-AZ for high availability inside a Region; prefer multi-Region only when the question requires Regional disaster recovery or global users.
4. Core Concepts by Domain
Domain 1: Design Secure Architectures
Concepts
Security questions test whether you can design access control, network isolation, encryption, auditability, and governance together. The exam often gives a design that works functionally but misses a security control.
Key concepts:
- Least privilege: Grant only required actions on required resources.
- IAM roles over long-term keys: Use roles for EC2, Lambda, ECS tasks, and cross-account access.
- Resource policies: Use S3 bucket policies, KMS key policies, SQS queue policies, SNS topic policies, and Lambda resource policies when access is controlled from the resource side.
- SCPs: Use AWS Organizations service control policies to set account-level guardrails. SCPs do not grant permissions; they only limit maximum permissions.
- Encryption at rest: Use KMS-managed keys when audit, rotation, key policy control, or cross-account access matters.
- Encryption in transit: Use TLS/HTTPS, ACM certificates, ALB listeners, CloudFront viewer policies.
- Private access: Use VPC endpoints for private access to AWS services without internet or NAT.
- Secrets: Use AWS Secrets Manager for automatic rotation and AWS Systems Manager Parameter Store for configuration/secrets with simpler requirements.
- Monitoring and audit: Use CloudTrail for API activity, CloudWatch for metrics/logs/alarms, AWS Config for configuration history/compliance.
- Threat detection: GuardDuty detects suspicious activity; Inspector scans vulnerabilities; Macie discovers sensitive data in S3; Security Hub aggregates findings.
Services
- IAM, IAM Identity Center, STS, AWS Organizations, SCPs.
- Amazon VPC, security groups, NACLs, VPC endpoints, PrivateLink.
- AWS KMS, CloudHSM, ACM, Secrets Manager, Parameter Store.
- S3 bucket policies, S3 Block Public Access, Object Lock, versioning, access points.
- CloudTrail, CloudWatch Logs, AWS Config, GuardDuty, Security Hub, Inspector, Macie.
- AWS WAF and AWS Shield for application and DDoS protection.
Patterns
| Scenario | Recommended pattern | Why |
|---|---|---|
| EC2 needs to read S3 privately | Gateway VPC endpoint for S3 plus least-privilege bucket policy | Avoids NAT, internet gateway, and public IPs |
| Lambda needs database credentials | Secrets Manager with rotation | Avoids hardcoded credentials and supports rotation |
| Multi-account organization needs to prevent disabling logging | SCP denying CloudTrail disabling actions | Central governance control across accounts |
| Public web app needs protection from SQL injection | AWS WAF attached to CloudFront or ALB | Layer 7 filtering for common web attacks |
| Sensitive S3 data must not become public | S3 Block Public Access, bucket policy, IAM least privilege, encryption | Prevents accidental exposure |
| Cross-account access to S3 | IAM role assumption plus bucket policy/KMS key policy if encrypted | Both identity and resource permissions may be needed |
Traps
- Using IAM users/access keys for applications when an IAM role is available.
- Confusing SCPs with IAM policies: SCPs restrict; they do not grant.
- Forgetting KMS permissions: Access to an encrypted S3 object requires S3 permission and KMS key permission.
- Choosing NAT gateway for private S3 access when a gateway VPC endpoint is more secure and cheaper.
- Using security groups as deny rules: Security groups allow only; NACLs can allow and deny.
- Assuming CloudTrail prevents attacks: CloudTrail records API events; it does not block by itself.
Domain 2: Design Resilient Architectures
Concepts
Resiliency questions test how systems continue operating during failures. The exam usually asks for the simplest architecture that satisfies availability, durability, RTO, and RPO requirements.
Key concepts:
- High availability: Survive component or Availability Zone failures.
- Fault tolerance: Continue operating even when components fail.
- Durability: Avoid data loss.
- RTO: Maximum acceptable downtime.
- RPO: Maximum acceptable data loss.
- Stateless compute: Store session state outside instances, such as in ElastiCache, DynamoDB, or cookies.
- Decoupling: Use SQS, SNS, EventBridge, or Kinesis to absorb failure and spikes.
- Backups and replication: Use AWS Backup, snapshots, database backups, S3 versioning, and cross-Region replication as appropriate.
Services
- Elastic Load Balancing, Auto Scaling groups, Route 53 health checks/failover.
- RDS Multi-AZ, Aurora Multi-AZ, read replicas, Aurora Global Database.
- DynamoDB global tables, point-in-time recovery, on-demand backups.
- S3 versioning, replication, Object Lock, lifecycle rules.
- AWS Backup, Elastic Disaster Recovery, EBS snapshots, AMIs.
- SQS, SNS, EventBridge, Step Functions.
Patterns
| Scenario | Recommended pattern | Why |
|---|---|---|
| Stateless web app must survive AZ failure | ALB + Auto Scaling group across multiple AZs | Replaces unhealthy instances and routes to healthy AZs |
| RDS database needs automatic failover in same Region | RDS Multi-AZ deployment | Standby is for availability, not read scaling |
| Read-heavy RDS workload | Read replicas | Offloads reads, but not automatic primary failover unless promoted |
| Queue-based processing with traffic spikes | SQS + Auto Scaling workers or Lambda consumers | Decouples producers and consumers |
| Need near-zero data loss across Regions | Multi-Region replication or service-specific global option | Use only when Regional DR is required |
| Accidental object deletion must be recoverable | S3 versioning and optionally MFA Delete/Object Lock | Protects against user or application mistakes |
Traps
- Read replica vs Multi-AZ: Read replicas improve read scalability; Multi-AZ improves availability and failover.
- Backups are not high availability: Backups help recovery but do not automatically keep apps online.
- Multi-Region is not always required: It adds cost and complexity. Use it only if the question requires Regional resilience or global DR.
- EBS is AZ-scoped: To recover in another AZ, use snapshots or AMIs.
- EFS is Regional and multi-AZ by design: Useful for shared Linux file storage across AZs.
- SQS standard queues are at-least-once: Applications must handle duplicate messages.
Domain 3: Design High-Performing Architectures
Concepts
Performance questions test latency, throughput, scalability, and service fit. The best answer often uses caching, distribution, parallelism, read scaling, or a more suitable managed service.
Key concepts:
- Elasticity: Automatically add/remove capacity based on demand.
- Caching: Move repeated reads closer to users or applications.
- Partitioning: Scale data access through partition keys and sharding.
- Asynchronous processing: Use queues/events to avoid blocking user requests.
- Global acceleration: Use edge services for global users.
- Right storage performance: Choose the storage system that matches access pattern and throughput.
Services
- CloudFront, Global Accelerator, Route 53 latency/geolocation routing.
- ALB, NLB, Auto Scaling, EC2 placement groups.
- Lambda, ECS, EKS, Fargate.
- S3 Transfer Acceleration, multipart upload, S3 request rate scaling.
- EBS gp3/io2, EFS performance modes, FSx for Lustre/Windows/NetApp/OpenZFS.
- RDS read replicas, Aurora replicas, DynamoDB on-demand/provisioned capacity, DAX.
- ElastiCache for Redis/Memcached.
- Kinesis, MSK, SQS, EventBridge.
Patterns
| Scenario | Recommended pattern | Why |
|---|---|---|
| Global static content with low latency | CloudFront in front of S3 or ALB | Caches content at edge locations |
| Repeated database reads slow app | ElastiCache or read replicas depending on query pattern | Cache repeated results or scale reads |
| Key-value access at massive scale | DynamoDB | Managed, low-latency, serverless NoSQL |
| HPC workload needs low-latency instance networking | Cluster placement group | Packs instances close together for network performance |
| Frequent large uploads to S3 from global users | S3 Transfer Acceleration or multipart upload | Improves upload performance over long distances |
| Container workload with minimal server management | ECS/Fargate | Managed container execution without managing EC2 capacity |
Traps
- CloudFront vs Global Accelerator: CloudFront caches HTTP content; Global Accelerator improves TCP/UDP traffic using AWS global network without caching.
- ElastiCache vs read replica: Cache repeated queries/session data with ElastiCache; use read replicas for SQL read scaling.
- DAX vs ElastiCache: DAX is DynamoDB-specific cache; ElastiCache is general application caching.
- Provisioned IOPS vs gp3: Use io2/io2 Block Express for very high IOPS/critical workloads; gp3 is often cost-effective for general purpose.
- Lambda is not always best: Long-running or specialized runtime workloads may fit ECS, EKS, or EC2 better.
Domain 4: Design Cost-Optimized Architectures
Concepts
Cost questions test whether you can reduce spend while preserving requirements. The exam does not reward the cheapest option if it violates availability, latency, durability, or operations constraints.
Key concepts:
- Match pricing model to workload pattern.
- Use managed/serverless services when operational overhead matters.
- Right-size compute and storage.
- Move infrequently accessed data to cheaper storage classes.
- Avoid unnecessary NAT gateways, cross-AZ data transfer, idle resources, and overprovisioning.
- Use automation to stop, scale down, or lifecycle resources.
Services
- EC2 On-Demand, Reserved Instances, Savings Plans, Spot Instances, Capacity Reservations.
- S3 storage classes and lifecycle policies.
- DynamoDB on-demand vs provisioned capacity with auto scaling.
- Aurora Serverless, Lambda, Fargate, Auto Scaling.
- AWS Cost Explorer, Budgets, Compute Optimizer, Trusted Advisor.
- VPC endpoints, NAT gateway design, CloudFront caching for origin cost reduction.
Patterns
| Scenario | Cost-optimized choice | Why |
|---|---|---|
| Predictable EC2 workload for 1-3 years | Savings Plans or Reserved Instances | Lower cost than On-Demand for commitment |
| Fault-tolerant batch job | Spot Instances | Lowest EC2 cost if interruptions are acceptable |
| Unpredictable serverless API | Lambda + API Gateway | Pay per request and avoid idle capacity |
| Rarely accessed S3 data | Lifecycle to Standard-IA, Glacier Instant Retrieval, Flexible Retrieval, or Deep Archive | Match retrieval pattern to storage class |
| Private S3 access from VPC | S3 gateway endpoint | Often cheaper and more secure than NAT path |
| Dev/test used only during business hours | Scheduled start/stop or Auto Scaling | Avoid paying for idle compute |
Traps
- Spot is not for workloads that cannot tolerate interruption.
- One Zone-IA is cheaper but not multi-AZ resilient.
- Glacier Deep Archive is cheapest but not for immediate retrieval.
- Reserved Instances/Savings Plans require commitment; do not use them for uncertain or short-lived workloads.
- NAT gateway charges can be significant; VPC endpoints can reduce cost for private AWS service access.
- Overusing multi-Region increases cost unless the requirement justifies it.
5. Service Selection Guide
Storage services
| Need | Choose | Avoid when |
|---|---|---|
| Object storage, static assets, backups, data lake | Amazon S3 | You need block-level attach to EC2 or POSIX file system semantics |
| Block storage for one EC2 instance in one AZ | Amazon EBS | You need shared multi-instance file access across AZs |
| Shared Linux file system across AZs | Amazon EFS | You need Windows file shares or ultra-low-latency block storage |
| Windows file shares | FSx for Windows File Server | You need simple object storage |
| High-performance temporary file system for analytics/HPC | FSx for Lustre | You need durable general object storage only |
| Hybrid on-premises access to AWS storage | Storage Gateway | You only need cloud-native application storage |
| Transfer large datasets to AWS | DataSync or Snow Family | Small regular transfers that can use normal network paths |
Database and analytics services
| Need | Choose | Common wrong answer |
|---|---|---|
| Managed relational database | RDS | EC2-hosted database unless custom OS/database control is required |
| High-performance MySQL/PostgreSQL-compatible relational database | Aurora | DynamoDB if relational joins/transactions dominate |
| Serverless key-value/document access at scale | DynamoDB | RDS for unpredictable massive key-value traffic |
| In-memory cache/session store | ElastiCache | Read replica if data does not need SQL read scaling |
| Data warehouse analytics | Redshift | RDS for large analytical scans |
| Search/log analytics | OpenSearch Service | Redshift if full-text search is the key requirement |
| Ad hoc SQL over S3 data lake | Athena | Redshift if you do not need a provisioned warehouse |
| ETL catalog and jobs | AWS Glue | Lambda for heavy, long-running ETL jobs |
Compute services
| Need | Choose | Avoid when |
|---|---|---|
| Full server control | EC2 | You want least operational overhead |
| Event-driven short-running functions | Lambda | Long-running processes, custom OS, or unsupported runtime constraints |
| Containers with AWS-managed orchestration | ECS | Kubernetes-specific requirement exists |
| Kubernetes workloads | EKS | You do not need Kubernetes complexity |
| Containers without managing servers | Fargate | You need specialized host-level control |
| Batch jobs | AWS Batch | You need always-on low-latency API serving |
Load balancing and routing
| Need | Choose | Why |
|---|---|---|
| HTTP/HTTPS path or host routing | ALB | Layer 7 routing, WAF integration, containers, microservices |
| Extreme TCP/UDP performance or static IP | NLB | Layer 4, low latency, static IP support |
| Third-party virtual appliances | Gateway Load Balancer | Transparent insertion of firewalls/inspection appliances |
| DNS routing and failover | Route 53 | DNS-level health checks, failover, latency/geolocation routing |
| Cache content globally | CloudFront | Edge caching for HTTP/HTTPS |
| Improve global TCP/UDP app performance | Global Accelerator | Anycast static IPs and AWS global network, not caching |
Messaging and integration
| Need | Choose | Why |
|---|---|---|
| Decouple producers and consumers with buffering | SQS | Queue-based pull model |
| Fanout notifications to many subscribers | SNS | Pub/sub push model |
| Event bus and SaaS/AWS event routing | EventBridge | Event routing, filtering, schedules, integrations |
| Workflow orchestration with state | Step Functions | Visual/stateful workflows, retries, branching |
| Real-time streaming ingestion | Kinesis or MSK | Ordered stream processing and replay |
Security and governance
| Need | Choose | Why |
|---|---|---|
| Who did what API action? | CloudTrail | API audit history |
| Metrics and alarms | CloudWatch | Operational monitoring |
| Resource compliance and drift | AWS Config | Configuration timeline and rules |
| Threat detection | GuardDuty | Suspicious activity findings |
| Vulnerability scanning | Inspector | EC2/ECR/Lambda vulnerability scanning |
| Sensitive data discovery in S3 | Macie | PII/sensitive data detection |
| Web exploit protection | WAF | Layer 7 rules |
| DDoS protection | Shield | Standard by default; Advanced for enhanced protection |
6. Architecture Patterns
Pattern 1: Secure private application access to AWS services
Scenario: An application runs in private subnets and must access S3 or DynamoDB without internet access.
Recommended solution: Use gateway VPC endpoints for S3/DynamoDB. Use interface VPC endpoints powered by PrivateLink for services that require them. Restrict access with endpoint policies, bucket policies, and IAM.
Why alternatives are wrong: NAT gateway works but adds cost and sends traffic through an internet-facing path. Public IPs violate private-only requirements.
Pattern 2: Highly available web application
Scenario: A web app must remain available during instance or AZ failure.
Recommended solution: Use an ALB across multiple AZs, Auto Scaling group across multiple AZs, stateless application design, and database Multi-AZ where needed.
Why alternatives are wrong: A single EC2 instance, single-AZ database, or manual failover does not meet high availability requirements.
Pattern 3: Read-heavy relational workload
Scenario: A transactional database is overloaded by reporting queries.
Recommended solution: Add read replicas for read scaling. Use caching if queries are repeated and stale reads are acceptable. For analytics-heavy workloads, move to Redshift or Athena depending on the data model.
Why alternatives are wrong: Multi-AZ standby does not serve reads in standard RDS deployments. Increasing instance size may help but does not isolate reporting load.
Pattern 4: Asynchronous order processing
Scenario: An application receives bursts of orders and backend processing cannot keep up.
Recommended solution: Put SQS between the frontend and workers. Scale workers or Lambda consumers based on queue depth. Use DLQs for failed messages.
Why alternatives are wrong: Direct synchronous calls increase coupling and failure propagation. SNS alone does not provide durable worker buffering in the same way as SQS.
Pattern 5: Global static and dynamic content
Scenario: Users worldwide need low-latency access to an application.
Recommended solution: Use CloudFront for cacheable HTTP content and origin acceleration. Use Route 53 latency routing or Global Accelerator when appropriate for dynamic/non-cacheable traffic.
Why alternatives are wrong: Deploying only in one Region without edge optimization may cause high latency. Multi-Region may be unnecessary if caching solves the requirement.
Pattern 6: Disaster recovery by RTO/RPO
| Requirement | Typical strategy | Notes |
|---|---|---|
| Low cost, longer recovery | Backup and restore | Lowest cost, highest RTO |
| Faster recovery with prebuilt core resources | Pilot light | Minimal environment always on |
| Faster still with scaled-down environment | Warm standby | Reduced capacity always running |
| Near-zero downtime | Multi-site active-active | Highest cost and complexity |
Pattern 7: Cost-optimized data lake
Scenario: Large volumes of data are stored and analyzed occasionally.
Recommended solution: Store data in S3, use lifecycle policies, query with Athena for ad hoc SQL, catalog with Glue, and use appropriate S3 storage classes.
Why alternatives are wrong: Keeping all data in RDS or Redshift may be expensive for rarely accessed data.
Pattern 8: Multi-account governance
Scenario: A company has many AWS accounts and needs centralized control.
Recommended solution: Use AWS Organizations, OUs, SCPs, centralized CloudTrail, AWS Config aggregators, and IAM Identity Center.
Why alternatives are wrong: Manually configuring each account does not scale and is error-prone. SCPs alone do not grant permissions; IAM policies are still needed.
7. Exam Traps
Misleading wording
| If the question says... | Think... |
|---|---|
| Least operational overhead | Managed or serverless service |
| Private access to S3/DynamoDB from VPC | Gateway VPC endpoint |
| Public internet not allowed | No public IP, no internet gateway path, prefer private endpoint |
| Protect against accidental deletion | Versioning, MFA Delete, Object Lock, backups |
| Automatic failover for RDS | Multi-AZ |
| Scale reads from RDS | Read replicas |
| Global static content | CloudFront |
| Static IP and global network acceleration | Global Accelerator |
| Decouple components | SQS, SNS, EventBridge depending on pattern |
| Fanout to many subscribers | SNS |
| Workflow with retries and branching | Step Functions |
| Unpredictable traffic | Serverless or auto scaling |
| Fault-tolerant batch, lowest cost | Spot Instances |
| Predictable 24/7 compute | Savings Plans or Reserved Instances |
Wrong-but-plausible answers
- NAT gateway for S3 private access: Technically works but VPC endpoint is usually better.
- Read replica for automatic failover: Not the primary HA solution for RDS; Multi-AZ is.
- CloudWatch instead of CloudTrail: CloudWatch monitors metrics/logs; CloudTrail audits API calls.
- AWS Config instead of CloudTrail: Config tracks resource configuration/compliance; CloudTrail records API activity.
- S3 One Zone-IA for critical data: Cheaper but not resilient to AZ loss.
- Spot for non-interruptible workload: Cost-effective but unsuitable if interruptions cannot be tolerated.
- SCP to grant permissions: SCPs only restrict; IAM grants.
- Security group deny rule: Security groups do not support deny rules.
- Multi-Region for every HA question: Often unnecessary unless Regional failure or global recovery is required.
Elimination strategy
- Cross out answers that violate the explicit requirement.
- Cross out answers that add unnecessary operational overhead when a managed service exists.
- Cross out answers that solve the wrong problem: performance vs resiliency vs cost vs security.
- Cross out answers that are technically possible but not AWS best practice.
- Between two good answers, choose the one with fewer moving parts and better alignment with the keyword.
8. Quick Memory Rules
Rules of thumb
- S3 is object storage, not a file system or block device.
- EBS is for one EC2 instance in one AZ unless using specific multi-attach cases.
- EFS is shared Linux file storage across AZs.
- FSx is for specialized file systems such as Windows, Lustre, NetApp ONTAP, or OpenZFS.
- RDS Multi-AZ = availability.
- RDS Read Replica = read scaling.
- DynamoDB = serverless key-value/document at scale.
- Redshift = data warehouse.
- Athena = serverless SQL on S3.
- ElastiCache = in-memory cache.
- CloudFront = edge cache.
- Global Accelerator = global network acceleration, static anycast IPs.
- SQS = queue.
- SNS = pub/sub fanout.
- EventBridge = event bus and routing.
- Step Functions = workflow orchestration.
- CloudTrail = API audit.
- CloudWatch = metrics/logs/alarms.
- AWS Config = configuration compliance.
- GuardDuty = threat detection.
- Inspector = vulnerability scanning.
- Macie = sensitive data discovery in S3.
- WAF = web exploit filtering.
- Shield = DDoS protection.
Fast service mapping
| If you see X | Think Y |
|---|---|
| Static website hosting | S3 + CloudFront |
| Private S3 from VPC | Gateway VPC endpoint |
| Rotate database secrets | Secrets Manager |
| Organization-wide deny | SCP |
| Temporary cross-account access | IAM role + STS |
| Audit API calls | CloudTrail |
| Detect open security groups over time | AWS Config |
| Detect suspicious account behavior | GuardDuty |
| SQL injection protection | AWS WAF |
| Shared session state | ElastiCache or DynamoDB |
| Long polling queue | SQS |
| Many subscribers need same message | SNS fanout |
| Ordered exactly-once processing | SQS FIFO, with limits and deduplication |
| Analytics on S3 | Athena + Glue |
| Petabyte warehouse | Redshift |
| Millisecond key-value lookup | DynamoDB |
| Lowest interruptible compute | Spot Instances |
| Predictable compute discount | Savings Plans or Reserved Instances |
| Archive for years, rare retrieval | S3 Glacier Deep Archive |
9. Final Revision Notes
Highest-yield review points
- IAM roles, resource policies, SCPs, and KMS key policies.
- VPC networking: public/private subnets, NAT, endpoints, security groups, NACLs.
- S3: storage classes, lifecycle, encryption, versioning, replication, Object Lock, access control.
- RDS/Aurora: Multi-AZ, replicas, backups, failover, scaling.
- DynamoDB: on-demand/provisioned, partition keys, global tables, DAX, TTL, PITR.
- ELB + Auto Scaling across multiple AZs.
- Decoupling with SQS/SNS/EventBridge/Step Functions.
- CloudFront, Route 53, Global Accelerator differences.
- DR patterns: backup/restore, pilot light, warm standby, active-active.
- Cost optimization with EC2 purchase options, S3 lifecycle, right sizing, serverless, and VPC endpoints.
Last-day revision list
- Review the four official domains and their weights.
- Memorize service-selection tables.
- Practice identifying the keyword in each scenario.
- Review all traps in Section 7.
- Redo missed questions and classify each miss: security, resiliency, performance, cost, or wording trap.
- Do not overfocus on obscure services. The exam rewards correct architecture tradeoffs.
10. Exam-Day Checklist
Must-know topics
- IAM roles vs users vs resource policies.
- SCPs restrict but do not grant permissions.
- KMS permissions are required in addition to service permissions.
- S3 Block Public Access, bucket policies, encryption, versioning, lifecycle, replication.
- Gateway vs interface VPC endpoints.
- Security groups vs NACLs.
- NAT gateway vs internet gateway.
- ALB vs NLB vs Gateway Load Balancer.
- CloudFront vs Global Accelerator vs Route 53 routing.
- RDS Multi-AZ vs read replicas.
- Aurora replicas and Aurora Global Database.
- DynamoDB capacity modes, global tables, DAX, PITR.
- SQS vs SNS vs EventBridge vs Step Functions.
- EBS vs EFS vs FSx vs S3.
- S3 storage classes and retrieval tradeoffs.
- EC2 On-Demand vs Reserved Instances vs Savings Plans vs Spot.
- Auto Scaling policies and multi-AZ deployment.
- CloudWatch vs CloudTrail vs AWS Config.
- GuardDuty vs Inspector vs Macie vs Security Hub.
- Backup, restore, pilot light, warm standby, active-active DR.
Final confidence checklist
Before you start the exam, remember:
- Look for the required outcome first, not the service names.
- Do not choose the most complex architecture unless the scenario requires it.
- Managed and serverless services often win when operations must be minimized.
- Multi-AZ solves most high availability questions; multi-Region solves Regional disaster recovery and global access questions.
- Cost optimization must not violate stated requirements.
- Security answers often require both identity permissions and resource-side controls.
- If two answers work, choose the one that is simpler, more managed, more secure, and closer to the exact wording.
Source Question Bank Pattern Summary
The practice bank used for this course contains 1008 rows organized by official SAA-C03 domain weighting:
| Domain | Rows |
|---|---|
| Design Secure Architectures | 302 |
| Design Resilient Architectures | 262 |
| Design High-Performing Architectures | 242 |
| Design Cost-Optimized Architectures | 202 |
The highest-frequency repeated concepts in the source bank were S3, EC2, AWS Config, EBS, RDS, VPC, IAM, AWS Backup, CloudFront, Route 53, NAT Gateway, Auto Scaling, WAF, CloudTrail, EFS, KMS, ALB, SQS, DynamoDB, Lambda, and CloudWatch. These topics receive priority throughout the guide because they are the strongest recurring exam patterns.
Recommended Revision Method
- Read Sections 1-4 once to understand the exam structure.
- Memorize Section 5 service selection tables.
- Use Section 6 to practice architecture reasoning.
- Drill Section 7 traps before doing practice questions.
- Use Section 10 as the final checklist on exam day.
FAQ
How should the practice set be reviewed?
Read every explanation and focus on the AWS service that directly solves the requirement.
What makes a practice question useful?
It should force a trade off between two or more plausible AWS services.
Should the answers be memorized?
No. The better habit is to understand the requirement and the service boundary.
What should be done after the practice set?
Return to the exam page and repeat the weak topic areas until the reasoning feels natural.
Official source
Review the AWS Certified Solutions Architect Associate certification page for the current exam summary and official details.
Next step
Open the exam page here: AWS SAA C03 exam page
