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 1 more to the end of certification prep.
SAA-C03 stems are scenarios: a company, a workload, a problem, and then a question. Most of the words set the scene. A handful decide the answer. This lesson is about finding that handful before you look at the options, and then spotting the one word in the options that separates the answer from its near-twin.
Everything in this lesson labelled Method is this course's technique. The AWS facts it relies on are quoted and sourced.
Read every stem as four layers:
| Layer | What it is | Example wording |
|---|---|---|
| Context | who, what, where. Mostly noise | "A media company runs a web application on EC2 instances…" |
| Constraints | pass/fail. An option that breaks one is out, however good it is otherwise | "must", "cannot", "without changing the application code", "RPO of 15 minutes" |
| Optimiser | the ranking rule among the survivors. Usually a superlative | "MOST cost-effective", "LEAST operational overhead", "with the lowest latency" |
| Ask | the shape of the answer | "Which solution…", "Which combination of steps… (Choose two.)" |
Here is an original stem, annotated:
A retailer runs its order API on Amazon EC2 instances in a single Availability Zone behind an Application Load Balancer. [context] Last month an AZ outage took the API offline for three hours. [context, which motivates the constraint] The company must keep the API available if an Availability Zone fails [constraint] and cannot modify the application code [constraint]. Which solution meets these requirements with the LEAST operational overhead? [optimiser + ask]
Before you read a single option you already know three things: the answer spans at least two AZs, it involves no code change, and among the options that do both, the one with fewer moving parts wins.
⚠️ The most common reading error is treating the optimiser as a constraint, or the reverse. "Most cost-effective" doesn't mean "cheapest option on the list". It means cheapest among those that meet every constraint. The cheapest option on the list usually fails a constraint, and it's there for exactly that reason.
The requirement phrases aren't invented by question writers. They come from the task statements. Verbatim, from the domain pages, verified 2026-09-25:
| Task | The guide says |
|---|---|
| 2.2 | "Using AWS services that improve the reliability of legacy applications and applications not built for the cloud (for example, when application changes are not possible)" |
| 2.2 | "Identifying metrics based on business requirements to deliver a highly available solution" |
| 2.2 | "Selecting an appropriate DR strategy to meet business requirements" |
| 2.2 | "Implementing designs to mitigate single points of failure" |
| 3.2 | "Selecting the appropriate resource type and size (for example, the amount of Lambda memory) to meet business requirements" |
| 4.1 | "Selecting the most cost-effective storage service for a workload" |
| 4.1 | "Determining the lowest cost method of transferring data for a workload to AWS storage" |
| 4.2 | "Determining the required availability for different classes of workloads (for example, production workloads, non-production workloads)" |
That last one deserves attention. The guide lists non-production availability as a skill. When a stem says "development environment" or "test workload", reducing availability is part of what's being tested. The Multi-AZ option there is a distractor for your production instinct.
"When application changes are not possible" is also a constraint you'll see directly. It rules out every option that says "refactor", "modify the application to…" or "rewrite as…".
The guide's opening line: "The exam validates a candidate's ability to design solutions based on the AWS Well-Architected Framework." The Framework has six pillars, per The pillars of the framework: "operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability".
AWS's one-line definitions, from each pillar's page:
| Pillar | AWS definition (verbatim) |
|---|---|
| Operational excellence | "a commitment to build software correctly while consistently delivering a great customer experience" |
| Security | "the ability to protect data, systems, and assets to take advantage of cloud technologies to improve your security" |
| Reliability | "the ability of a workload to perform its intended function correctly and consistently when it's expected to" |
| Performance efficiency | "the ability to use cloud resources efficiently to meet performance requirements, and to maintain that efficiency as demand changes and technologies evolve" |
| Cost optimization | "the ability to run systems to deliver business value at the lowest price point" |
| Sustainability | "focuses on environmental impacts, especially energy consumption and efficiency" |
Method: the phrase map. This mapping is this course's reading aid (first given in SAA0 lesson 1).
AWS doesn't publish it.
| Phrase in the stem | Pillar it selects | Constraint or optimiser? | What it usually eliminates |
|---|---|---|---|
| "LEAST operational overhead", "minimal management", "fully managed" | Operational excellence | optimiser | self-managed EC2, custom scripts, cron jobs, anything "manually" |
| "most secure", "least privilege", "encrypted at rest and in transit", "must be auditable" | Security | usually a constraint | long-term access keys, broad policies, public exposure |
| "highly available", "fault tolerant", "survive an AZ failure", "no single point of failure" | Reliability | constraint | single-AZ, single-instance, anything with one of something |
| an RTO / RPO number | Reliability (DR) | hard constraint | DR strategies too slow for the number, and ones far more expensive than needed |
| "lowest latency", "highest throughput", "millions of requests per second", "must scale to" | Performance efficiency | optimiser or constraint | undersized or synchronous designs |
| "MOST cost-effective", "lowest cost", "minimize cost" | Cost optimization | optimiser | over-provisioned, always-on, Multi-Region when not required |
| "reduce environmental impact", "minimize resources provisioned" | Sustainability | optimiser | idle capacity |
Two rules make the map work. Both are method:
⚠️ The trap is answering with the pillar you care about. Engineers default to reliability. If the stem says "most cost-effective" and gives no availability requirement, a Multi-AZ, multi-Region option isn't "better". It fails the optimiser.
AWS's definitions, from Business Continuity Plan (BCP), verified 2026-09-25:
"Recovery Time Objective (RTO) is the maximum acceptable delay between the interruption of service and restoration of service. This objective determines what is considered an acceptable time window when service is unavailable and is defined by the organization."
"Recovery Point Objective (RPO) is the maximum acceptable amount of time since the last data recovery point. This objective determines what is considered an acceptable loss of data between the last recovery point and the interruption of service and is defined by the organization."
The same page frames the choice as a two-sided fit. In its worked example, "the business has determined their maximum permissible RTO as well as the limit of what they can spend on their service restoration strategy. Given the business' objectives, the DR strategies Pilot Light or Warm Standby will satisfy both the RTO and the cost criteria."
Method: two-sided elimination. An RTO/RPO number removes options on both ends:
too slow for the number fits far more than the number needs
─────────────────────── ────── ──────────────────────────────
backup & restore (for a pilot light / multi-site active/active
"minutes" RTO) warm standby (when "cost-effective" is in the stem)
The four strategies and their distinguishing test are in SAA2 lesson 6. The one-line test AWS gives
is quoted there and re-verified today from
Disaster recovery options in the cloud:
"pilot light cannot process requests without additional action taken first, whereas warm standby can
handle traffic (at reduced capacity levels) immediately."
The guide tells you the distractors are "plausible responses that match the content area". In practice (and this is observation, not an AWS statement) a plausible distractor is very often the correct answer with one word changed. Five kinds of swap cover most of them. Every fact below is verified against the page cited:
| Kind of swap | Near-twin pair | What the one word does | Source |
|---|---|---|---|
| Feature for sibling feature | "Multi-AZ" vs "read replica" | "a Multi-AZ standby cannot serve read requests". Read replicas use "asynchronous replication" | RDS FAQ |
| Mode for mode | Step Functions "Standard" vs "Express" | Express "only support[s] Request Response integrations" and runs "up to five minutes". Standard runs "up to one year" | Step Functions |
| Mode for mode | Object Lock "compliance" vs "governance" | compliance: "can't be overwritten or deleted by any user, including the root user". Governance: deletable by users with "special permissions" | Object Lock |
| Policy for policy | Route 53 "failover" vs "weighted" routing | "active-passive failover using the failover routing policy". Active-active uses "any routing policy … other than failover" | Route 53 |
| Queue type | SQS "standard" vs "FIFO" | standard: "at-least-once delivery". FIFO: "exactly-once processing" | SQS FAQ |
| Setting value | target type "ip" vs "instance" for Fargate |
"you must choose ip as the target type, not instance" | Fargate |
Many more pairs are in drills.md.
Method: how to find the changed word.
These are reading cues, not rules. Each is only a cue until the stem's optimiser confirms it:
| Option wording | Why it's a cue |
|---|---|
| "Write a custom script…", "use a cron job on an EC2 instance…" | builds and runs something a managed feature does. Weak under "LEAST operational overhead" |
| "Manually…" | a human in the loop. Weak for anything recurring |
| "Launch an EC2 instance to run [a managed thing]" | self-managing what AWS offers managed |
| "Refactor / rewrite the application" | fails outright if the stem says application changes aren't possible |
| a service not named in the stem's problem domain | sometimes a pure distractor from an adjacent topic |
⚠️ Don't over-apply these. Sometimes the custom option is right, because no managed feature meets the constraint. The cue tells you where to look first. It doesn't decide the answer.
SAA2, strike through every context sentence, and show that
the answer is still determinable.