RoleMath Study Track · free study companion
A free study companion keyed to the officially published exam domains of AWS Certified Solutions Architect – Associate (SAA-C03): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. AWS Certified Solutions Architect – Associate (SAA-C03) exam guide
A free, source-cited study companion built on AWS's published SAA-C03 exam guide — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Not sure which domain to start with? Take the readiness check on the cert page →
Program blueprint under review
A free SAA-C03 program blueprint that turns secure, resilient, high-performing, and cost-optimized AWS design into explicit requirements, alternatives, failure analysis, validation, and decision evidence through a no-account route without claiming instructional completeness or an exam, job, savings, or availability outcome.
This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.
Choose an outcome
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Learners who have selected SAA-C03 and need one design-reasoning sequence across all four current domains.
Completion emphasis: Complete all modules and no-account or controlled labs, the official Skill Builder plan where free, the architecture-review capstone, and a final objective gap review.
Cloud learners and practitioners who want reviewable evidence of requirements, service alternatives, security ownership, failure analysis, performance, cost, operations, migration, validation, and rollback reasoning.
Completion emphasis: Retain architecture views, decision records, threat/responsibility matrix, failure model, performance plan, cost scenarios, operations evidence, migration/rollback plan, and review findings.
Learners deciding whether translating ambiguous requirements into cloud tradeoffs and reviewable architecture decisions fits their interests and current foundation.
Completion emphasis: Complete the diagnostic, secure-boundary map, Multi-AZ failure redesign, scale-up/scale-out estimate, and cost tradeoff; record whether to continue, bridge cloud foundations, or choose a more operational route.
Start safely
Verify cloud foundation, architecture reasoning, account/cost safety, and evidence practices before associate-level design work; this is not an AWS prerequisite or exam prediction.
Ready when: Yes, with service categories understood before product-specific design.
If not yet: Bridge through Cloud Practitioner or equivalent cloud foundations before treating SAA-C03 as the next exam target.
Ready when: Yes, and every recommendation will record alternatives and conditions that would change it.
If not yet: Complete the requirement-to-decision warm-up and avoid product memorization as a substitute for architecture reasoning.
Ready when: Either route is valid; no live account is required for full program completion.
If not yet: Use official documentation, diagrams, expected-state tables, and Pricing Calculator without creating an AWS account.
Ready when: Yes, with read-only inspection and no default-VPC or security-rule creation required.
If not yet: Use the no-account architecture route; do not create or modify a VPC, subnet, route, security group, load balancer, instance, database, or other resource.
Ready when: Yes, or you will complete the failure-mode warm-up before Multi-AZ design.
If not yet: Practice writing failure, impact, detection, mitigation, recovery, verification, and residual risk for a simple two-component system.
Ready when: Yes, with calculator output treated as planning evidence, not a bill or guarantee.
If not yet: Use a structured assumption log before presenting any price, capacity, latency, availability, RTO, RPO, or savings statement.
Plan, then adapt
12 weeks 8-12 hours/week
A planning estimate for learners moving beyond cloud fundamentals: give each design domain several requirement, diagram, calculator, and review sessions before integration.
8 weeks 12-16 hours/week
A planning estimate that covers one design domain most weeks and reserves two weeks for the integrated architecture review, migration plan, validation, and gaps.
5 weeks 18-22 hours/week
For learners with existing AWS architecture or implementation experience; do not compress unfamiliar service, failure, security, cost, operations, or migration tradeoffs.
Evidence-gated sequence
Pin SAA-C03, assess cloud/design foundations, select no-account or read-only practice, and establish requirements, assumptions, decision, cost, and review records.
Design least privilege, data protection, trusted paths, network segmentation, secure service access, monitoring, and shared-responsibility controls from explicit requirements.
Modules: Design Secure Architectures
Eliminate unjustified single points of failure, model component/dependency failures, and select availability, backup, replication, failover, decoupling, and recovery patterns with explicit assumptions.
Modules: Design Resilient Architectures
Select compute, storage, database, network, caching, integration, and scaling patterns from measured or assumed workload behavior while preserving security and resilience.
Modules: Design High-Performing Architectures
Estimate the complete design, identify cost drivers, match pricing and storage models to usage, right-size safely, and define cost controls without breaking requirements.
Modules: Design Cost-Optimized Architectures
Integrate requirements, alternatives, security, resilience, performance, cost, operations, migration, validation, rollback, and decision communication into one auditable fictional architecture review.
Modules: Design Secure Architectures, Design Resilient Architectures, Design High-Performing Architectures, Design Cost-Optimized Architectures
Before a lab
Show your work
Completing this policy demonstrates SAA-C03 coverage and no-account architecture practice inside RoleMath; it does not predict a score, guarantee architecture quality/savings/availability, or establish professional cloud-architect experience.
Integrated practice
Redesign a fragile fictional single-zone event platform into a secure, resilient, performant, cost-aware, operable AWS architecture and produce the evidence, migration, validation, rollback, and decision records needed for review across all four SAA-C03 domains.
Safety boundary: The complete capstone is no-account design and tabletop work. Optional AWS console observation must remain read-only in a personally controlled secured account and create or change nothing. Do not launch services, modify networks/security, upload data, run load/failure tests, or expose credentials, account IDs, billing, or real organizational architecture. Treat estimates and targets as assumptions, not guarantees.
Finish honestly
Present the packet as self-directed SAA-C03 architecture lab work. Do not call it a production architecture, AWS approval, guaranteed cost/performance/availability, professional cloud-architect experience, or a RoleMath credential.
Objective source checked 2026-07-10. Recheck objectives every 30 days and resources every 60 days.
The official objective domains and their exam weight — titles & weights only, straight from the vendor’s exam objectives. AWS Certified Solutions Architect – Associate (SAA-C03) exam guide
Our default advice is to study the heaviest-weighted domain first, because the published weights tell you where the exam spends its questions. For the Solutions Architect – Associate exam the published weights already run in descending order, so weight-first and outline order happen to agree: Design Secure Architectures (30%) first, then Design Resilient Architectures (26%), Design High-Performing Architectures (24%), and Design Cost-Optimized Architectures (20%). There is a design logic to that order too. Security is the widest lens — identity, network boundaries, and encryption touch every later topic — so establishing it first means the resilience, performance, and cost domains all read against a security backdrop you already understand. Resilience comes next because 'what happens when a component fails' is the question that most shapes an architecture. Performance and cost then become tuning decisions layered on a design that is already secure and durable. This is sequencing advice based on the published weights and how the topics build on each other, not a claim about the science of learning — if a different order fits how you think, use it. Unlike the Cloud Practitioner exam, SAA rewards genuine design reasoning, so expect to spend real time turning each domain's ideas into judgment about trade-offs, not just recognition of terms.
Module 1 of 4 · domain 1 · 30% of the exam
Start here — it is the heaviest domain at 30% and the widest lens on the exam. Identity, network boundaries, and encryption reappear inside every other domain, so time spent here pays off three more times as you study resilience, performance, and cost.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. AWS Certified Solutions Architect – Associate (SAA-C03) exam guide
This is the 'who is allowed to do what, and how do you keep data and networks protected' domain, and at 30% it is the largest single slice of the Solutions Architect – Associate exam. It is worth being clear about how it differs from the security material on the entry-level Cloud Practitioner exam: there, you recognized security concepts and named the right control. Here, you are asked to design — to look at a described system and choose an identity model, a network layout, and an encryption approach that hold together as a whole. The exam is testing architectural judgment about security, not memory of service names.
The spine of the domain is identity and access management done at design scale. You still start from least privilege — granting each identity only the access it genuinely needs — but as an architect you decide the shape of the whole access model. The key move is designing with roles instead of long-lived credentials: an IAM role hands out temporary, automatically expiring permissions that a service, an application, or a federated user assumes when it needs them, so there are no static keys to leak. The exam repeatedly favors this pattern — an EC2 instance that needs to read a storage bucket should assume a role, not carry an embedded access key. You also design how outside identities get in: rather than creating a login per person, you federate an existing corporate directory or identity provider so people use credentials they already have, and you centralize guardrails across many accounts so no single team can grant itself more than policy allows.
The second pillar is network security — designing the boundaries data moves within. The private virtual network (the VPC) is the canvas: inside it you place subnets, and the crucial design decision is public versus private. Resources that must be reachable from the internet (a load balancer, say) sit in public subnets; databases and application servers that should never be directly exposed sit in private subnets and reach the internet only outbound, through a controlled gateway, if at all. Two layers of filtering enforce this: security groups act as stateful firewalls attached to individual resources, allowing specific inbound and outbound traffic, while network ACLs act as a coarser, stateless filter at the subnet edge. The architect's instinct the exam rewards is to expose the minimum — put nothing in a public subnet that does not need to be there, and let each tier talk only to the tier it must.
The third pillar is protecting data itself, in two states. Encryption at rest scrambles stored data so a stolen disk or snapshot is useless without the key; on AWS this is designed around a key-management service that creates, stores, and controls access to encryption keys, and most storage and database services can be told to encrypt with a key you govern. Encryption in transit protects data as it crosses the network, typically with TLS, so it cannot be read if intercepted. The design skill is knowing that these are largely configuration choices you make deliberately — turning on encryption for a bucket, a volume, or a database, and deciding who is allowed to use the key — rather than afterthoughts. Managing secrets (passwords, API keys) through a dedicated secrets service, instead of hard-coding them, belongs to the same instinct: never let sensitive material sit in plaintext where it can leak.
Tying the three pillars together is a defense-in-depth mindset: no single control is trusted to be enough, so you layer them. A well-designed system might keep its database in a private subnet (network layer), reachable only by the application's security group (resource firewall), authenticated by an IAM role rather than a password (identity layer), with its storage encrypted by a governed key (data layer) — so that a failure or misconfiguration in any one layer does not by itself expose the data. The exam loves scenarios where you must spot the weakest layer or add the missing one. It also expects you to design for visibility: logging API activity and monitoring for anomalies so that if something does go wrong, there is an audit trail and an alert rather than silence.
Study this domain by redesigning systems you already understand through a security lens: for any application, ask where each component should sit (public or private subnet), how each part should prove its identity (role, not key), what data must be encrypted and who holds the key, and which layer you would be most embarrassed to have left open. The account-free worksheet below turns those network-boundary ideas into a requirements-to-control evidence packet. Read the official SAA-C03 exam guide for AWS's authoritative published scope, domain weights, and task statements; AWS notes that the guide is not a comprehensive list of every exam topic, and this explanation deliberately paraphrases rather than reproduces it.
Turn a fictional workload's requirements into identity, network, encryption, secrets, and logging boundaries without embedding credentials or granting broad access Adversarially review a layered security design, identify its weakest unverified control, and retain a requirements-to-control evidence packet
Confirm the packet contains at least five requirements, all named boundaries, seven control rows with verification, five adversarial answers, and one revision without real credentials or organization data.
Practice evidence maps to exam_domain_aws_solutions_architect_associate_01
Stay safe & legal: Work only with the RoleMath fictional scenario, learner-owned local files, and public AWS documentation; no cloud account or external system is in scope. Account required: no; payment required: no; maximum designed cost: $0.
4RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 2 of 4 · domain 2 · 26% of the exam
Second in our suggested order, matching its 26% weight. Study it after security: resilience is about surviving failure, and the single most important resilience decision — spreading a workload across Availability Zones — builds directly on the subnet-and-zone map you inspected in Domain 1.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. AWS Certified Solutions Architect – Associate (SAA-C03) exam guide
This is the 'what happens when something breaks, and how do you keep running anyway' domain, and at 26% it is the second-largest slice of the exam. Resilience is arguably the heart of what a solutions architect does: the guiding assumption is that any single component will eventually fail, so you design so that no single failure takes the whole system down. The exam is dense with scenarios that describe an outage — an instance dies, a data center loses power, a region becomes unreachable — and ask you to choose the design that survives it. Getting comfortable with 'assume it fails, then remove the single point of failure' is the mindset to build here.
The most important resilience concept on AWS is the Availability Zone. A Region is divided into multiple Availability Zones — physically separate data-center clusters with independent power and networking, close enough to replicate data quickly but isolated enough that one failing does not take the others with it. The foundational design pattern, which the exam returns to constantly, is Multi-AZ: run your workload in at least two zones so that if one zone fails, the other keeps serving. A managed database configured for Multi-AZ, for example, keeps a synchronized standby copy in a second zone and fails over to it automatically. When a scenario says 'high availability' or 'survive a data-center failure', the answer almost always involves spreading across Availability Zones.
Sitting on top of the zone concept are the two services that make a stateless tier self-healing: load balancers and auto scaling. A load balancer spreads incoming traffic across many instances in multiple zones and stops sending traffic to any instance that fails its health check, so a dead instance is quietly bypassed rather than serving errors. Auto scaling groups keep a target number of instances running: if one fails or a whole zone drops out, the group launches replacements in a healthy zone automatically, and it can also add and remove instances as load changes. Together they turn a fixed set of servers into a fleet that repairs itself — the exam expects you to reach for this pairing whenever a workload must stay available without someone watching it by hand.
Resilience also comes from decoupling — designing components so they do not depend on each other being healthy at the same instant. The classic tools are queues and notification services that sit between parts of a system: instead of a web tier calling a processing tier directly (so that if the processor is down, requests are lost), the web tier drops messages onto a queue, and the processor pulls from the queue whenever it is ready. If the processor fails, messages wait safely in the queue instead of disappearing, and when it recovers it catches up. This loose coupling means a slow or failed component degrades gracefully rather than cascading. The exam rewards recognizing when a tightly coupled, synchronous design should be broken apart with a queue or an event-driven pattern to make it fault-tolerant.
Beyond a single Region, the domain reaches into data durability and disaster recovery. Object storage is designed for very high durability by replicating data across zones automatically, and you make data more resilient still with backups, snapshots, and versioning so that a deletion or corruption can be undone. For rare but serious events — a whole Region becoming unavailable — architects design disaster-recovery strategies that trade cost against recovery speed: at one end, simply backing data up to another Region and rebuilding slowly if needed; at the other, running a fully live copy in a second Region ready to take over in seconds. The exam wants you to match a stated recovery requirement (how much data loss and downtime is acceptable) to the appropriately sized strategy, understanding that faster recovery costs more to keep warm.
Study this domain by taking any architecture and playing 'kill the component': for each piece, ask what happens if it dies, and redesign until no single death is fatal — add a second zone, put a load balancer and auto scaling in front, insert a queue between tightly coupled tiers, add backups and cross-Region copies for the data. The account-free tabletop below makes those choices explicit in failure, recovery, and evidence rows. Read the official SAA-C03 exam guide for AWS's authoritative published scope, domain weights, and task statements; AWS notes that the guide is not a comprehensive list of every exam topic.
Build a failure-mode matrix that distinguishes availability, durability, backup, replication, scaling, and failover for a fictional multi-tier workload Run two account-free tabletop scenarios and retain detection, recovery, validation, rollback, residual-risk, owner, and tradeoff decisions
Confirm all eight failure rows and both scenarios include detection, mitigation/recovery, evidence or validation, rollback where relevant, and residual risk using fictional values only.
Practice evidence maps to exam_domain_aws_solutions_architect_associate_02
Stay safe & legal: This is a tabletop using a fictional RoleMath workload, learner-owned local files, and public documentation; no live system or failure injection is authorized. Account required: no; payment required: no; maximum designed cost: $0.
5RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 3 of 4 · domain 3 · 24% of the exam
Third in our suggested order, matching its 24% weight. Study it after resilience: performance choices — caching, scaling, picking the right storage or database — assume the secure, multi-zone foundation the first two domains established, and layer speed on top of it.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. AWS Certified Solutions Architect – Associate (SAA-C03) exam guide
This is the 'how do you make it fast and keep it fast as load grows' domain, and at 24% it is a substantial slice of the exam. Where resilience asks how a system survives failure, performance asks how it stays responsive under load — and the two are related, because the same elasticity that lets a system heal also lets it scale. The exam presents workloads with performance pressure (a spike in users, a slow database, latency for distant customers) and asks you to choose the design that meets it efficiently. The recurring skill is picking the right tool and the right scaling strategy for a described access pattern, rather than throwing bigger hardware at every problem.
The first idea to internalize is the difference between scaling up and scaling out. Scaling up (vertical scaling) means moving to a larger, more powerful instance — simple, but bounded by the biggest machine available and a single point of failure. Scaling out (horizontal scaling) means adding more instances and spreading work across them — the cloud-native default, because it has almost no ceiling and pairs naturally with the load balancing and auto scaling from the resilience domain. The exam strongly favors designs that scale out and adjust automatically to demand, so that capacity tracks load instead of being sized for a peak that is idle most of the time. When a scenario describes unpredictable or spiky traffic, the high-performing answer is almost always elastic, horizontal, and automatic.
Caching is the highest-leverage performance tool, and the domain treats it at several layers. A content delivery network caches static content (images, files, whole pages) at edge locations physically close to users, so a visitor in another part of the world is served from nearby instead of waiting on a round trip to the origin — the standard answer to 'reduce latency for a global audience'. Closer to the application, an in-memory cache stores the results of expensive database queries or computations so repeated requests are answered from fast memory instead of hitting the database every time, which both speeds responses and relieves load on the data tier. The exam wants you to recognize where a cache belongs: static assets at the edge, hot query results in memory in front of the database.
Choosing the right storage and database for the access pattern is the domain's largest theme, because a mismatch is a common and expensive performance mistake. On storage, object storage suits large files and static content served or archived at scale, block storage (disk-like volumes) suits databases and applications that need low-latency random access, and shared file storage suits many machines needing the same files — and within these, different performance tiers trade speed for cost. On databases, the split is relational versus non-relational: a managed relational database fits structured, related data with complex queries, while a non-relational database is built for massive scale, high request rates, and flexible data shapes with predictable low latency. Read-heavy relational workloads can add read replicas to spread query load. The exam repeatedly asks you to match a described data pattern — huge scale and simple lookups, or rich relational queries, or shared files, or streaming media — to the storage or database designed for it.
Underlying all of this is a decoupled, elastic mindset that lets each part scale independently. Serverless compute that runs only when an event fires scales automatically from zero to very high volume without you managing servers, which fits spiky or event-driven workloads well. Queues and streaming services absorb bursts so a downstream component is not overwhelmed, smoothing spikes into a steady flow the system can handle. Designing tiers that can each scale on their own — web, application, and data — means you add capacity exactly where the bottleneck is rather than scaling everything at once. The exam rewards recognizing the bottleneck in a scenario and applying the narrowest effective fix: cache the repeated reads, add replicas for read load, put a queue in front of a burst, scale out the tier that is actually saturated.
Study this domain by profiling systems in your head: for any workload, ask where the latency and load actually are, what the access pattern looks like (read-heavy or write-heavy, structured or flexible, global or local), and what the smallest change is that would relieve the real bottleneck. The account-free decision-matrix lab below compares alternatives only after workload, capacity, latency, and reversal assumptions are normalized. Read the official SAA-C03 exam guide for AWS's authoritative published scope, domain weights, and task statements; AWS notes that the guide is not a comprehensive list of every exam topic.
Profile a fictional workload's traffic, concurrency, data, latency, background work, geography, and growth before selecting compute, storage, database, cache, integration, and network patterns Create a safe validation plan and revise architecture choices when five workload assumptions change, without claiming an unrun benchmark passed
Confirm all eight workload and decision rows, the validation plan, and five changed-assumption answers are complete, use fictional values, and label planned tests separately from observed results.
Practice evidence maps to exam_domain_aws_solutions_architect_associate_03
Stay safe & legal: Use only the fictional RoleMath workload, learner-owned local files, and public documentation; no load test, cloud account, or external target is authorized. Account required: no; payment required: no; maximum designed cost: $0.
4RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 4 of 4 · domain 4 · 20% of the exam
Last in our suggested order, per its 20% weight — the lightest domain, and the most concrete. It reads best at the end because cost optimization is a lens you apply to designs you already know how to make secure, resilient, and fast: now you make them affordable without breaking those properties.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. AWS Certified Solutions Architect – Associate (SAA-C03) exam guide
This is the 'how do you deliver the same secure, resilient, fast design for less money' domain, and at 20% it is the lightest of the four — but it is where architecture meets the bill, and it is the most immediately practical. The Cloud Practitioner exam tested whether you could recognize the billing tools; here you are asked to design for cost, weighing pricing models, storage tiers, and right-sizing against the other three domains' requirements. The honest framing the exam expects is that cost optimization is a trade-off, not a race to zero: you rarely make something cheaper for free, so the skill is knowing which savings cost you nothing important and which quietly sacrifice resilience or performance you actually need.
The largest cost lever is choosing the right pricing model for each workload's usage shape, because the same compute can cost dramatically different amounts depending on how you buy it. On-demand pricing charges by the second or hour with no commitment — the flexible default for unpredictable or short-lived work. If you can commit to steady baseline usage for one or three years, you trade that commitment for a large discount through savings plans or reserved capacity, which is the right choice for the always-on core of a system. For interruptible, fault-tolerant work — batch jobs, rendering, anything that can be restarted — spare capacity offered at a deep discount can cut costs sharply, as long as the design tolerates being reclaimed. The exam's recurring move is to describe a workload's predictability and interruptibility and ask which pricing model fits: steady baseline points to a commitment, spiky points to on-demand, restartable points to the discounted spare capacity.
Right-sizing is the discipline of matching resources to actual need instead of over-provisioning out of caution. Teams routinely run instances larger than their workload requires, keep volumes and databases bigger than the data justifies, and leave idle resources running. Designing for cost means choosing the smallest resource that meets the performance and resilience requirement, scaling out with many small elastic instances rather than paying for a large box that sits mostly idle, and using auto scaling so capacity follows demand down as well as up — you stop paying for the night-time peak you sized for but never use. Serverless compute, which charges only when code runs and nothing when idle, is often the most cost-efficient choice for spiky or low-volume workloads precisely because there is no idle capacity to pay for.
Storage and data transfer are the quiet, cumulative costs the domain wants you to design around. Object storage offers tiers that trade retrieval speed and access frequency for price — frequently accessed data sits in a standard tier, while data touched rarely can live in far cheaper infrequent-access or archival tiers — and lifecycle rules can move data down the tiers automatically as it ages, so you are not paying premium rates to store logs from three years ago. A tool that automatically shifts objects to the cheapest appropriate tier based on how they are actually used takes the guesswork out. Data transfer is the cost most beginners miss: moving data out of AWS to the internet, and sometimes between Regions or zones, carries charges, so a cost-aware design keeps chatty traffic local, uses caching at the edge to cut repeated egress, and avoids needless cross-Region movement. The exam expects you to spot a design that will rack up transfer or premium-storage costs and choose the cheaper equivalent that still meets the requirement.
Finally, the domain expects you to design in the tools that make cost visible and controllable, because you cannot optimize what you cannot see. Budgets can monitor spending and trigger alerts or scoped actions, but they are not a universal real-time hard cap and costs can continue beyond a threshold. Cost-analysis tools that break the bill down by service and tag, consolidated billing, attribution tags, and recommendation services all support cost governance. Treat those controls as part of the architecture, not an afterthought.
Study this domain by taking a design you would build for the other three domains and asking, component by component, 'what is the cheapest way to meet this exact requirement without losing the security, resilience, or performance I need?' The account-free cost-model lab below requires normalized assumptions, uncertainty, tradeoffs, and reversal conditions instead of a predetermined savings result. Read the official SAA-C03 exam guide for AWS's authoritative published scope, domain weights, and task statements; AWS notes that the guide is not a comprehensive list of every exam topic.
Build three dated no-account AWS Pricing Calculator scenarios with explicit region, usage, data, resilience, exclusions, drivers, and uncertainty Evaluate eight optimization candidates against security, resilience, performance, compliance, and operations requirements and define a cost-governance cadence
Confirm three comparable scenarios and eight optimization rows include assumptions, exclusions, drivers, cross-domain tradeoffs, evidence, uncertainty, reversal conditions, and no claim of guaranteed cost or savings.
Practice evidence maps to exam_domain_aws_solutions_architect_associate_04
Stay safe & legal: Use only the public no-login AWS Pricing Calculator, public documentation, fictional workload assumptions, and learner-owned local files; no AWS account is needed. Account required: no; payment required: no; maximum designed cost: $0.
4RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Studying AWS Certified Solutions Architect – Associatebuilds transferable skills that carry across employers and platforms, not just toward this one exam. Each has a free, source-cited RoleMath primer — what it is, a step-by-step free learning path, clearly labeled free resources, and a safe hands-on exercise:
Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.
Check your AWS Certified Solutions Architect – Associate readiness →Full AWS Certified Solutions Architect – Associate decision page →
A free, source-cited study companion built on AWS's published SAA-C03 exam guide — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by Amazon Web Services.