AWS Training
Modules Listen All tracks

← Exam Strategy and Question Mechanics

Starts this lesson and continues through 1 more to the end of certification prep.

Reading a scenario — requirement phrases and the one-word difference

Why this lesson matters

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.

The anatomy of a stem — Method

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 exam guide's own vocabulary

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…".

Requirement phrase → Well-Architected pillar

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:

  1. Constraints first, optimiser second. Throw out everything that fails a constraint. Then rank what's left on the optimiser.
  2. Tie-break on operational overhead. If two survivors look equal on the stated optimiser, the managed one wins. That follows from the Well-Architected basis: operational excellence is a pillar even when the stem doesn't name it.

⚠️ 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.

RTO and RPO — numbers are constraints

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 one-or-two-word difference

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.

  1. When two options share most of their wording, line them up and read only the difference. The question is testing that word.
  2. Ask what the word commits you to. "Synchronous" commits to a standby that doesn't serve reads. "Governance" commits to deletions by privileged users being possible.
  3. Match that commitment against the constraints you pulled out first. The twin that breaks a constraint is the distractor.

Words in the options that signal overhead — Method

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.

Check yourself

  1. In "…must survive the loss of an Availability Zone. Which solution is MOST cost-effective?", which is the constraint and which is the optimiser?
  2. A stem gives an RPO of 15 minutes and asks for the most cost-effective DR design. Name the two directions an option can fail in.
  3. Which exam-guide skill makes "reduce availability for a development environment" a legitimate answer?
  4. Two options are identical except one says "Multi-AZ deployment" and the other says "read replica". The stem is about read load. Which survives, and why?
  5. A stem says "without modifying the application". What does that eliminate before you read further?
Answers
  1. Constraint: survive an AZ loss. Optimiser: most cost-effective. Anything single-AZ is out; among the rest, the cheapest wins.
  2. Too slow: a strategy whose recovery point can't be within 15 minutes. Too much: a strategy far beyond the need (for example, multi-site active/active) when cost is the optimiser.
  3. Task 4.2: "Determining the required availability for different classes of workloads (for example, production workloads, non-production workloads)."
  4. Read replica. "a Multi-AZ standby cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits."
  5. Every option that refactors, rewrites or modifies code, for example "rewrite as Lambda functions". The guide's wording is "when application changes are not possible".

Teaching this section

← PreviousHow the questions are builtNext →Elimination as a method — four worked passes