Pair your devices with a code and playback position follows you: pause on this device, hit resume on the other. Position is saved to the site every minute and on pause.
Open this panel on your other device and enter the same code.
Starts this lesson and continues through 30 more to the end of certification prep.
The SAA-C03 exam guide's opening line about the exam is this: "The exam validates a candidate's ability to design solutions based on the AWS Well-Architected Framework."
Not "informed by". Based on. The Framework is the exam's scoring rubric, which is why it's the first document on the reading list and why it's the first lesson here.
And it explains the shape of the questions. Four answers, all technically functional, and the stem says "most cost-effective" or "least operational overhead" or "highest availability". That phrase is naming a pillar. Once you hear it that way, the question stops being "which of these works?" and becomes "which pillar did they just ask me to optimise for?"
Verbatim from AWS Well-Architected Framework, publication date November 6, 2024 (verified 2026-09-21):
"The AWS Well-Architected Framework helps you understand the pros and cons of decisions you make while building systems on AWS. Using the Framework helps you learn architectural best practices for designing and operating secure, reliable, efficient, cost-effective, and sustainable workloads in the AWS Cloud. It provides a way for you to consistently measure your architectures against best practices and identify areas for improvement."
Note the phrase "pros and cons". The Framework is explicitly about trade-offs, not rules. AWS reinforces this immediately:
"The process for reviewing an architecture is a constructive conversation about architectural decisions, and is not an audit mechanism."
⚠️ That sentence is worth carrying into the exam. Questions in this exam do not have an answer that is simply "correct" — they have an answer that is correct for the priority the stem named. The same architecture can be right in one question and wrong in the next.
What it's built from: "The AWS Well-Architected Framework documents a set of foundational questions that help you to understand if a specific architecture aligns well with cloud best practices." And who it's for: "those in technology roles, such as chief technology officers (CTOs), architects, developers, and operations team members."
Verbatim, from the Security Pillar whitepaper's own statement of the framework (Security Pillar, publication date November 6, 2024) — "The framework is based on six pillars":
| # | Pillar | The stem phrase that means "this pillar" |
|---|---|---|
| 1 | Operational Excellence | "least operational overhead", "easiest to maintain", "minimise manual effort" |
| 2 | Security | "must be encrypted", "least privilege", "must be auditable", "meet compliance" |
| 3 | Reliability | "highly available", "fault tolerant", "must survive an AZ failure", "RTO / RPO" |
| 4 | Performance Efficiency | "lowest latency", "highest throughput", "must scale to" |
| 5 | Cost Optimization | "most cost-effective", "lowest cost", "minimise spend" |
| 6 | Sustainability | "reduce environmental impact", "minimise resources provisioned" |
⚠️ Six, not five. Sustainability was added after a great deal of study material was written, and older courses still say five. The SAA-C03 exam guide doesn't weight domains by pillar, but the pillar vocabulary is how the questions are phrased, so the count matters for the reading rather than for a direct question.
The mapping to the exam's four domains is nearly one-to-one and worth seeing side by side:
| Exam domain | Weight | Pillar it corresponds to |
|---|---|---|
| Design Secure Architectures | 30% | Security |
| Design Resilient Architectures | 26% | Reliability |
| Design High-Performing Architectures | 24% | Performance Efficiency |
| Design Cost-Optimized Architectures | 20% | Cost Optimization |
Operational Excellence and Sustainability don't get their own domain — they show up inside the other four, as the "least operational overhead" tie-breaker. Which is exactly how they behave in the exam: when two options both meet the stated requirement, the one with less operational overhead wins. That single heuristic is worth several marks.
Verbatim from General design principles, verified 2026-09-21. These are the ones people skip, and they are the most quotable thing in the whole whitepaper.
1. Stop guessing your capacity needs
"If you make a poor capacity decision when deploying a workload, you might end up sitting on expensive idle resources or dealing with the performance implications of limited capacity. With cloud computing, these problems can go away. You can use as much or as little capacity as you need, and scale in and out automatically."
Exam consequence: any option that fixes a capacity figure in advance is suspect. Auto Scaling, serverless and on-demand provisioning are the framework-aligned answers.
2. Test systems at production scale
"In the cloud, you can create a production-scale test environment on demand, complete your testing, and then decommission the resources. Because you only pay for the test environment when it's running, you can simulate your live environment for a fraction of the cost."
3. Automate with architectural experimentation in mind
"Automation permits you to create and replicate your workloads at low cost and avoid the expense of manual effort. You can track changes to your automation, audit the impact, and revert to previous parameters when necessary."
Exam consequence: infrastructure as code — CloudFormation, CDK — beats console steps, and it beats them on revertibility, not just speed. That's the reason to cite.
4. Consider evolutionary architectures
"In a traditional environment, architectural decisions are often implemented as static, onetime events, with a few major versions of a system during its lifetime. As a business and its context continue to evolve, these initial decisions might hinder the system's ability to deliver changing business requirements. In the cloud, the capability to automate and test on demand lowers the risk of impact from design changes."
5. Drive architectures using data
"In the cloud, you can collect data on how your architectural choices affect the behavior of your workload. This lets you make fact-based decisions on how to improve your workload. Your cloud infrastructure is code, so you can use that data to inform your architecture choices and improvements over time."
6. Improve through game days
"Test how your architecture and processes perform by regularly scheduling game days to simulate events in production. This will help you understand where improvements can be made and can help develop organizational experience in dealing with events."
Exam consequence: when a question asks how to validate a disaster recovery plan, "test the failover on a schedule" is the framework answer. Documenting the runbook is not testing it.
"AWS also provides a service for reviewing your workloads at no charge. The AWS Well-Architected Tool (AWS WA Tool) is a service in the cloud that provides a consistent process for you to review and measure your architecture using the AWS Well-Architected Framework."
At no charge is the examinable detail. If an option proposes a paid engagement or a custom assessment process where the WA Tool would do, the WA Tool is the lower-cost, lower-overhead answer.
Also named on the page: AWS Well-Architected Labs ("a repository of code and documentation to give you hands-on experience implementing best practices") and the AWS Well-Architected Partner program.
Three passes over every question:
⚠️ The trap is answering with the pillar you care about. An engineer's instinct is reliability; the stem may have asked for cost. A question that says "development environment" and "most cost-effective" is not asking you to make it Multi-AZ, and the Multi-AZ option is there precisely because your instinct will reach for it.