Quick Review purpose
This Quick Review is for candidates preparing for the real AWS Certified Solutions Architect – Associate (SAA-C03) exam from AWS. Use it to refresh high-yield architecture decisions before moving into topic drills, mock exams, and detailed explanations.
The SAA-C03 exam is not mainly a memorization test. It rewards choosing the AWS service or architecture pattern that best satisfies requirements such as:
- High availability and fault tolerance
- Security and least privilege
- Performance and scalability
- Cost optimization
- Operational simplicity
- Migration constraints
- Data durability, retention, and access patterns
This page is IT Mastery review support and is not affiliated with AWS.
How to think like SAA-C03
Many questions describe a business workload and ask for the best or most cost-effective architecture. The right answer usually follows from the stated constraints.
| If the question says… | Think first about… | Common trap |
|---|
| “Least operational overhead” | Managed or serverless services | Choosing EC2 because it is familiar |
| “Highly available across AZs” | Multi-AZ design, managed HA, load balancing | Single EC2 instance, single NAT gateway, single DB instance |
| “Decouple components” | SQS, SNS, EventBridge, Kinesis | Direct synchronous calls between services |
| “Cost-effective for variable traffic” | Auto Scaling, serverless, Spot where appropriate | Overprovisioned always-on instances |
| “Static website or static assets” | S3 plus CloudFront | EC2 web servers for static content |
| “Shared file system for Linux EC2” | Amazon EFS | EBS attached to multiple instances generally not the right default |
| “Object storage, massive scale” | Amazon S3 | EFS or EBS for object-style data |
| “Relational database with minimal admin” | Amazon RDS or Aurora | Self-managed database on EC2 |
| “NoSQL key-value, single-digit millisecond access” | DynamoDB | RDS when no relational features are needed |
| “Real-time streaming ingestion” | Kinesis Data Streams / Firehose / MSK | SQS for ordered streaming analytics |
| “Hybrid private connectivity” | Site-to-Site VPN, Direct Connect, Transit Gateway | Public internet without stated acceptability |
| “Global low-latency content delivery” | CloudFront | Multi-Region EC2 without caching |
Core architecture principles
Availability, durability, and fault tolerance
| Concept | SAA-C03 review |
|---|
| Availability | Can users access the system when needed? Use Multi-AZ, load balancing, Auto Scaling, health checks, and failover. |
| Durability | Is data preserved after hardware or service failures? Use S3, backups, replication, snapshots, and managed database durability features. |
| Fault tolerance | Can the workload keep running after component failure? Design without single points of failure. |
| Disaster recovery | How quickly and how much data can be recovered? Understand backup/restore, pilot light, warm standby, and multi-site active-active at a conceptual level. |
| Elasticity | Can capacity increase and decrease automatically? Use Auto Scaling, serverless services, and managed scaling. |
Shared responsibility model
AWS is responsible for security of the cloud. Customers are responsible for security in the cloud.
| Area | AWS responsibility | Customer responsibility |
|---|
| Physical data centers | Facilities, hardware, physical controls | Select Regions/AZs as needed |
| Managed services infrastructure | Underlying hosts and service platform | Configure access, encryption, networking, logging |
| EC2 | Physical host, hypervisor | OS patching, security groups, IAM, app security |
| S3 | Storage infrastructure | Bucket policies, public access settings, encryption choices, lifecycle |
| RDS | Managed database platform | DB configuration, user access, backups/retention choices, parameter settings |
Exam trap: AWS manages more for serverless and managed services, but customers still configure identity, access, data classification, network exposure, and logging.
Networking and VPC review
VPC fundamentals
| Feature | What to remember |
|---|
| VPC | Isolated virtual network in a Region. |
| Subnet | Lives in one Availability Zone. Public/private depends on routing, not the name. |
| Public subnet | Route table sends internet-bound traffic to an Internet Gateway. |
| Private subnet | No direct route to Internet Gateway for inbound internet access. |
| Internet Gateway | Allows public internet connectivity for resources with public IPs and proper routing. |
| NAT Gateway | Lets private subnet resources initiate outbound internet traffic. Managed and preferred over NAT instances for most exam scenarios. |
| Route table | Controls where network traffic is directed. |
| Security group | Stateful instance-level or ENI-level firewall. Allows rules only. |
| Network ACL | Stateless subnet-level firewall. Allows and denies rules. |
| VPC endpoint | Private access to supported AWS services without using public internet paths. |
Security groups vs network ACLs
| Decision point | Security group | Network ACL |
|---|
| Scope | ENI/resource level | Subnet level |
| State | Stateful | Stateless |
| Rule type | Allow only | Allow and deny |
| Return traffic | Automatically allowed | Must be explicitly allowed |
| Common use | Control instance or load balancer traffic | Broad subnet guardrails or explicit deny patterns |
Common candidate mistake: Choosing a network ACL when the question asks for normal application access control. Security groups are the default control for instance-level access.
Public, private, and database subnets
| Workload | Typical placement |
|---|
| Public load balancer | Public subnets across multiple AZs |
| EC2 application servers | Private subnets behind a load balancer |
| RDS database | Private subnets in a DB subnet group |
| NAT Gateway | Public subnet, with private subnets routing outbound internet traffic through it |
| Bastion host, if used | Public subnet, tightly restricted inbound access |
VPC connectivity options
| Need | Good AWS option |
|---|
| Connect VPCs one-to-one | VPC peering |
| Connect many VPCs and on-premises networks centrally | Transit Gateway |
| Private connection from on-premises to AWS | Direct Connect |
| Encrypted tunnel over internet | Site-to-Site VPN |
| Private access to AWS services from VPC | VPC endpoints |
| Private service exposure across VPCs/accounts | AWS PrivateLink |
| Hybrid DNS resolution | Route 53 Resolver endpoints |
Trap: VPC peering is not transitive. If VPC A peers with B and B peers with C, A does not automatically reach C through B.
Route 53, CloudFront, and edge networking
| Service | Use when… |
|---|
| Route 53 | You need DNS, health checks, routing policies, domain registration, or failover routing. |
| CloudFront | You need global content delivery, caching, TLS at the edge, signed URLs/cookies, or lower latency for static/dynamic content. |
| Global Accelerator | You need static anycast IPs and optimized routing to regional endpoints, often for non-HTTP or latency-sensitive apps. |
| AWS WAF | You need web-layer filtering, managed rules, IP sets, or protection against common web exploits. |
| Shield | You need DDoS protection capabilities. |
Route 53 routing policy quick table
| Routing policy | Best fit |
|---|
| Simple | Basic DNS response, no special routing logic |
| Weighted | Split traffic by percentage, such as blue/green or A/B |
| Latency-based | Send users to the Region with lowest latency |
| Failover | Active-passive failover using health checks |
| Geolocation | Route based on user location |
| Geoproximity | Route by geographic proximity, optionally with bias |
| Multivalue answer | Return multiple healthy records |
Compute and load balancing
EC2 purchasing and capacity
| Option | Best fit | Watch for |
|---|
| On-Demand | Short-term, unpredictable workloads | Higher cost than commitment models |
| Reserved Instances | Steady EC2 usage with commitment | Less flexible than On-Demand |
| Savings Plans | Flexible commitment-based savings | Applies depending on plan type and usage |
| Spot Instances | Fault-tolerant, interruptible workloads | Can be interrupted; not ideal for critical single-instance apps |
| Dedicated Hosts | Compliance or licensing requiring physical host visibility/control | Higher cost and management overhead |
| Capacity Reservations | Need capacity assurance in a specific AZ | Does not automatically reduce cost unless combined appropriately |
Auto Scaling
| Feature | Review point |
|---|
| Launch template | Preferred modern way to define EC2 configuration for Auto Scaling. |
| Desired capacity | Target number of instances. |
| Minimum/maximum | Bounds for scaling. |
| Scaling policy | Adds/removes capacity based on metrics or schedules. |
| Health checks | Auto Scaling can replace unhealthy instances. |
| Multi-AZ | Use subnets in multiple AZs for high availability. |
Trap: Auto Scaling improves elasticity and availability, but it does not by itself make a stateful application safe. Store state outside instances, such as in RDS, DynamoDB, EFS, S3, or ElastiCache.
Elastic Load Balancing
| Load balancer | Layer | Use when… |
|---|
| Application Load Balancer | Layer 7 | HTTP/HTTPS routing, host/path rules, containers, WebSockets, target groups |
| Network Load Balancer | Layer 4 | Very high performance TCP/UDP/TLS, static IP needs, low latency |
| Gateway Load Balancer | Layer 3/4 appliance insertion | Deploying third-party virtual appliances like firewalls |
| Classic Load Balancer | Legacy | Usually not the preferred answer for new architectures |
Containers and serverless compute
| Service | Best fit |
|---|
| Lambda | Event-driven serverless functions, short-lived tasks, minimal infrastructure management |
| ECS | Managed container orchestration on AWS |
| EKS | Kubernetes workloads on AWS |
| Fargate | Serverless compute engine for containers; no EC2 management |
| Elastic Beanstalk | Platform management for applications with less infrastructure control |
| App Runner | Simple managed container/web app deployment |
| Batch | Batch jobs, queues, and compute environments |
Decision rule: If the question emphasizes “run containers without managing servers,” look for Fargate. If it emphasizes “Kubernetes,” look for EKS.
Storage review
S3 high-yield concepts
| Feature | What to know |
|---|
| Bucket | Regional container for objects. Bucket names are globally unique. |
| Object | Data plus metadata, addressed by key. |
| Versioning | Preserves multiple versions and helps recover from accidental deletion/overwrite. |
| Lifecycle policies | Move or expire objects based on age/rules to optimize cost. |
| Replication | Copy objects across buckets, often cross-Region or same-Region. |
| S3 Object Lock | Write-once-read-many retention use cases. |
| Block Public Access | Important guardrail against accidental public exposure. |
| Bucket policy | Resource-based access policy for bucket/object permissions. |
| Presigned URL | Time-limited access to a private object. |
| Transfer Acceleration | Faster long-distance uploads using edge locations. |
| Event notifications | Trigger workflows via Lambda, SQS, or SNS. |
S3 storage class selection
| Storage class | Best fit |
|---|
| S3 Standard | Frequently accessed data |
| S3 Intelligent-Tiering | Unknown or changing access patterns |
| S3 Standard-IA | Infrequently accessed data needing rapid access |
| S3 One Zone-IA | Infrequently accessed, re-creatable data stored in one AZ |
| S3 Glacier Instant Retrieval | Archive data needing immediate retrieval |
| S3 Glacier Flexible Retrieval | Archive data with flexible retrieval time |
| S3 Glacier Deep Archive | Lowest-cost long-term archive with slower retrieval |
Common trap: Do not choose One Zone-IA for data that must remain resilient to AZ loss unless the scenario says the data is easily re-created.
EBS, EFS, FSx, and instance store
| Storage | Scope | Best fit |
|---|
| EBS | Block storage for EC2 in one AZ | Boot volumes, databases on EC2, low-latency block storage |
| EFS | Managed NFS file system across AZs | Shared Linux file storage for multiple instances |
| FSx for Windows File Server | Managed Windows file shares | SMB, Windows workloads, Active Directory integration |
| FSx for Lustre | High-performance file system | HPC, analytics, ML, fast processing of large datasets |
| Instance store | Temporary local storage | Ephemeral cache/scratch data; data lost on stop/terminate depending on instance behavior |
Trap: EBS volumes are AZ-scoped. If an EC2 instance needs access in another AZ, snapshots can be used to create a new volume there, but EBS is not a regional shared file system.
Storage decision path
flowchart TD
A[Need storage?] --> B{Object, block, or file?}
B -->|Object| C[S3]
B -->|Block for EC2| D[EBS]
B -->|Shared Linux file| E[EFS]
B -->|Windows file share| F[FSx for Windows File Server]
B -->|HPC fast file processing| G[FSx for Lustre]
C --> H{Access pattern known?}
H -->|Frequent| I[S3 Standard]
H -->|Unknown or changing| J[S3 Intelligent-Tiering]
H -->|Archive| K[S3 Glacier classes]
Databases and caching
Relational database choices
| Service | Best fit |
|---|
| Amazon RDS | Managed relational databases such as MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server |
| Amazon Aurora | AWS-designed relational database compatible with MySQL/PostgreSQL, often chosen for performance, scaling, and managed HA |
| RDS Multi-AZ | High availability and automatic failover |
| RDS read replica | Read scaling and, in some cases, cross-Region read/disaster recovery patterns |
| Aurora Replicas | Read scaling and failover targets within Aurora clusters |
| RDS Proxy | Connection pooling for applications, especially Lambda-heavy relational workloads |
Trap: Multi-AZ is for availability/failover, not read scaling in the usual SAA-C03 decision pattern. Read replicas are for read scaling.
NoSQL and purpose-built databases
| Service | Best fit |
|---|
| DynamoDB | Serverless key-value/document database, high-scale low-latency access |
| DynamoDB global tables | Multi-Region active-active access patterns |
| DynamoDB DAX | In-memory cache for DynamoDB read acceleration |
| ElastiCache for Redis/Memcached | In-memory caching, session stores, low-latency reads |
| MemoryDB for Redis | Durable Redis-compatible in-memory database |
| Redshift | Data warehousing and analytics |
| OpenSearch Service | Search, log analytics, full-text queries |
| Neptune | Graph database |
| DocumentDB | MongoDB-compatible document workloads |
| Timestream | Time series data |
| Keyspaces | Apache Cassandra-compatible workloads |
| QLDB | Ledger database with immutable transaction log |
Database decision rules
| Requirement | Likely answer |
|---|
| SQL, joins, transactions, managed operations | RDS or Aurora |
| Need relational HA across AZs | RDS Multi-AZ or Aurora |
| Scale reads for relational workload | Read replicas |
| Key-value access at massive scale | DynamoDB |
| Microsecond caching layer | ElastiCache |
| Data warehouse reporting | Redshift |
| Search across logs/documents | OpenSearch Service |
| Graph relationships | Neptune |
| Immutable verifiable ledger | QLDB |
Security, identity, and encryption
IAM essentials
| Concept | Review point |
|---|
| IAM user | Long-term identity; avoid for applications when roles are possible. |
| IAM group | Collection of users; permissions management for users. |
| IAM role | Assumable identity with temporary credentials; preferred for AWS services. |
| IAM policy | JSON permissions document. |
| Identity-based policy | Attached to users, groups, or roles. |
| Resource-based policy | Attached to resources such as S3 buckets, KMS keys, SQS queues, or Lambda functions. |
| STS | Provides temporary security credentials. |
| Least privilege | Grant only required actions on required resources. |
| MFA | Stronger authentication, especially for privileged access. |
Common trap: Applications running on EC2 should usually use an IAM role attached to the instance profile, not stored access keys.
AWS Organizations controls
| Feature | Use |
|---|
| AWS Organizations | Central account management |
| Organizational units | Group accounts by function, environment, or governance boundary |
| Service control policies | Set maximum available permissions for accounts/OUs |
| Consolidated billing | Centralized billing across accounts |
Trap: An SCP does not grant permissions. It only limits what can be granted by identity/resource policies.
KMS and secrets
| Need | Service or feature |
|---|
| Managed encryption keys | AWS KMS |
| Customer-managed key policies and rotation control | KMS customer managed keys |
| Store and rotate database credentials | AWS Secrets Manager |
| Store configuration parameters and simple secrets | Systems Manager Parameter Store |
| Encrypt S3 objects | SSE-S3, SSE-KMS, or client-side encryption depending on requirements |
| Encrypt EBS volumes | EBS encryption using KMS |
| Encrypt RDS | RDS encryption using KMS, generally chosen at creation or via snapshot workflows |
Logging and detection
| Service | Use |
|---|
| CloudTrail | API activity and account governance audit trail |
| CloudWatch | Metrics, logs, alarms, dashboards |
| AWS Config | Resource configuration history, compliance rules |
| GuardDuty | Threat detection using logs and behavior analysis |
| Security Hub | Central security findings and posture management |
| Inspector | Vulnerability management for supported workloads |
| Macie | Sensitive data discovery in S3 |
| IAM Access Analyzer | Analyze external access and policy findings |
Trap: CloudWatch is not the same as CloudTrail. CloudWatch monitors metrics/logs; CloudTrail records API activity.
Application integration and decoupling
Messaging and event services
| Service | Best fit |
|---|
| SQS Standard queue | Decouple producers/consumers with high throughput and at-least-once delivery |
| SQS FIFO queue | Ordered processing and exactly-once processing behavior within FIFO design constraints |
| SNS | Pub/sub fanout to subscribers |
| EventBridge | Event bus, SaaS/AWS service events, routing by event patterns |
| Kinesis Data Streams | Real-time streaming data ingestion and custom consumers |
| Kinesis Data Firehose | Load streaming data into destinations like S3, Redshift, OpenSearch, or third-party services |
| Step Functions | Orchestrate workflows and stateful business processes |
| Amazon MQ | Managed message broker for protocols/apps needing broker compatibility |
SQS review points
| Feature | Meaning |
|---|
| Visibility timeout | Time a message is hidden after a consumer receives it. Set long enough for processing. |
| Dead-letter queue | Captures messages that fail repeatedly. |
| Long polling | Reduces empty responses and cost. |
| Delay queue/message timer | Postpones message availability. |
| FIFO queue | Ordering and deduplication use cases. |
Common trap: If one message must be delivered to many subscribers, use SNS fanout, not a single SQS queue with multiple competing consumers.
Reliability and disaster recovery patterns
High-availability patterns
| Requirement | Architecture pattern |
|---|
| Web app highly available across AZs | ALB across public subnets, EC2 Auto Scaling across private subnets |
| Managed relational DB failover | RDS Multi-AZ or Aurora |
| Stateless application tier | Store sessions externally, use Auto Scaling |
| Static content high availability | S3 with CloudFront |
| Queue-based workload resilience | SQS plus Auto Scaling consumers and DLQ |
| Global failover | Route 53 health checks and failover routing, or appropriate multi-Region design |
Disaster recovery approaches
| Pattern | Review meaning |
|---|
| Backup and restore | Lowest cost, slower recovery |
| Pilot light | Minimal critical core running, scale up during disaster |
| Warm standby | Scaled-down full environment ready to expand |
| Multi-site active-active | Multiple active environments, fastest recovery, highest complexity/cost |
Exam decision rule: If the question asks for the lowest cost DR option and can tolerate slower recovery, backup and restore is usually favored. If it asks for very fast recovery, warm standby or active-active may be more appropriate.
Migration, hybrid, and data transfer
| Need | AWS service |
|---|
| Database migration with minimal downtime | AWS Database Migration Service |
| Convert database schema between engines | AWS Schema Conversion Tool |
| Transfer large datasets online | AWS DataSync |
| SFTP/FTPS/FTP managed endpoints | AWS Transfer Family |
| Offline bulk data transfer | AWS Snow Family |
| Hybrid storage integration | AWS Storage Gateway |
| Discover on-premises inventory | AWS Application Discovery Service |
| Rehost servers to AWS | AWS Application Migration Service |
| Central backup management | AWS Backup |
Storage Gateway types
| Type | Use |
|---|
| File Gateway | File interface to S3-backed storage |
| Volume Gateway | Block storage with cached or stored volume patterns |
| Tape Gateway | Virtual tape replacement for backup workflows |
Monitoring, operations, and governance
| Service | High-yield use |
|---|
| CloudWatch Alarms | Alert or trigger actions based on metrics |
| CloudWatch Logs | Centralize application/system logs |
| CloudWatch Logs Insights | Query logs |
| X-Ray | Trace distributed applications |
| Systems Manager | Patch, run commands, manage inventory, Session Manager access |
| AWS Backup | Central backup policies across supported services |
| Trusted Advisor | Recommendations across cost, security, fault tolerance, performance, and service limits |
| Service Quotas | View/request quota increases |
| Health Dashboard | AWS service events and account-specific health |
| Control Tower | Multi-account landing zone governance |
Trap: For secure shell access without opening inbound SSH, Systems Manager Session Manager is often a better answer than a bastion host, assuming prerequisites are met.
Cost optimization review
Cost levers
| Area | Review actions |
|---|
| Compute | Right-size instances, use Auto Scaling, Savings Plans/Reserved Instances for steady usage, Spot for interruptible workloads |
| Storage | Choose correct S3 storage class, lifecycle old data, delete unused EBS volumes/snapshots |
| Databases | Select appropriate engine, use read replicas only when needed, scale capacity to workload |
| Networking | Watch NAT Gateway data processing, cross-AZ traffic, data transfer out, and unnecessary public paths |
| Monitoring | Set budgets, alarms, and cost allocation tags |
| Architecture | Prefer managed/serverless where it reduces idle capacity and operations |
| Tool | Use |
|---|
| AWS Budgets | Track spend or usage against thresholds |
| Cost Explorer | Analyze historical cost and usage |
| Cost and Usage Reports | Detailed billing data for analysis |
| Compute Optimizer | Rightsizing recommendations for supported resources |
| Pricing Calculator | Estimate architecture costs before deployment |
Common trap: “Cheapest” is not always “best.” If the scenario requires high availability, durability, or compliance, avoid options that save money by violating stated requirements.
High-yield service comparison tables
S3 vs EBS vs EFS
| Requirement | Choose |
|---|
| Store images, backups, logs, static assets | S3 |
| Boot volume for EC2 | EBS |
| Block storage for database on EC2 | EBS |
| Shared POSIX file system across Linux EC2 instances | EFS |
| Long-term archive | S3 Glacier storage classes |
| Temporary scratch data tied to an instance | Instance store |
ALB vs NLB vs CloudFront
| Requirement | Choose |
|---|
| Path-based or host-based HTTP routing | ALB |
| TCP/UDP, extreme performance, static IP support | NLB |
| Global caching and edge delivery | CloudFront |
| Web application firewall at edge or ALB | AWS WAF with CloudFront or ALB |
| Fixed global entry IPs with regional endpoints | Global Accelerator |
SQS vs SNS vs EventBridge vs Kinesis
| Requirement | Choose |
|---|
| Buffer work between producers and consumers | SQS |
| Fanout notifications to multiple subscribers | SNS |
| Event routing from AWS/SaaS/custom apps | EventBridge |
| Ordered high-volume streaming analytics | Kinesis Data Streams |
| Load streaming data into S3/Redshift/OpenSearch | Kinesis Data Firehose |
| Coordinate multi-step workflow | Step Functions |
RDS Multi-AZ vs read replica
| Requirement | Choose |
|---|
| Automatic failover for relational DB | Multi-AZ |
| Scale read traffic | Read replica |
| Cross-Region read locality | Cross-Region read replica where supported |
| Improve write scaling | Usually not read replicas; consider architecture/database choice |
| Reduce admin for connection storms | RDS Proxy |
Common SAA-C03 traps
Trap 1: Ignoring “managed” and “least operational overhead”
If two answers work technically, the exam often favors the one with less administration when the scenario requests minimal operations.
| Less optimal | Often better |
|---|
| Self-managed MySQL on EC2 | RDS or Aurora |
| EC2 fleet for event functions | Lambda |
| EC2-hosted queue/broker without need | SQS, SNS, EventBridge, or Amazon MQ depending on requirement |
| Manual scaling | Auto Scaling or serverless scaling |
Trap 2: Confusing HA with scalability
| Design goal | Meaning |
|---|
| High availability | Survive failure and remain accessible |
| Scalability | Handle increased load |
| Elasticity | Automatically scale up/down |
| Durability | Preserve data |
An Auto Scaling group may improve both availability and scalability, but an RDS read replica mostly improves read scalability, while Multi-AZ improves availability.
Trap 3: Choosing public access when private access is required
If the question asks for private connectivity to AWS services, consider:
- VPC gateway endpoints for supported services such as S3 and DynamoDB
- VPC interface endpoints powered by PrivateLink for many AWS services
- Private subnets with no direct inbound internet route
- Direct Connect or VPN for hybrid connectivity
Trap 4: Misreading “real-time”
“Real-time” can point to different services:
| Scenario | Likely service |
|---|
| Streaming click events for custom consumers | Kinesis Data Streams |
| Deliver streaming data into S3 | Kinesis Data Firehose |
| Pub/sub application notification | SNS |
| Event routing between applications | EventBridge |
| Queue-based background processing | SQS |
Trap 5: Overusing Multi-Region
Multi-Region designs can improve disaster recovery and latency but add cost and complexity. If the question only requires high availability within a Region, Multi-AZ is often enough.
Trap 6: Forgetting state
Stateless compute is easier to scale and replace. Store state in managed external services:
| State type | Common service |
|---|
| User sessions | ElastiCache, DynamoDB, application-managed external store |
| Uploaded files | S3 |
| Shared application files | EFS or FSx |
| Relational data | RDS or Aurora |
| Key-value data | DynamoDB |
Fast final-review checklist
Before answering an SAA-C03 scenario question, ask:
- What is the primary requirement? Cost, availability, security, performance, or operational simplicity?
- Is the workload stateful or stateless?
- Does it need relational features, key-value scale, file storage, object storage, or block storage?
- Is traffic synchronous, queued, pub/sub, event-driven, or streaming?
- Is the architecture single-AZ, Multi-AZ, or Multi-Region?
- Does the question require private connectivity or public access?
- Can a managed or serverless service reduce operational overhead?
- Are there hidden cost drivers such as idle capacity, cross-AZ transfer, NAT processing, or overprovisioned storage?
- Does the proposed answer satisfy every stated constraint, not just one?
- Does any answer add unnecessary complexity?
Practice connection
Use this Quick Review as a final concept pass, then move into IT Mastery practice with original practice questions. The fastest way to improve for AWS Certified Solutions Architect – Associate (SAA-C03) is to test service selection under realistic constraints:
- Start with focused topic drills on weak areas such as VPC networking, S3 storage classes, RDS vs DynamoDB, IAM/KMS, and decoupling.
- Review detailed explanations for both correct and incorrect answers.
- Track repeated mistakes by decision type, not just by service name.
- Then use timed mock exams to practice reading scenario wording quickly.
Next step: choose one weak domain, complete a short question bank drill, and review every explanation until you can state why the best answer is better than the plausible distractors.
Continue in IT Mastery
Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official AWS questions, copied live-exam content, or exam dumps.