SAA-C03 Domains and Scenario Reasoning

Objectives

• Identify the four domains and their scored-content weights.
• Separate hard requirements from preferences in a scenario.
• Eliminate distractors by explaining a violated requirement.

1. Know what the blueprint measures

Architecture questions are exercises in choosing a design under constraints. Your goal in this lesson is to replace service-name guessing with a repeatable method: extract requirements, test candidates, and justify the surviving choice.

The SAA-C03 guide divides scored content into four domains. These are exam content categories, not four independent layers of an application. [S1]

The names, weights, and task themes come from the exam guide. A single scenario may involve several domains: a cheaper design still needs to satisfy the required security and resilience constraints. [S1]

The guide describes 50 scored questions and 15 unidentified unscored questions. Multiple-choice items have one correct answer and three distractors; multiple-response items require at least two correct answers among at least five options. Follow the answer count in the question rather than assuming every item asks for one choice. [S1][S39]

The passing scaled score is 720 on a 100–1000 scale. Do not translate that into a claim that 72% correct is the passing threshold. The guide's scope lists also matter: its outline is not an exhaustive inventory, and a newly released feature is not automatically exam content. [S1]

Check yourself: Name the domains from highest to lowest weight before looking back. Answer: secure, resilient, high-performing, cost-optimized—30%, 26%, 24%, and 20%.

2. Refresh the failure boundary: Region versus Availability Zone

For this lesson, picture a Region as the outer deployment boundary containing multiple Availability Zones (AZs). AZs are distinct locations within that Region, providing isolation from failures affecting another AZ. Spreading resources across AZs is not the same as placing them in different Regions. [S16]

Aurora makes this distinction concrete. Its cluster storage keeps copies across multiple AZs in one Region even when all database instances are in one AZ. Those copies protect data, but they do not mean that a running database instance exists outside the failed AZ. AWS recommends distributing the writer and reader instances across AZs to improve instance availability. [S16]

Consider two candidate layouts:

• Layout A: writer and reader both in AZ A; cluster storage spans AZs.
• Layout B: writer in AZ A, reader in AZ B; cluster storage spans AZs.

If AZ A becomes unavailable, Layout B has an existing reader outside the affected AZ that can be promoted. Layout A does not. This is the difference between protecting stored data and maintaining a path to serving database requests. Failover can still interrupt requests; do not equate it with zero downtime. [S16]

A Region-wide outage is a different failure boundary. Aurora global databases span Regions, and updates from the primary Region to secondary Regions are asynchronous. A cross-Region design therefore needs recovery reasoning of its own; it is not simply another name for a multi-AZ cluster. [S16]

The accompanying diagram shows a single-Region cluster, not a complete application or a regional disaster-recovery design.

Check yourself: Does adding a reader in a second AZ satisfy a requirement to recover in another Region? No. Both instances are still inside the same regional boundary.

3. Turn a paragraph into a requirement ledger

Use this original practice scenario throughout the next two sections:

A company already runs an Aurora application in one AWS Region. It must keep all application data in that Region. The database must support automatic failover to an existing instance if one AZ becomes unavailable; a brief failover interruption is acceptable. The team prefers the lowest ongoing database cost among designs that satisfy those conditions. Assume that compute sizing and application connectivity are already adequate.

Before considering options, classify each statement:

This table is a teaching method, not an AWS scoring rubric. Words such as 'must' and 'cannot' often identify hard constraints, but read the meaning rather than just spotting keywords. A numeric cost ceiling would itself be a hard requirement; 'cost' is not always merely a preference.

Do not silently add requirements. The scenario does not ask for regional disaster recovery, worldwide reads, or uninterrupted writes. Adding those goals can make an attractive answer solve a different problem.

Check yourself: If the wording changes to 'monthly spending must not exceed the approved budget,' how does the ledger change? The budget becomes a pass/fail constraint, not merely a ranking preference. If no option meets all hard constraints, revisit your reading instead of quietly dropping one.

4. Eliminate distractors with a specific violation

For the scenario above, choose one of these original practice options:

• A. Retain only the writer instance and rely on Aurora's multi-AZ cluster storage.
• B. Keep the writer and one reader in the writer's AZ.
• C. Keep the writer and one reader in different AZs of the selected Region.
• D. Keep the writer in the selected Region and add an Aurora global database secondary in another Region.

Reason before revealing the answer: For each rejected option, complete this sentence: 'This option fails because the requirement says ___, but this design ___.'

A fails the existing-instance requirement. Multi-AZ storage protects the data, but a writer-only cluster has no existing reader to promote outside the affected AZ. Storage redundancy does not substitute for instance placement. [S16]

B fails the AZ-failure requirement. A writer and reader in the same AZ can both be affected by that AZ's outage. The extra reader does not establish an instance in a separate failure location. [S16]

D fails the data-location requirement. A global database replicates data to other Regions. It addresses a different failure scope while violating this scenario's explicit regional constraint. [S16]

C is the best answer among these options. It puts a reader outside the writer's AZ while keeping both instances and cluster data in the chosen Region. Aurora can promote a reader during failover; using the cluster endpoint for writes follows the current writer rather than fixing the application to one instance endpoint. [S16]

Notice what the explanation does not claim: it does not promise uninterrupted writes or prove that C is the cheapest possible Aurora deployment under every pricing configuration. Here, C is the only listed option that meets every hard requirement. No price calculation is needed to eliminate the others.

This is why plausible distractors are useful practice: each contains something technically relevant, but relevance is not sufficient. The exam guide explicitly describes distractors as plausible alternatives. [S39]

5. Use a short decision checklist and a structured worksheet

Apply this checklist to unfamiliar scenarios:

1. Read the request. Is it asking for one choice, several choices, the lowest cost, or the least operational effort?
2. Extract pass/fail conditions. Record location, access, recovery, latency, data model, and budget constraints actually stated.
3. Record tolerances and unknowns. Distinguish acceptable delay from an unstated recovery target.
4. Sketch the relevant boundary. Show where a failure occurs and which resources remain usable.
5. Test every candidate against every hard requirement. A single decisive violation can eliminate a candidate.
6. Rank compliant candidates. Apply the requested preference only to the survivors.
7. Explain the choice and rejection. State the mechanism that satisfies the requirement and the specific defect in each distractor.

The JSON code example is a local reasoning worksheet for this lesson. It is not an AWS API request, deployment template, or executable infrastructure. Reading or saving it provisions nothing. Its purpose is to make the assumptions and eliminations explicit.

Using diagrams and design notes to clarify an architecture, then prioritizing issues by business impact, is consistent with AWS's lightweight architecture-review guidance. That guidance also recommends reviewing early, before launch, and after significant changes. [S40]

Check yourself: If a candidate satisfies all requirements but has a feature you have never used, should you reject it for unfamiliarity? No. Test its stated behavior against the constraints; familiarity is not an architectural requirement.

6. Transfer the method to a storage question

Try a second original mini-scenario without an availability diagram:

An application uses object-storage APIs. Rarely accessed objects must remain directly readable within milliseconds, without a restore step. Choose between S3 Glacier Instant Retrieval and S3 Glacier Deep Archive. Treat storage cost as the preference after access requirements pass.

Write the hard requirement and one elimination sentence before reading on.

Worked answer: The hard requirement is direct millisecond access without restoration. Glacier Instant Retrieval supports millisecond access without a restore step. Deep Archive requires restoration before objects can be accessed, so it fails the hard requirement regardless of its storage price. [S2]

Choosing the compliant class is not yet a complete cost estimate. Retrieval costs, minimum storage durations, and billable object sizes can matter. The storage-class guide lists a 90-day minimum for Glacier Instant Retrieval and a 180-day minimum for Deep Archive. [S2]

Exit check:

1. List the four domain weights from memory.
2. In the Aurora scenario, identify two hard requirements and the ranking preference.
3. Explain why multi-AZ storage alone does not satisfy the existing-instance failover requirement.
4. Explain why a low storage price cannot rescue Deep Archive in the mini-scenario.

Answer guide: 30/26/24/20 for secure/resilient/high-performing/cost-optimized; same-Region data and existing-instance AZ failover are hard requirements, with cost ranking compliant options; stored copies do not create a database instance in another AZ; and restoration violates the required direct-access behavior. [S1][S16][S2]

Carry forward the habit, not just the answers: name the requirement, name the mechanism, then name the trade-off.

{
  "purpose": "Practice decision worksheet; not an AWS API payload",
  "hard_requirements": [
    "Keep all application data in the selected Region",
    "Automatically fail over to an existing instance after one AZ is lost"
  ],
  "tolerances": [
    "A brief failover interruption is acceptable"
  ],
  "ranking_preference": "Lowest ongoing database cost among compliant options",
  "candidates": [
    {"option": "A", "passes": false, "reason": "No existing reader outside the failed AZ"},
    {"option": "B", "passes": false, "reason": "Writer and reader share one AZ"},
    {"option": "C", "passes": true, "reason": "Writer and reader occupy different AZs in one Region"},
    {"option": "D", "passes": false, "reason": "Copies application data to another Region"}
  ],
  "selected_option": "C"
}

Original worksheet for the Aurora scenario; records requirement checks without creating AWS resources. Aurora behavior is explained with [S16] in the lesson.

Key takeaways

• SAA-C03 scored-content weights are secure 30%, resilient 26%, high-performing 24%, and cost-optimized 20%. [S1]
• Separate pass/fail requirements, explicit tolerances, assumptions, and ranking preferences before comparing options.
• Multi-AZ placement and multi-Region deployment address different failure boundaries. [S16]
• Aurora storage redundancy does not by itself provide a running instance outside a failed AZ. [S16]
• Reject a distractor by naming its violated requirement, not by calling the service generally unsuitable.
• Compare cost among compliant designs; a cheaper option that fails required access or recovery behavior is not a valid answer.

Common mistakes

• Treating 720 as proof that 72% correct passes.: It is a scaled score on a 100–1000 scale, not a published raw percentage threshold. [S1]
• Assuming any mention of multi-AZ means the whole application survives an AZ loss.: Inspect the placement and recovery behavior of the components serving requests, separately from storage protection. [S16]
• Choosing the lowest-priced option before checking constraints.: First eliminate options that fail a hard requirement, then apply the scenario's cost preference.
• Adding cross-Region replication automatically because it sounds more resilient.: Check the stated failure scope and data-location constraints. Aurora global databases copy data across Regions. [S16]
• Rejecting an answer only because another service is more familiar.: Explain a concrete requirement violation or comparative trade-off instead of relying on recognition.

References

1. AWS Certified Solutions Architect – Associate Exam Guide (SAA-C03), Amazon Web Services
2. AWS Certified Solutions Architect - Associate Exam Guide (SAA-C03), Amazon Web Services
3. High availability for Amazon Aurora, Amazon Web Services
4. The review process, Amazon Web Services
5. Understanding and managing Amazon S3 storage classes, Amazon Web Services

See the full course: AWS Solutions Architect – Associate (SAA-C03): Architecture and Exam Preparation