SAA-C03 - AWS Certified Solutions Architect Associate Cheat Sheet

🎯Take a practice test on this topic7 practice tests · 318 questions→

The AWS Certified Solutions Architect - Associate certification is earned by passing a single exam, SAA-C03, the current in-force version. This sheet covers all four scored domains end to end: Design Secure Architectures (30%), Design Resilient Architectures (26%), Design High-Performing Architectures (24%), and Design Cost-Optimized Architectures (20%). SAA-C03 is a design exam, not a hands-on one: almost every question is a scenario that states business and technical requirements (cost, scale, availability, latency, RPO/RTO, compliance) and asks you to choose the AWS service or pattern that best fits, so the tested skill is matching requirement to service and knowing why the close alternatives are wrong. The reflexes AWS rewards: follow the shared responsibility model and least privilege, prefer the most-managed (serverless or managed) option that still meets every stated constraint, decouple components so they scale and fail independently, design across multiple Availability Zones for high availability and across Regions for disaster recovery, and match the scope of the solution to the requirement. Learn the commonly-confused pairs in each table (SCP vs IAM policy, security group vs network ACL, SQS vs SNS vs EventBridge, ALB vs NLB vs GLB, Multi-AZ vs read replica, EBS vs EFS vs S3, CloudFront vs Global Accelerator, Spot vs Reserved vs Savings Plans) and you can answer most items by elimination.

What This Cheat Sheet Covers

This topic spans 22 focused tables and 252 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Design IAM Identities and PoliciesTable 2: Design Multi-Account, Federation, and Cross-Account AccessTable 3: Design Secure VPC Network ArchitectureTable 4: Secure Applications, Edge, and External ConnectionsTable 5: Encryption and Key ManagementTable 6: Data Governance, Backup, and LifecycleTable 7: Decoupling, Messaging, and Event-Driven ArchitecturesTable 8: Serverless, Containers, and MicroservicesTable 9: Multi-Tier, Load Balancing, Caching, and APIsTable 10: High Availability and Multi-AZ/Region PatternsTable 11: Disaster Recovery Strategies (RPO/RTO)Table 12: Durability, Proxies, Quotas, and Resilience ToolingTable 13: High-Performing Storage SolutionsTable 14: High-Performing and Elastic ComputeTable 15: High-Performing Database SolutionsTable 16: High-Performing and Scalable Network ArchitecturesTable 17: Data Streaming, Ingestion, and TransferTable 18: Data Lakes, Analytics, and TransformationTable 19: Cost-Optimized Storage SolutionsTable 20: Cost-Optimized Compute SolutionsTable 21: Cost-Optimized Database SolutionsTable 22: Cost-Optimized Network Architectures

Table 1: Design IAM Identities and Policies

SAA-C03 Domain 1 (Design Secure Architectures), Task 1.1: design secure access to AWS resources. This slice covers the IAM authorization model (users, groups, roles, policies), root-user and MFA best practices, least privilege, the shared responsibility model, and when to use resource-based policies.

Concept	Example	Description
Shared Responsibility Model	AWS patches the hypervisor; you patch the EC2 guest OS and configure IAM	AWS secures "of the cloud" (hardware, virtualization, facilities); the customer secures "in the cloud" (guest OS, data, encryption, IAM configuration). An IAM misconfiguration is the customer's responsibility, not AWS's.
Account Root User	Use root only to change account settings, then switch to an admin IAM identity	The single sign-in identity created with the account, with full access to every service and to billing. AWS says lock it away, enable MFA, and do NOT create root access keys. Use it only for the few root-only tasks.
Multi-Factor Authentication (MFA)	Password plus a code from a passkey, security key, or TOTP authenticator app	A second sign-in factor beyond the password. AWS strongly recommends MFA on the root user and on any IAM user, and prefers phishing-resistant passkeys or FIDO security keys.
IAM Users	An identity with a console password and long-term access keys	An identity for one person or application that carries long-term credentials. AWS recommends using them only when roles or federation cannot be used (for example legacy clients or break-glass access).
IAM User Groups	Attach `AdministratorAccess` to a `Developers` group; add and remove users	A collection of IAM users so you attach policies once and manage human permissions by membership. A group is not an identity, so it cannot be a Principal and cannot be assumed.
IAM Roles	An EC2 instance profile lets the app call S3 with auto-rotated temporary credentials	An identity assumable by anyone who needs it, with no long-term credentials; assuming it returns temporary credentials. AWS's preferred way to give workloads and cross-service access.

Table 1: Design IAM Identities and Policies

Concept	Example	Description
Shared Responsibility Model	AWS patches the hypervisor; you patch the EC2 guest OS and configure IAM	AWS secures "of the cloud" (hardware, virtualization, facilities); the customer secures "in the cloud" (guest OS, data, encryption, IAM configuration). An IAM misconfiguration is the customer's responsibility, not AWS's.
Account Root User	Use root only to change account settings, then switch to an admin IAM identity	The single sign-in identity created with the account, with full access to every service and to billing. AWS says lock it away, enable MFA, and do NOT create root access keys. Use it only for the few root-only tasks.
Multi-Factor Authentication (MFA)	Password plus a code from a passkey, security key, or TOTP authenticator app	A second sign-in factor beyond the password. AWS strongly recommends MFA on the root user and on any IAM user, and prefers phishing-resistant passkeys or FIDO security keys.
IAM Users	An identity with a console password and long-term access keys	An identity for one person or application that carries long-term credentials. AWS recommends using them only when roles or federation cannot be used (for example legacy clients or break-glass access).
IAM User Groups	Attach `AdministratorAccess` to a `Developers` group; add and remove users	A collection of IAM users so you attach policies once and manage human permissions by membership. A group is not an identity, so it cannot be a Principal and cannot be assumed.
IAM Roles	An EC2 instance profile lets the app call S3 with auto-rotated temporary credentials	An identity assumable by anyone who needs it, with no long-term credentials; assuming it returns temporary credentials. AWS's preferred way to give workloads and cross-service access.